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 12:55]
flacco [Installation]
invis_server_wiki:dasi [2020/06/07 14:47]
flacco [SSH vorbereiten]
Zeile 35: Zeile 35:
 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. 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 
 + 
 +**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. ​ Sicherungsserver können via SSH oder SMB-Freigaben angesprochen werden. ​
Zeile 51: Zeile 70:
 ==== Sicherung auf externe Festplatten ==== ==== Sicherung auf externe Festplatten ====
  
-=== Installation === 
-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>​ 
  
 === Einrichten und registrieren der Datensicherungsfestplatten === === Einrichten und registrieren der Datensicherungsfestplatten ===
Zeile 120: 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 161: 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 180: 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
-</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. +# Dasimonitor aktivieren ​sollte nicht erforderlich sein! 
- +dasiMonitorAct:0
-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>​ </​code>​
  
-von den führenden Kommentarzeichen (Doppel-Slash '/')In dieser Zeile können Sie auch den gewünschten Sicherungszyklus vorgebenDas Portal wird dann deutlich darauf hinweisen, wenn eine Sicherung nicht wie geplant durchgeführt wird.+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.
  
-Die Anzeige erfolgt im Portal auf der Seite "Status".+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.
  
 === Testen === === Testen ===
Zeile 214: 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 223: 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 442: Zeile 454:
 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 ======
  
  • invis_server_wiki/dasi.txt
  • Zuletzt geändert: 2021/06/01 09:40
  • von flacco