Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
invis_server_wiki:dasi [2019/01/08 08:51] flacco [Daten wiederherstellen] |
invis_server_wiki:dasi [2020/06/07 15:49] flacco [Datenwiederherstellung mit rdiff-backup] |
||
---|---|---|---|
Zeile 2: | Zeile 2: | ||
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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Für bilanzierungspflichtige Unternehmen schreibt der Gesetzgeber eine tägliche Datensicherung vor. Dies ist gerade bei Verwendung von externen Festplatten als Sicherungsziel, die dann auch täglich gewechselt werden müssen zu bedenken. Mit einem Server als Sicherungsziel ist das durch Automation natürlich einfacher zu realisieren. | ||
+ | |||
+ | Unabhängig vom gewählten Sicherungsziel gilt, dass eine Datensicherung nur dann als Datensicherung gilt, wenn die gesicherten Daten räumlich getrennt von den Originaldaten aufbewahrt werden. Dabei meint "räumlich getrennt" zumindest einen anderen Brandabschnitt. Dies kann auch in kleineren Büros die nicht über getrennte Brandabschnitte verfügen durch Aufbewahrung der Sicherungsmedien in einem Brandschutztresor gewährleistet werden. In einem solchen Fall kommt ein lokal betriebener Datensicherungsserver allerdings nicht in Frage. Sie können ihn ja kaum im Tresor betreiben... | ||
===== interne Sicherungen ===== | ===== interne Sicherungen ===== | ||
Zeile 13: | Zeile 21: | ||
^ alldump | Samstags um 6:00 Uhr | Sicherung aller Datenbanken des Servers mit Ausnahme der Kopano-Datenbank | | ^ alldump | Samstags um 6:00 Uhr | Sicherung aller Datenbanken des Servers mit Ausnahme der Kopano-Datenbank | | ||
^ adbackup | Täglich um 23:30 | Sicherung des Active Directory / ab invis-Server 14.0 | | ^ adbackup | Täglich um 23:30 | Sicherung des Active Directory / ab invis-Server 14.0 | | ||
+ | |||
+ | Die genannten Zyklen sind die Voreinstellungen nach der Installation eines invis-Servers. Sie lassen sich individuell anpassen. Vorgenommen werden die Einstellungen in: <file>/etc/cron.d/invis.cron</file> | ||
Diese Sicherungen erfolgen zunächst auf die lokalen Festplatten des Servers selbst und sind in der Freigabe Archiv im Unterverzeichnis "sicherungen" zu finden. Damit diese Sicherungen nicht bis ins unermessliche Platz belegen werden die verschiedenen Sicherungsverzeichnisse zyklisch bereinigt. Das maximale Alter der Sicherungen ist in "Tagen" in <file>/etc/invis/invis.conf</file> einstellbar und in der Regel auf 21 oder 42 Tage voreingestellt. Ältere Sicherungen werden gelöscht. | Diese Sicherungen erfolgen zunächst auf die lokalen Festplatten des Servers selbst und sind in der Freigabe Archiv im Unterverzeichnis "sicherungen" zu finden. Damit diese Sicherungen nicht bis ins unermessliche Platz belegen werden die verschiedenen Sicherungsverzeichnisse zyklisch bereinigt. Das maximale Alter der Sicherungen ist in "Tagen" in <file>/etc/invis/invis.conf</file> einstellbar und in der Regel auf 21 oder 42 Tage voreingestellt. Ältere Sicherungen werden gelöscht. | ||
Zeile 23: | Zeile 33: | ||
===== externe Sicherungen ===== | ===== externe Sicherungen ===== | ||
- | Basierend auf unserer Empfehlung eine invis-Server Installation unter Nutzung von Logical-Volume-Management durchzuführen haben wir ein eigenes Datensicherungswerkzeug entwickelt, welches Datensicherung durch Kombination von LV-Snapshots und "//**rdiff-backup**//" durchführt. | + | Basierend auf unserer Empfehlung eine invis-Server Installation unter Nutzung von Logical-Volume-Management durchzuführen haben wir ein eigene Datensicherungswerkzeuge entwickelt, welche Datensicherung durch Kombination von LV-Snapshots und "//**rdiff-backup**//" oder "//**borg**//" durchführt. |
- | Als Sicherungsziele kommen wahlweise oder in Kombination externe USB bzw. eSATA Festplatten und ein gesonderter Sicherungsserver in Frage. | + | * **invis-rdbu** - Nutzt rdiff-backup |
+ | * **invis-bbu** - Nutzt borg Backup | ||
- | Sicherungsserver können von **//rdiff-backup//** direkt via "rsync over SSH" oder SMB-Freigaben angesprochen werden. Bei der Nutzung von SMB-Freigaben gehen leider die Besitz- und Zugriffsrechte der gesicherten Dateien verloren. | + | **Tipps zur Auswahl:** |
+ | |||
+ | * ListenpunktVon beiden Paketen ist **invis-bbu** das neuere. Grund für die Entwicklung eines zweiten Tools waren immer wieder auftretende Probleme mit den von //**rdiff-backup**// erzeugten Backup-Repositories. In einzelnen Fällen traten vor allem durch eine ungewollte Unterbrechung der Datensicherung Fehler in den Repositories auf, die diese unbrauchbar machten. In der Folge führt dies dazu, dass alle weiteren Datensicherungen in ein solchermaßen beschädigtes Repository fehl schlagen. | ||
+ | |||
+ | * Zur Stabilität der von Borg-Backup erzeugten Repositories können wir derzeit, einfach aufgrund mangelnder Erfahrung, noch keine Aussagen machen. | ||
+ | |||
+ | * Ein großer Vorteil von borg Backup ist die Tatsache, dass dessen Repositories von vorne herein verschlüsselt werden können. D.h. es ist keine Datenträgerverschlüsselung erforderlich. Gerade bei Sicherungsmedien die sensible Datenenthalten und außer Haus aufbewahrt werden ist dies ein unschätzbarer Vorteil. | ||
+ | |||
+ | * Beide Systeme erlauben das Wiederherstellen älterer Dateiversionen aus der Sicherung, was mit borg ein gutes Stück einfacher geht als mit rdiff-backup. | ||
+ | |||
+ | Die Installation ist denkbar einfach. Installieren Sie zunächst eines der beiden Software-Pakete, unabhängig davon, ob Sie auf externe Platten oder einen Sicherungsserver sichern wollen. | ||
+ | |||
+ | <code> | ||
+ | linux:~ # zypper in invis-bbu | ||
+ | </code> | ||
+ | |||
+ | Als Sicherungsziele kommen wahlweise oder in Kombination externe USB bzw. eSATA Festplatten sowie ein gesonderter Sicherungsserver in Frage. | ||
+ | |||
+ | Sicherungsserver können via SSH oder SMB-Freigaben angesprochen werden. | ||
+ | |||
+ | //**Achtung:** Bei der Nutzung von SMB-Freigaben gehen leider die Besitz- und Zugriffsrechte der gesicherten Dateien verloren.// | ||
Beim Einsatz externer Festplatten nutzen wir die Möglichkeiten der UDEV-Hardware Verwaltung unter Linux. Die Sicherungsplatten werden dem Server bekannt gemacht und er startet die Datensicherung automatisch, wenn "genau diese" Festplatten mit dem Server verbunden werden. Andere Festplatten lösen keine Sicherung aus. Wichtig zu wissen, ist dass das Verbinden der Festplatte der auslösende Moment ist. | Beim Einsatz externer Festplatten nutzen wir die Möglichkeiten der UDEV-Hardware Verwaltung unter Linux. Die Sicherungsplatten werden dem Server bekannt gemacht und er startet die Datensicherung automatisch, wenn "genau diese" Festplatten mit dem Server verbunden werden. Andere Festplatten lösen keine Sicherung aus. Wichtig zu wissen, ist dass das Verbinden der Festplatte der auslösende Moment ist. | ||
- | //**Achtung:**Die Festplatte mit dem Server verbunden zu lassen sorgt **nicht** für kontinuierlich Datensicherungen.// | + | //**Achtung:** Die Festplatte mit dem Server verbunden zu lassen sorgt **nicht** für kontinuierlich Datensicherungen.// |
//**Achtung:** Vor dem Gesetz gilt eine Datensicherung nur dann als Datensicherung, wenn die Sicherungen **räumlich getrennt** von den originalen Daten aufbewahrt werden. Dabei meint "räumlich getrennt" mindestens einen anderen Brandabschnitt. D.h. Gesicherte Daten müssen durch mindestens eine Brandschutzwand und Brandschutztür von den Originaldaten getrennt sein. Ein Tresor mit Brandschutzfunktion erfüllt diese Forderung ebenfalls.// | //**Achtung:** Vor dem Gesetz gilt eine Datensicherung nur dann als Datensicherung, wenn die Sicherungen **räumlich getrennt** von den originalen Daten aufbewahrt werden. Dabei meint "räumlich getrennt" mindestens einen anderen Brandabschnitt. D.h. Gesicherte Daten müssen durch mindestens eine Brandschutzwand und Brandschutztür von den Originaldaten getrennt sein. Ein Tresor mit Brandschutzfunktion erfüllt diese Forderung ebenfalls.// | ||
Zeile 37: | Zeile 68: | ||
Weiterhin fordert der Gesetzgeber von Bilanz-pflichtigen Unternehmen eine tägliche Datensicherung. Dies bedeutet für die Sicherung auf externe Festplatten, dass Sie mindestens 2 Platten im Wechsel nutzen sollten, so dass eine immer an einem gesicherten Aufbewahrungsort liegt. | Weiterhin fordert der Gesetzgeber von Bilanz-pflichtigen Unternehmen eine tägliche Datensicherung. Dies bedeutet für die Sicherung auf externe Festplatten, dass Sie mindestens 2 Platten im Wechsel nutzen sollten, so dass eine immer an einem gesicherten Aufbewahrungsort liegt. | ||
- | ==== Installation und Konfiguration ==== | + | ==== Sicherung auf externe Festplatten ==== |
- | Die Installation ist denkbar einfach. Installieren Sie zunächst das Software-Paket "invis-rdbu", unabhängig davon, ob Sie auf externe Platten oder einen Sicherungsserver sichern wollen. | ||
- | |||
- | <code> | ||
- | linux:~ # zypper in invis-rdbu | ||
- | </code> | ||
=== Einrichten und registrieren der Datensicherungsfestplatten === | === Einrichten und registrieren der Datensicherungsfestplatten === | ||
+ | |||
+ | Bei der Initialisierung externer Sicherungsfestplatten spielt es keine Rolle, für welches Sicherungssystem Sie sich entschieden haben. Die Vorgehensweise ist bei beiden Systemen identisch. | ||
Legen sie auf einer externen Festplatte eine einzige Partition an und formatieren Sie diese mit einem "ext3" oder "ext4" Dateisystem. Trennen und verbinden Sie die Festplatte nach der Formatierung neu mit Ihrem Server. Warten Sie ein paar Sekunden. | Legen sie auf einer externen Festplatte eine einzige Partition an und formatieren Sie diese mit einem "ext3" oder "ext4" Dateisystem. Trennen und verbinden Sie die Festplatte nach der Formatierung neu mit Ihrem Server. Warten Sie ein paar Sekunden. | ||
Zeile 105: | 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 146: | Zeile 174: | ||
<code> | <code> | ||
- | # Konfigurationsdatei fuer invis-rdbudisk | + | # Konfigurationsdatei fuer invis-bbudisk |
- | # (c) 2010-2016 Stefan Schaefer - invis-server.org | + | # (c) 2010-2020 Stefan Schaefer - invis-server.org |
# Zielhost | # Zielhost | ||
targetHost:localhost | targetHost:localhost | ||
- | targetDirUDEV:/mnt/udevsync/rdbackups | + | targetDirUDEV:/mnt/udevsync/borgbackups |
# LVM Daten | # LVM Daten | ||
volumeGroup:system | volumeGroup:system | ||
# Mehrere Volume Namen durch Leerzeichen trennen | # Mehrere Volume Namen durch Leerzeichen trennen | ||
- | sourceVolume:root srv home 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:20G | + | # Name des Snapshot-Volumes |
+ | snapshotVolume:invisdiskbackup | ||
# Admin | # Admin | ||
Zeile 165: | Zeile 194: | ||
# Mail-Absender und -Empfaenger | # Mail-Absender und -Empfaenger | ||
- | mailTo:info@local-net.loc | + | mailTo:hilfe@fsproductions.de |
- | mailFrom:backup@local-net.loc | + | mailFrom:backup@invis-server.org |
# nur im Fehlerfall oder immer Mails versenden. | # nur im Fehlerfall oder immer Mails versenden. | ||
# Werte: always, failure | # Werte: always, failure | ||
mailWhen:failure | mailWhen:failure | ||
- | #Backupuser | + | # borg-backup Optionen |
- | buServerUser:root | + | bbOptions:--exclude-from /etc/invis/backup-exclude-list --one-file-system -s |
+ | |||
+ | # Dasimonitor aktivieren - sollte nicht erforderlich sein! | ||
+ | dasiMonitorAct:0 | ||
</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. |
- | Das Web-Portal des invis-Servers ist ebenfalls in der Lage über Erfolg oder Misserfolg der Datensicherung zu informieren. Diese Funktion muss zunächst in der Konfiguration des invis-Portals frei geschaltet werden. Öffnen Sie für diesen Zweck die Datei: <file>/etc/invis/portal/config.php</file> und befreien Sie die Zeile: | + | 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. |
- | <code> | + | 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. |
- | // Bitte folgende Zeile von den Kommentarzeichen befreien, wenn udevsync zur Datensicherung verwendet wird. | + | |
- | $STATUS_BACKUP_TIMER = 3; | + | |
- | </code> | + | |
- | + | ||
- | von den führenden Kommentarzeichen (Doppel-Slash '/'). In dieser Zeile können Sie auch den gewünschten Sicherungszyklus vorgeben. Das Portal wird dann deutlich darauf hinweisen, wenn eine Sicherung nicht wie geplant durchgeführt wird. | + | |
- | + | ||
- | Die Anzeige erfolgt im Portal auf der Seite "Status". | + | |
=== Testen === | === Testen === | ||
Zeile 199: | 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 208: | 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 264: | 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 Script, welches 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 Scripts, welche 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 280: | Zeile 317: | ||
Wird auf externe Festplatten, ist das Verbinden der Platte mit dem Server das auslösende Ereignis. Das bedeutet auch, dass Sie die Sicherungsfestplatte nach erfolgter Sicherung wieder vom Server trennen müssen. | Wird auf externe Festplatten, ist das Verbinden der Platte mit dem Server das auslösende Ereignis. Das bedeutet auch, dass Sie die Sicherungsfestplatte nach erfolgter Sicherung wieder vom Server trennen müssen. | ||
+ | |||
+ | {{ :invis_server_wiki:status_dasi.png?|}} | ||
//**Achtung**: Lassen Sie eine Sicherungsfestplatte am Server angeschlossen, werden **nicht** automatisch regelmäßige Datensicherungen durchgeführt.// | //**Achtung**: Lassen Sie eine Sicherungsfestplatte am Server angeschlossen, werden **nicht** automatisch regelmäßige Datensicherungen durchgeführt.// | ||
- | Die ideale Vorgehensweise ist eine abwechselnde Datensicherung auf zwei Festplatten. D.h. Eine der Festplatten ist mit dem Server verbunden, während die zweite an einem "sicheren" Ort aufbewahrt wird. Tauschen Sie idealerweise zu einem Zeitpunkt an dem wenig oder nicht auf dem Server gearbeitet wird die Festplatten aus. | + | Die ideale Vorgehensweise ist eine abwechselnde Datensicherung auf zwei Festplatten. D.h. Eine der Festplatten ist mit dem Server verbunden, während die |
+ | zweite an einem "sicheren" Ort aufbewahrt wird. Tauschen Sie idealerweise zu einem Zeitpunkt an dem wenig oder nicht auf dem Server gearbeitet wird die Festplatten aus. | ||
Sie können die verbundene Festplatte dabei einfach ohne weitere Vorbereitung vom Server trennen, die logische Trennung wird nach erfolgter Sicherung bereits vom Sicherungsprogramm vorgenommen. | Sie können die verbundene Festplatte dabei einfach ohne weitere Vorbereitung vom Server trennen, die logische Trennung wird nach erfolgter Sicherung bereits vom Sicherungsprogramm vorgenommen. | ||
+ | |||
+ | ==== 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. | ||
+ | |||
+ | Sie können jederzeit den Status der Datensicherung auf der Status-Seite Ihres invis-Portals überprüfen. Eine Anmeldung am Portal ist dafür nicht notwendig. Die Statusdaten werden Nutzern des lokalen Netzes immer gezeigt.{{ :invis_server_wiki:screenshot_inivis-portal_dasi_20190617.png|}} | ||
+ | |||
+ | 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. 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: | + | 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. |
+ | |||
+ | ==== 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: | ||
<code> | <code> | ||
- | invis: # udevrestore | + | invis: # udbrestore |
</code> | </code> | ||
+ | |||
+ | Dies gilt gleichermaßen für **invis-rdbu** und **invis-bbu**. | ||
+ | |||
+ | Jetzt kann die Sicherungsplatte verbunden und eingehängt werden: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # mount /dev/backup /mnt/udevsync | ||
+ | </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> | ||
+ | |||
+ | ==== 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. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Ist die Festplatte angeschlossen und gemountet, kann ins Verzeichnis der Sicherungen gewechselt werden: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # cd /mnt/udevsync/rdbackups | ||
+ | </code> | ||
+ | |||
+ | Unterhalb dieses Verzeichnisses befinden sich für jede Sicherungsquelle ein Unterverzeichnis: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # ls -l | ||
+ | drwxr-xr-x 19 root root 4096 4. Okt 16:06 home | ||
+ | drwxr-xr-x 20 root root 4096 1. Dez 12:30 root | ||
+ | drwxr-xr-x 12 root root 4096 1. Dez 13:38 srv | ||
+ | drwxr-xr-x 13 root root 4096 1. Dez 12:05 var | ||
+ | </code> | ||
+ | |||
+ | 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 dem Wiederherstellen der Daten ist die Sicherungsfestplatte wieder auszuhängen und vom Server zu trennen: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # umount /mnt/udevsync | ||
+ | </code> | ||
+ | === Wiederherstellen älterer Dateiversionen mittels rdiff-backup ==== | ||
+ | |||
+ | Gehen wir im folgenden Beispiel von einer Sicherung auf eine Datensichrungsfestplatte aus und entsprechend der obigen Anleitung vor: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # udbrestore | ||
+ | invis:~ # mount /dev/backup /mnt/udevsync | ||
+ | </code> | ||
+ | |||
+ | Wechseln Sie jetzt ins Verzeichnis der Sicherungen: | ||
+ | |||
+ | <code> | ||
+ | invis:~ # cd /mnt/udevsync/rdbackups | ||
+ | invis:/mnt/udevsync/rdbackups # | ||
+ | </code> | ||
+ | |||
+ | Dort befinden sich die Sicherungen. In der Regel sind dies die Verzeichnisse ''home'', ''srv'', ''var'' und ''root''. Nehmen wir an Sie wollen das persönliche Verzeichnis eines Benutzer in einem älteren Sicherungsstand wiederherstellen. Dazu sollten Sie zunächst nachschauen, welche Sicherungen auf dem Datenträger vorhanden sind: | ||
+ | |||
+ | <code> | ||
+ | invis:/mnt/udevsync/rdbackups # rdiff-backup --list-increments home/hmohr/ | ||
+ | Found 4 increments: | ||
+ | hmohr.2018-11-30T19:43:23+01:00.dir Fri Nov 30 19:43:23 2018 | ||
+ | hmohr.2018-12-04T19:58:57+01:00.dir Tue Dec 4 19:58:57 2018 | ||
+ | hmohr.2019-01-11T20:49:56+01:00.dir Fri Jan 11 20:49:56 2019 | ||
+ | hmohr.2019-01-15T19:20:28+01:00.dir Tue Jan 15 19:20:28 2019 | ||
+ | Current mirror: Thu Jun 13 21:20:53 2019 | ||
+ | </code> | ||
+ | |||
+ | Das Beispiel zeigt insgesamt neben der letzten aktuellen Sicherung insgesamt 4 ältere Sicherungsstände. (Nebenbei bemerkt ist dies ein trauriges Beispiel von Datensicherungseifer; ganze 4 Sicherungen in 8 Monaten und die letzte ist bereits 5 Monate alt...) | ||
+ | |||
+ | Um jetzt die älteste Sicherung wiederherzustellen gehen Sie wie folgt vor. Legen Sie zunächst ein temporäres Wiederherstellungsverzeichnis an: | ||
+ | |||
+ | <code> | ||
+ | invis:/mnt/udevsync/rdbackups # mkdir /srv/restore/hmohr | ||
+ | </code> | ||
+ | |||
+ | Jetzt starten Sie die Wiederherstellung: | ||
+ | |||
+ | <code> | ||
+ | invis:/mnt/udevsync/rdbackups # rdiff-backup --restore-as-of 2018-11-30 home/hmohr/ /srv/restore/hmohr/ | ||
+ | </code> | ||
+ | |||
+ | Dabei erwartet die Option ''restore-as-of'' die Angabe des Datums des gewünschten Sicherungsstandes. Wählen Sie ein Datum welches zuvor mit der Option ''list-increments'' aufgezeigt wurde. | ||
... work in progress ... | ... work in progress ... | ||
- | ===== Aufräumen ===== | + | ==== Datenwiederherstellung mit borg Backup ==== |
+ | ===== Sicherung Überwachen und ggf. Aufräumen ===== | ||
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.... | ||
Zeile 304: | Zeile 459: | ||
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. | ||
+ | ===== Sicherungsverlauf im invis-Portal anzeigen ===== | ||
+ | |||
+ | Das Web-Portal des invis-Servers ist ebenfalls in der Lage über Erfolg oder Misserfolg der Datensicherung zu informieren. Diese Funktion muss zunächst in der Konfiguration des invis-Portals frei geschaltet werden. Öffnen Sie für diesen Zweck die Datei: <file>/etc/invis/portal/config.php</file> und befreien Sie die Zeile: | ||
+ | |||
+ | <code> | ||
+ | // Bitte folgende Zeile von den Kommentarzeichen befreien, wenn udevsync zur Datensicherung verwendet wird. | ||
+ | $STATUS_BACKUP_TIMER = 3; | ||
+ | </code> | ||
+ | |||
+ | von den führenden Kommentarzeichen (Doppel-Slash '/'). In dieser Zeile können Sie auch den gewünschten Sicherungszyklus vorgeben. Das Portal wird dann deutlich darauf hinweisen, wenn eine Sicherung nicht wie geplant durchgeführt wird. | ||
+ | |||
+ | Die Anzeige erfolgt im Portal auf der Seite "Status". | ||
====== Kopano Datensicherung ====== | ====== Kopano Datensicherung ====== | ||