invis_server_wiki:dasi

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
invis_server_wiki:dasi [2020/06/07 15:49]
flacco [Datenwiederherstellung mit rdiff-backup]
invis_server_wiki:dasi [2020/06/10 12:30] (aktuell)
flacco [Borg Backup]
Zeile 3: Zeile 3:
 invis-Server verfügen über ein mehrschichtiges Datensicherungssystem,​ bestehend aus regelmäßigen internen Sicherungen,​ kombiniert mit einer externen Sicherung auf externe Festplatten oder einen Datensicherungsserver. invis-Server verfügen über ein mehrschichtiges Datensicherungssystem,​ bestehend aus regelmäßigen internen Sicherungen,​ kombiniert mit einer externen Sicherung auf externe Festplatten oder einen Datensicherungsserver.
  
-Für die Überwachung und ggf. die Durchführung der externen Datensicherung ist primär der Betreiber eines invis-Servers verantwortlich. Dies ist beispielsweise der Geschäftsführer einen Unternehmens und nicht etwa der Systemadministrator. Selbstverständlich können diese Aufgaben innerhalb eines Unternehmens delegiert werden, sprich die Verantwortlichkeit für Durchführung und Überwachung an Mitarbeiter weitergegeben werden. Dies sollte in jedem Falle vertraglich geregelt werden. Einen externen IT-Dienstleister für die Datensicherung verantwortlich zu machen ist eher unsinnig. Er (wenn vorhanden) sollte allerdings ​in die Überwachung der Datensicherung ​herangezogen werden. ​+Für die Überwachung und ggf. die Durchführung der externen Datensicherung ist primär der Betreiber eines invis-Servers verantwortlich. Dies ist beispielsweise der Geschäftsführer einen Unternehmens und nicht etwa der Systemadministrator. Selbstverständlich können diese Aufgaben innerhalb eines Unternehmens delegiert werden, sprich die Verantwortlichkeit für Durchführung und Überwachung an Mitarbeiter weitergegeben werden. Dies sollte in jedem Falle vertraglich geregelt werden. Einen externen IT-Dienstleister für die Datensicherung verantwortlich zu machen ist eher unsinnig. Er (wenn vorhanden) sollte allerdings ​für gelegentliche Kontrollen und Wiederherstellungstests ​herangezogen werden. ​
  
 Auch wenn die Verantwortlichkeit für die Datensicherung innerhalb eines Unternehmens an einen oder mehrere Mitarbeiter delegiert wurde, sollte es ureigenstes Interesse der Geschäftsleitung sein die damit zusammenhängenden Aufgaben regelmäßig zu kontrollieren. Bezüglich der Haftung bei Schäden durch Datenverlust steht die Geschäftsleitung bzw. der Unternehmer immer in der Mitverantwortung. Versäumnisse bei der Datensicherung werden rechtlich stets als Mitverschulden im Sinne des § 254 (Mitverschulden) BGB bewertet.  ​ Auch wenn die Verantwortlichkeit für die Datensicherung innerhalb eines Unternehmens an einen oder mehrere Mitarbeiter delegiert wurde, sollte es ureigenstes Interesse der Geschäftsleitung sein die damit zusammenhängenden Aufgaben regelmäßig zu kontrollieren. Bezüglich der Haftung bei Schäden durch Datenverlust steht die Geschäftsleitung bzw. der Unternehmer immer in der Mitverantwortung. Versäumnisse bei der Datensicherung werden rechtlich stets als Mitverschulden im Sinne des § 254 (Mitverschulden) BGB bewertet.  ​
Zeile 211: Zeile 211:
 Bei beiden Tools ist es möglich dem eigentlichen Sicherungskommando "​rdiff-backup"​ bzw. "​borg"​ Befehlsoptionen mitzugeben. Hier haben wir jeweils Vorgaben gemacht. In der Hauptsache geht es dabei um Excludes, also Regeln darüber was von den Sicherungen ausgeschlossen werden soll. Bei beiden Tools ist es möglich dem eigentlichen Sicherungskommando "​rdiff-backup"​ bzw. "​borg"​ Befehlsoptionen mitzugeben. Hier haben wir jeweils Vorgaben gemacht. In der Hauptsache geht es dabei um Excludes, also Regeln darüber was von den Sicherungen ausgeschlossen werden soll.
  
