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 13:10]
flacco [Sicherungsverlauf im invis-Portal anzeigen]
invis_server_wiki:dasi [2020/06/10 12:19]
flacco [Sicherung Überwachen und ggf. Aufräumen]
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 133: Zeile 133:
 Zur Verwendung von **//​udbconf//​** müssen Sie sich im Klaren sein, was Sie sichern wollen. Zur Verwendung von **//​udbconf//​** müssen Sie sich im Klaren sein, was Sie sichern wollen.
  
-Wie eingangs bereits erläutert, ​setzt "​invis-rdbu"​ die Verwendung von Logical-Volume-Management zwingend voraus. Zur Konfiguration der Datensicherung benötigen Sie den Namen der Volume-Group und der darauf liegenden zu sichernden Volumes. Sichern sollten Sie grundsätzlich alle logischen Volumes des Servers, nur dann ist es möglich eine vollständige Server-Installation aus der Sicherung wiederherzustellen. Wenn Sie bei der Partitionierung der Server-Festplatten gemäß unserem Beispiel hier im **[[:​invis_server_wiki:​installation#​festplatten-management|Wiki]]** vorgegangen sind, sind das die Volumes:+Wie eingangs bereits erläutert, ​setzen ​"​invis-rdbu" und "​invis-bbu" die Verwendung von Logical-Volume-Management zwingend voraus. Zur Konfiguration der Datensicherung benötigen Sie den Namen der Volume-Group und der darauf liegenden zu sichernden Volumes. Sichern sollten Sie grundsätzlich alle logischen Volumes des Servers, nur dann ist es möglich eine vollständige Server-Installation aus der Sicherung wiederherzustellen. Wenn Sie bei der Partitionierung der Server-Festplatten gemäß unserem Beispiel hier im **[[:​invis_server_wiki:​installation#​festplatten-management|Wiki]]** vorgegangen sind, sind das die Volumes:
  
   * **root**   * **root**
Zeile 175: Zeile 175:
 <​code>​ <​code>​
 # Konfigurationsdatei fuer invis-bbudisk # Konfigurationsdatei fuer invis-bbudisk
-# (c) 2010-2016 Stefan Schaefer - invis-server.org+# (c) 2010-2020 Stefan Schaefer - invis-server.org
  
 # Zielhost # Zielhost
Zeile 185: Zeile 185:
 # Mehrere Volume Namen durch Leerzeichen trennen # Mehrere Volume Namen durch Leerzeichen trennen
 sourceVolume:​srv home root var sourceVolume:​srv home root var
-# Groeße des Snapshots ​-> Achtung bei Images von virtuellen Maschinen,​ +# Groeße des Snapshots
-# hier muessen die Images in den Snapshot passen.+
 snapshotSize:​10G snapshotSize:​10G
 # Name des Snapshot-Volumes # Name des Snapshot-Volumes
Zeile 208: Zeile 207:
 </​code>​ </​code>​
  
-Grundsätzlich ​versucht ​"​invis-rdbu"​ Emails zu versenden, die generell über die Durchführung der Datensicherung informieren,​ oder nur Fehler melden. Voreingestellt ist das Versenden von Mails im Fehlerfall. Diese Einstellung kann manuell in der automatisch erzeugten Konfigurationsdatei <​file>/​etc/​invis/​rdbudisk.conf</​file>​ angepasst werden.+Grundsätzlich ​versuchen ​"​invis-rdbu" und "​invis-bbu" Emails zu versenden, die generell über die Durchführung der Datensicherung informieren,​ oder nur Fehler melden. Voreingestellt ist das Versenden von Mails im Fehlerfall. Diese Einstellung kann manuell in der automatisch erzeugten Konfigurationsdatei <​file>/​etc/​invis/​rdbudisk.conf</​file>​ oder <​file>/​etc/​invis/​bbudisk.conf</​file>​ angepasst werden
 + 
 +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. 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 221: Zeile 224:
 ==== Einrichtung der Datensicherung auf einen Sicherungsserver ==== ==== Einrichtung der Datensicherung auf einen Sicherungsserver ====
  
-Der Sicherungsserver selbst benötigt einfach nur eine Linux-Installation mit genügend Festplattenplatz. Auf ihm muss der SSH-Dienst laufen und //​**rdiff-backup**//​ installiert sein.+Der Sicherungsserver selbst benötigt einfach nur eine Linux-Installation mit genügend Festplattenplatz. Auf ihm muss der SSH-Dienst laufen und je nach verwendeter Sicherungslösung ​//​**rdiff-backup**// oder //**borg**// installiert sein. Letzteres wird bei Verwendung des neueren **invis-bbu** beim Initialisieren der Borg-Repositories automatisch erledigt. Kommt **invis-rdbu** zum Einsatz muss //​**rdiff-backup**//​ händisch auf dem Zielserver installiert werden.
  
 === SSH vorbereiten === === SSH vorbereiten ===
Zeile 230: Zeile 233:
  
 <​code>​ <​code>​
 +invis:~ # ssh-keygen
 +...
 Generating public/​private rsa key pair. Generating public/​private rsa key pair.
 Enter file in which to save the key (/​root.sshid_rsa):​ Enter file in which to save the key (/​root.sshid_rsa):​
Zeile 286: Zeile 291:
 === Sicherung einrichten === === Sicherung einrichten ===
  
-Das Einrichten einer Sicherung auf einen externen Server läuft analog zur Sicherung auf externe Festplatten ab. Es existiert ​mit //​**rdbunetconf**//​auch hier ein Scriptwelches ​die Konfigurationsdatei zur Sicherung generiert. Es ist einfach ohne weitere Optionen aufzurufen:+Das Einrichten einer Sicherung auf einen externen Server läuft analog zur Sicherung auf externe Festplatten ab. Es existieren ​mit //​**rdbunetconf**// und //​**bbunetconf**// auch hier ein Scriptswelche ​die Konfigurationsdatei zur Sicherung generiert. Es ist einfach ohne weitere Optionen aufzurufen:
  
 <​code>​ <​code>​
-invis:~ # rdbunetconf+invis:~ # bbunetconf
 </​code>​ </​code>​
  
 Im Verlauf des Scripts wird gefragt, ob die Sicherung via SSH oder auf eine einzuhängende SMB-Freigabe erfolgen soll. Wir empfehlen ganz eindeutig die SSH-Methode zu bevorzugen. Die SMB-Methode ist eher eine Notlösung, beispielsweise zur Sicherung auf ein NAS System welches lediglich via SMB nutzbar ist. Dabei kommt es allerdings immer wieder zu Problemen, beispielsweise wegen maximaler Pfadlängen,​ unterschiedlichen Zeichensätzen oder auch der Konsistenz von Zugriffs- und Besitzrechten. Im Verlauf des Scripts wird gefragt, ob die Sicherung via SSH oder auf eine einzuhängende SMB-Freigabe erfolgen soll. Wir empfehlen ganz eindeutig die SSH-Methode zu bevorzugen. Die SMB-Methode ist eher eine Notlösung, beispielsweise zur Sicherung auf ein NAS System welches lediglich via SMB nutzbar ist. Dabei kommt es allerdings immer wieder zu Problemen, beispielsweise wegen maximaler Pfadlängen,​ unterschiedlichen Zeichensätzen oder auch der Konsistenz von Zugriffs- und Besitzrechten.
 +
 +Kommt **invis-bbu** zum Einsatz müssen die Sicherungsrepositories noch vorbereitet werden. Anders als bei //​**rdiff-backup**//​ sind dies nicht einfach leere Verzeichnisse. Wie bereits erwähnt unterstützt //​**borg**//​ auch nativ verschlüsselte Repositories. Teil des Backup-Pakets ist das Tool //​**bbcrr**//,​ es installiert **//​borg//​** auf dem Zielserver, legt die Repositories an, verschlüsselt sie und speichert das zugehörige Passwort in: <​file>/​etc/​invis/​invis-pws.conf</​file>​
 +
 +Darüber hinaus extrahiert es die Schlüssel der Repositories und legt diese in <​file>/​etc/​invis/​private/</​file>​ab.
 +
 +Das Tool wird ohne weitere Optionen auf dem Quell-Server aufgerufen:
 +
 +<​code>​
 +invis:~ # bbcrr
 +</​code>​
 ===== Durchführung und Kontrolle ===== ===== Durchführung und Kontrolle =====
  
Zeile 313: Zeile 328:
  
 ==== Kontrolle ==== ==== Kontrolle ====
- 
  
 Zur Kontrolle der Datensicherung versendet das Sicherungssystem im Fehlerfall oder wahlweise auch immer Status-Mails an einen in der Konfiguration festzulegenden Administrator. Einen kleinen Haken hat die Sache jedoch, läuft die Datensicherung aufgrund eines Problems gar nicht erst an, wird leider auch keine Mail versendet. Zur Kontrolle der Datensicherung versendet das Sicherungssystem im Fehlerfall oder wahlweise auch immer Status-Mails an einen in der Konfiguration festzulegenden Administrator. Einen kleinen Haken hat die Sache jedoch, läuft die Datensicherung aufgrund eines Problems gar nicht erst an, wird leider auch keine Mail versendet.
Zeile 320: Zeile 334:
  
 Nebenstehende Abbildungen zeigen den Idealfall ​ - alle 4 Datensicherungsaufgaben wurden erfolgreich durchgeführt - sowie eine gerade aktive Datensicherung. In beiden Fällen ist auf der Datensicherungplatte noch ausreichend Platz vorhanden. Weiterhin wird angezeigt, wie viel Zeit bis zur nächsten Datensicherung verbleibt. Dieser Zeitraum kann in der Konfiguration des invis-Portals individuell eingestellt werden. Ist eine Datensicherung überfällig wird dies ebenfalls angezeigt. Dabei ändert sich die Farbe der angezeigten Tage selbstverständlich in rot. Nebenstehende Abbildungen zeigen den Idealfall ​ - alle 4 Datensicherungsaufgaben wurden erfolgreich durchgeführt - sowie eine gerade aktive Datensicherung. In beiden Fällen ist auf der Datensicherungplatte noch ausreichend Platz vorhanden. Weiterhin wird angezeigt, wie viel Zeit bis zur nächsten Datensicherung verbleibt. Dieser Zeitraum kann in der Konfiguration des invis-Portals individuell eingestellt werden. Ist eine Datensicherung überfällig wird dies ebenfalls angezeigt. Dabei ändert sich die Farbe der angezeigten Tage selbstverständlich in rot.
- 
  
 ===== Daten wiederherstellen ===== ===== Daten wiederherstellen =====
  
-Die Wiederherstellung von Daten unterscheidet sich geringfügig,​ je nach dem, ob das Sicherungsziel externe Festplatten oder ein Sicherungsserver ist. +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:
  
 <​code>​ <​code>​
Zeile 334: Zeile 347:
 </​code>​ </​code>​
  
-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.+Dies gilt gleichermaßen für **invis-rdbu** und **invis-bbu**.
  
-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.+Jetzt kann die Sicherungsplatte verbunden ​und eingehängt ​werden:
  
-Um Daten wiederherzustellen müssen Sie auf der Kommandozeile in das Verzeichnis der Sicherung wechseln. Je nach Sicherungsziel müssen Sie unterschiedliche Wege gehen.+<​code>​ 
 +invis:~ # mount /dev/backup /​mnt/​udevsync 
 +</​code>​
  
-**Sicherungsfestplatte**+=== Datensicherungsserver ===
  
-Hier muss zunächst ​dafür Sorge getragen werden, dass das Anschließen der Platte von der Daten wiederhergestellt werden sollen, keine neue Datensicherung auslöst. Für diesen Zweck bringt die Sicherungssoftware des invis-Servers ein eigenes Script mit. Es ist vor dem Verbinden der Festplatte einfach ohne weiteren Parameter aufzurufen:+In diesem Fall melden Sie sich zunächst ​per SSH am Sicherungsserver an:
  
 <​code>​ <​code>​
-invis:~ # udbrestore+invis:~ # ssh root@sicherungsserver 
 +sicherungsserver:​~ #
 </​code>​ </​code>​
  
 +Die Abfrage eines Passworts erfolgt nicht, da die Authentifikation via Public-Key Verfahren erfolgt.
 +==== Datenwiederherstellung mit rdiff-backup ====
  
-Jetzt kann die Sicherungsplatte verbunden ​und eingehängt ​werden:+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.
  
-<​code>​ +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. 
-invis:~ # mount /dev/backup /​mnt/​udevsync + 
-</​code>​+=== 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.
  
-Jetzt kann ins Verzeichnis der Sicherungen gewechselt werden:+Ist die Festplatte angeschlossen und gemountet, ​kann ins Verzeichnis der Sicherungen gewechselt werden:
  
 <​code>​ <​code>​
Zeile 373: Zeile 393:
 Die Nutzdaten Ihres Unternehmens finden Sie unter "/​home"​ bzw. "/​srv"​. In diesen Verzeichnissen finden Sie 1:1 die Datenstruktur vor wie auf den Quellverzeichnissen des Servers. Um Daten der letzten Sicherung wiederherzustellen müssen Sie lediglich die entsprechende Datei oder das Verzeichnis aus dem Sicherungsverzeichnis an einen Ort Ihrer Wahl kopieren. Am einfachsten können Sie dass mit Hilfe des auf jedem invis-Server installierten Dateimanagers "​Midnight Commander"​ (//​**mc**//​) erledigen. Die Nutzdaten Ihres Unternehmens finden Sie unter "/​home"​ bzw. "/​srv"​. In diesen Verzeichnissen finden Sie 1:1 die Datenstruktur vor wie auf den Quellverzeichnissen des Servers. Um Daten der letzten Sicherung wiederherzustellen müssen Sie lediglich die entsprechende Datei oder das Verzeichnis aus dem Sicherungsverzeichnis an einen Ort Ihrer Wahl kopieren. Am einfachsten können Sie dass mit Hilfe des auf jedem invis-Server installierten Dateimanagers "​Midnight Commander"​ (//​**mc**//​) erledigen.
  
-Nach dme Wiederherstellen der Daten ist die Sicherungsfestplatte wieder auszuhängen und vom Server zu trennen:+Nach dem Wiederherstellen der Daten ist die Sicherungsfestplatte wieder auszuhängen und vom Server zu trennen:
  
 <​code>​ <​code>​
 invis:~ # umount /​mnt/​udevsync invis:~ # umount /​mnt/​udevsync
 </​code>​ </​code>​
- +=== Wiederherstellen ​älterer Dateiversionen ​mittels 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. +
- +
-Wechseln sie jetzt ins Sicherungsverzeichnis:​ +
- +
-<​code>​ +
-sicherungsserver:​~ # cd /​srv/​backup +
-</​code>​ +
- +
-==== Wiederherstellen ​von Daten mittels rdiff-backup ====+
  
 Gehen wir im folgenden Beispiel von einer Sicherung auf eine Datensichrungsfestplatte aus und entsprechend der obigen Anleitung vor: Gehen wir im folgenden Beispiel von einer Sicherung auf eine Datensichrungsfestplatte aus und entsprechend der obigen Anleitung vor:
Zeile 410: 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 442: 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**
 +
 +**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