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:25]
flacco
invis_server_wiki:dasi [2020/06/10 12:30]
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 339: Zeile 339:
 Die Wiederherstellung von Daten unterscheidet sich geringfügig,​ je nach dem, ob das Sicherungsziel externe Festplatten oder ein Sicherungsserver ist und deutlich, je nachdem, ob **invis-rdbu** oder **invis-bbu** genutzt wird. Die Wiederherstellung von Daten unterscheidet sich geringfügig,​ je nach dem, ob das Sicherungsziel externe Festplatten oder ein Sicherungsserver ist und deutlich, je nachdem, ob **invis-rdbu** oder **invis-bbu** genutzt wird.
  
-==== Wechseln ins Verzeichnis der Datensicherung ​==== +==== Wiederherstellung von Daten vorbereiten ​==== 
 +=== Sicherungsfestplatten ===
 Im Falle externer Sicherungsplatten ist beim Verbinden der Platte mit dem Server zu verhindern, dass das Verbinden unmittelbar eine neue Sicherung auslöst. Für diesen Zweck existiert ein eigenes Script, welches **vor** dem Verbinden der Festplatte ohne weiteren Parameter auf der Kommandozeile des Servers aufgerufen wird: Im Falle externer Sicherungsplatten ist beim Verbinden der Platte mit dem Server zu verhindern, dass das Verbinden unmittelbar eine neue Sicherung auslöst. Für diesen Zweck existiert ein eigenes Script, welches **vor** dem Verbinden der Festplatte ohne weiteren Parameter auf der Kommandozeile des Servers aufgerufen wird:
  
Zeile 355: Zeile 355:
 </​code>​ </​code>​
  
-=== Datenwiederherstellung mit rdiff-backup ===+=== Datensicherungsserver === 
 + 
 +In diesem Fall melden Sie sich zunächst per SSH am Sicherungsserver an: 
 + 
 +<​code>​ 
 +invis:~ # ssh root@sicherungsserver 
 +sicherungsserver:​~ # 
 +</​code>​ 
 + 
 +Die Abfrage eines Passworts erfolgt nicht, da die Authentifikation via Public-Key Verfahren erfolgt. 
 +==== Datenwiederherstellung mit rdiff-backup ​====
  
 Für die Wiederherstellung von Daten ist es entscheidend,​ wie schnell der Verlust einer Datei oder eines Verzeichnisses auffällt. Da die Basis der Sicherung das Programm //​**rdiff-backup**//​ ist, ist jeweils der letzte Sicherungsstand direkt verfügbar, ältere Sicherungsstände liegen nur noch als sogenannte Inkremente in der Sicherung vor und müssen unter Verwendung von //​**rdiff-backup**//​ **berechnet** werden. In jedem Fall benötigen Sie Erfahrung auf der Linux-Kommandozeile. Für die Wiederherstellung von Daten ist es entscheidend,​ wie schnell der Verlust einer Datei oder eines Verzeichnisses auffällt. Da die Basis der Sicherung das Programm //​**rdiff-backup**//​ ist, ist jeweils der letzte Sicherungsstand direkt verfügbar, ältere Sicherungsstände liegen nur noch als sogenannte Inkremente in der Sicherung vor und müssen unter Verwendung von //​**rdiff-backup**//​ **berechnet** werden. In jedem Fall benötigen Sie Erfahrung auf der Linux-Kommandozeile.
  
 In der Praxis bedeutet das, dass eine Datei die nach der letzten Datensicherung auf dem Server gelöscht wurde, auf dem Sicherungsmedium vollwertig vorhanden ist und einfach zurück kopiert werden kann. Erfolgt nach dem Löschen eines Originals eine zweite Sicherung auf das gleiche Sicherungsmedium muss die Datei aus den Inkrementen wiederhergestellt werden. Letzteres ist deutlich aufwändiger. In der Praxis bedeutet das, dass eine Datei die nach der letzten Datensicherung auf dem Server gelöscht wurde, auf dem Sicherungsmedium vollwertig vorhanden ist und einfach zurück kopiert werden kann. Erfolgt nach dem Löschen eines Originals eine zweite Sicherung auf das gleiche Sicherungsmedium muss die Datei aus den Inkrementen wiederhergestellt werden. Letzteres ist deutlich aufwändiger.
 +
 +=== Daten aus der aktuellsten Sicherung wiederherstellen ===
  
 Um Daten wiederherzustellen müssen Sie auf der Kommandozeile in das Verzeichnis der Sicherung wechseln. Je nach Sicherungsziel müssen Sie unterschiedliche Wege gehen. Um Daten wiederherzustellen müssen Sie auf der Kommandozeile in das Verzeichnis der Sicherung wechseln. Je nach Sicherungsziel müssen Sie unterschiedliche Wege gehen.
Zeile 386: Zeile 398:
 invis:~ # umount /​mnt/​udevsync invis:~ # umount /​mnt/​udevsync
 </​code>​ </​code>​
- 
-**Datensicherungsserver** 
- 
-In diesem Fall melden Sie sich zunächst per SSH am Sicherungsserver an: 
- 
-<​code>​ 
-invis:~ # ssh root@sicherungsserver 
-sicherungsserver:​~ # 
-</​code>​ 
- 
-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>​ 
- 
 === Wiederherstellen älterer Dateiversionen mittels rdiff-backup ==== === Wiederherstellen älterer Dateiversionen mittels rdiff-backup ====
  
Zeile 418: 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 450: Zeile 450:
  
 ... work in progress ... ... work in progress ...
 +
 +==== 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.txt
  • Zuletzt geändert: 2021/06/01 09:40
  • von flacco