-Die letzte Option ''​dasiMonitorAct''​ ermöglicht es das Tool //​**dasimonitor**//​ scharf zu schalten. Wird eine Datensicherung rabiat unterbrochen,​ kann es sein, dass der Sicherungssnapshot erhalten und gemountet bleibt. Dies würde künftige Datensicherungen verhindern. Ist //​**dasimonitor**//​ scharf geschaltet kontrolliert es alle 3 Minuten, ob solche Relikte vorhanden sind und entfernt sie gegebenenfalls. Das birgt allerdings auch Gefahren. Beispielsweise wenn Sie manuell einen LV-Snapshot anlegen und diesen nach "/​mnt/​backup"​ mounten. //​**dasimonitor**//​ würde das als Relikt ansehen und entfernen. Schalten Sie //​**dasimonitor**//​ nur scharf, wenn es bei der Datensicherung immer mal wieder zu Problemen kommt.+Die letzte Option ''​dasiMonitorAct''​ ermöglicht es das Tool //​**dasimonitor**//​ scharf zu schalten. Wird eine Datensicherung rabiat unterbrochen,​ kann es sein, dass der Sicherungssnapshot erhalten und gemountet bleibt. Dies würde künftige Datensicherungen verhindern. Ist //​**dasimonitor**//​ scharf geschaltet kontrolliert es alle 3 Minuten, ob solche Relikte vorhanden sind und entfernt sie gegebenenfalls. Das birgt allerdings auch Gefahren. Beispielsweise wenn Sie manuell einen LV-Snapshot anlegen und diesen nach "/​mnt/​backup"​ mounten. //​**dasimonitor**//​ würde das als Relikt ansehen und entfernen. Schalten Sie //​**dasimonitor**//​ nur scharf, wenn es bei der Datensicherung immer mal wieder zu Problemen kommt. Im unscharfen Zustand überwacht dasimonitor lediglich, ob die Datensicherung aktiv ist oder nicht und protokolliert dies für die Anzeige im invis-Portal.
  
 === Testen === === Testen ===
Zeile 365: Zeile 365:
  
 Die Abfrage eines Passworts erfolgt nicht, da die Authentifikation via Public-Key Verfahren erfolgt. Die Abfrage eines Passworts erfolgt nicht, da die Authentifikation via Public-Key Verfahren erfolgt.
- 
-Wechseln sie jetzt ins Sicherungsverzeichnis:​ 
- 
-<​code>​ 
-sicherungsserver:​~ # cd /srv/backup 
-</​code>​ 
- 
 ==== Datenwiederherstellung mit rdiff-backup ==== ==== Datenwiederherstellung mit rdiff-backup ====
  
Zeile 419: Zeile 412:
 invis:~ # cd /​mnt/​udevsync/​rdbackups invis:~ # cd /​mnt/​udevsync/​rdbackups
 invis:/​mnt/​udevsync/​rdbackups #  invis:/​mnt/​udevsync/​rdbackups # 
 +</​code>​
 +
 +Auf einem Backupserver gehen wir vom folgenden Pfad aus. Wechseln sie jetzt ins Sicherungsverzeichnis:​
 +
 +<​code>​
 +sicherungsserver:​~ # cd /srv/backup
 </​code>​ </​code>​
  
