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
Nächste Überarbeitung Beide Seiten der Revision
invis_server_wiki:dasi [2020/06/07 15:49]
flacco [Datensicherungsserver]
invis_server_wiki:dasi [2020/06/08 06:37]
flacco [Sicherung konfigurieren]
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 412: 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 446: 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 =====
  
  • invis_server_wiki/dasi.txt
  • Zuletzt geändert: 2021/03/09 08:53
  • von flacco