Zeile 453: Zeile 452:
  
 ==== Datenwiederherstellung mit borg Backup ==== ==== Datenwiederherstellung mit borg Backup ====
 +
 +Anders als bei //​**rdiff-backup**//​ legt //​**borg**//​ keine gesicherten Daten in Ihrer Normalform ab. D.h. eine Rücksicherung mit Copy & Paste ist zunächst nicht möglich. Dennoch ist die Lösung eleganter als beim Konkurrenten. Die Datensicherungsrepositories lassen sich als Dateisysteme in den Verzeichnisbaum des Servers einhängen. (Zugegeben, das ist auch mit //​**rdiff-backup**//​ möglich, hat uns aber weit weniger gefallen.)
 +
 +Je nach dem, ob Sie als Sicherungsziel externe Festplatten oder einen Backup-Server nutzen müssen Sie entweder auf den Backup-Server wechseln oder die Sicherungsplatte mounten. Siehe Abschnitt "​Vorbereitung"​ weiter oben im Text.
 +
 +Ist dies geschehen, können Sie die Sicherungsrepositories mit dem Kommando //​**borg**//​ mounten. Sie benötigen dazu das Passwort der Repository Verschlüsselung,​ zu finden in: <​file>/​etc/​invis/​invis-pws.conf</​file>​ auf dem invis-Server.
 +
 +Hängen Sie das gewünschte Repository ein:
 +<​code>​
 +invis:~ # borg mount /​mnt/​udevsync/​bbackups/​srv /​mnt/​restore
 +Enter passphrase for key /​srv/​backup/​srv:​
 +</​code>​
 +
 +Im Zielverzeichnis finden Sie jetzt für jede erfolgte Datensicherung in dieses Repo ein Verzeichnis,​ benannt mit dem Datum der Datensicherung. Wechselns Sie ins gewünschte Sicherungsverzeichnis und tauchen Sie dort in den Verzeichnisbaum bis an die Stelle der wiederherzustellenden Daten ein. Jetzt können Sie die Daten einfach aus dem Repository heraus kopieren.
 +
 +Clever ist auch eine Wiederherstellung mittels //​**rsync**//​ direkt an den Ursprungsort oder ein gesondertes Wiederherstellungsverzeichnis. Das geht natürlich auch Remote vom Backupserver aus.
 +
 +Beispiel:
 +
 +<​code>​
 +backupserver:​~ # rsync -raHAXv -e "ssh -i /​home/​user/​.ssh/​sshkey"​ /​mnt/​restore/​2020-06-15/​mnt/​backup/​srv/​shares/​gruppen/​technik/​zeichnungen root@invis.example-net.loc:/​srv/​shares/​gruppen/​technik/​zeichnungen
 +</​code>​
 +
 +Die im Beispiel gezeigten //​**rsync**//​ Optionen "​aHAX"​ sorgen dafür, dass Zugriffs- und Besitzrechte,​ erweiterte Attribute und POSIX-ACLs erhalten bleiben. ​
 +
 +//​**Achtung:​** Passen Sie beim Wiederherstellen auf jeden Fall darauf auf, dass sie sich dabei keine wichtigen Daten mit älteren Dateiversionen überschreiben!//​
 +
 +Der Quellpfad im gezeigten Beispiel sieht auf den ersten Blick ein wenig merkwürdig aus. Das liegt daran, dass //​**borg**//​ den Quellpfad der erhält. Da wir durch einen LV-Snapshot sichern und dieser während der Sicherung nach "/​mnt/​backup"​ gemountet ist, taucht dieser Pfad natürlich genau so in der Sicherung auf.
 +
 +Ist die Wiederherstellung abgeschlossen muss das Sicherungsrepository wieder ausgehangen werden:
 +
 +<​code>​
 +backupserver:​~ # umount /​mnt/​restore
 +</​code>​
 +
 +Wurde von einer Sicherungsfestplatte wiederhergestellt,​ muss diese natürlich auch wieder ausgehangen werden:
 +
 +<​code>​
 +invis:~ # umount /​mnt/​udevsync
 +</​code>​
 +
 ===== Sicherung Überwachen und ggf. Aufräumen ===== ===== Sicherung Überwachen und ggf. Aufräumen =====
  
 +==== Global ====
 Wir haben festgestellt,​ dass gerade bei der Verwendung von externen Sicherungsfestplatten immer wieder Probleme auftreten, beispielsweise,​ weil Festplatten versehentlich getrennt werden noch während eine Sicherung läuft. Um derartiges zu vermeiden zeigt das invis-Portal inzwischen wesentlich deutlicher an, dass eine Sicherung aktiv ist. Dies setzt natürlich die Nutzung des invis-Portals voraus.... Wir haben festgestellt,​ dass gerade bei der Verwendung von externen Sicherungsfestplatten immer wieder Probleme auftreten, beispielsweise,​ weil Festplatten versehentlich getrennt werden noch während eine Sicherung läuft. Um derartiges zu vermeiden zeigt das invis-Portal inzwischen wesentlich deutlicher an, dass eine Sicherung aktiv ist. Dies setzt natürlich die Nutzung des invis-Portals voraus....
  
 Um nach einem Abbruch einer Sicherung verwaiste Mounts oder Snapshot-Volumes wieder los zu werden läuft per Cornjob alle 3 Minuten das Script //​**dasimonitor**//​. Das Script ist auch die Quelle der Informationen die im invis-Portal angezeigt werden. Um nach einem Abbruch einer Sicherung verwaiste Mounts oder Snapshot-Volumes wieder los zu werden läuft per Cornjob alle 3 Minuten das Script //​**dasimonitor**//​. Das Script ist auch die Quelle der Informationen die im invis-Portal angezeigt werden.
 +
 +==== Borg Backup ====
 +
 +Etwa durch einen unterbrochenen Backup-Vorgang kann es sein, dass ein Borg-Sicherungs-Repository dauerhaft geblockt ist. Eine solche Blockade muss manuell aufgehoben werden. Zuvor ist sicherzustellen,​ dass aktuell niemand auf das Repository zugreift. Ist dies geschehen gehen Sie wie folgt vor:
 +
 +**Disk-Backup**
 +
 +Beim Sichern auf externe Festplatten müssen diese natürlich erst gemountet werden. Dabei ist zu verhindern, dass dies eine Datensicherung auslöst:
 +
 +<​code>​
 +invis:~ # udbrestore
 +invis:~ # mount /dev/backup /​mnt/​udevsync
 +</​code>​
 +
 +Jetzt kann das blockierte Repository von seiner Blockade befreit werden.
 +
 +<​code>​
 +invis:~ # borg break-lock /​mnt/​udevsync/​borgbackups/​repo
 +</​code>​
 +
 +Abschließend muss der Schutz gegen eine ungeplante Datensicherung wieder entfernt und die Platte ausgehängt werden:
 +
 +<​code>​
 +invis:~ # umount /​mnt/​udevsync
 +invis:~ # rm /​var/​spool/​results/​backup/​restore
 +</​code>​
 +
 +**Backup-Server**
 +<​code>​
 +invis:~ # borg break-lock ssh://​root@backupserver.example.loc:​22/​pfad/​zum/​repo
 +</​code>​
  
 ===== Sicherungsverlauf im invis-Portal anzeigen ===== ===== Sicherungsverlauf im invis-Portal anzeigen =====
  • invis_server_wiki/dasi.1591544957.txt.gz
  • Zuletzt geändert: 2020/06/07 15:49
  • von flacco