Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:dasi [2016/01/13 18:23]
flacco [Einrichten der Datensicherung auf externe Festplatten]
+++ invis_server_wiki:dasi [2019/01/08 08:32]
flacco [interne Sicherungen]
@@ Zeile 1: / Zeile 1: @@
 ====== invis Server Datensicherung ======
+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.
+===== interne Sicherungen =====
+Interne Sicherungen sind zeitgesteuerte Sicherungen wichtiger Datenbestände. Während der Installation werden verschiedene Datensicherungsaufgaben angelegt:
+^ Aufgabe / Script  ^ Zyklus  ^ Bemerkung  ^
+^ kbackup  | Mo, Mi, Fr, So jeweils um 3:00 Uhr  | Sicherung der Kopano-Konten / ermöglicht das wiederherstellen einzelner Objekte (Mailordner, Mails usw. z.B. bei versehentlichem Löschen  |
+^ kdbdump  | Di, Do, Sa jeweils um 3:00 Uhr  | Sicherung der Kopano Datenbank / dient der Wiederherstellung der Kopano Datenbank im Notfall  |
+^ dwdatasnapshot  | Samstags um 1:30 Uhr  | Sicherung des Dokuwiki-Datenbestandes  |
+^ 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  |
+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.
+Alle internen Sicherungen werden von der externen Sicherung mit erfasst.
+//**Hinweis:** Alle in der Tabelle genannten Sicherungsscripts können auch manuell auf der Kommandozeile des Servers aufgerufen werden.//
+===== 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.
@@ Zeile 26: / Zeile 46: @@
 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.
+=== Registrieren der Sicherungsfestplatte ===
 Während der erwähnten wenigen Sekunden Wartezeit können Sie dem Server bei der Hardware-Erkennung zuschauen:
@@ Zeile 53: / Zeile 75: @@
 </code>
-Das Script sollte Ihnen zunächst die Bezeichnung der Festplatte (sdX) und der darauf angelegten Partition (sdX1) anzeigen. Ist dies nicht der Fall, sondern statt dessen werden sinnlose Informationen gezeigt, brechen Sie das Script bitte unmittelbar mit der Tastenkombination STRG+C ab. Wie es in diesem Fall weitergeht, lesen Sie weiter unten.
+Das Script sollte Ihnen zunächst die Bezeichnung der Festplatte (sdX) und der darauf angelegten Partition (sdX1) anzeigen. Durchsucht werden die letzten 3 Stunden des Systemjournals auf entsprechende Hotplug-Events. Wird keine geeignete Festplatte gefunden, bricht das Script ab.
-Das Script //**udbadddisk**// ermittelt Informationen zur eindeutigen Identifikation der Festplatte und generiert daraus eine UDEV-Regel in der Datei: <file>/etc/udev/rules.d/10-backupdisk.rules</file>
+Ist eine Sicherungsplatte schon länger als 3 Stunden mit dem Server verbunden und Sie kennen den Namen der darauf eingerichteten Sicherungspartition, können Sie diese Partition auch als Aufrufparameter angeben:
+<code>
+linux:~ udbadddisk sdc1
+Gefundene Festplatte: sdc
+Gefundene Partition: sdc1
+Gefundenes Merkmal Partitionsgröße: 3907027120
+Gefundenes Merkmal Seriennummer: FDC0FD20EF00000FD0FCC4F2FFFFFF
+Datensicherungsplatte hinzugefügt
+</code>
+Das Script //**udbadddisk**// ermittelt Informationen zur eindeutigen Identifikation der Festplatte und generiert daraus eine UDEV-Regel in der Datei: <file>/etc/udev/rules.d/80-backupdisk.rules</file>
 Hier die im oben gezeigten Beispiel entstandene UDEV-Regel:
 <code>
-SUBSYSTEMS=="usb", KERNEL=="sd*", ATTRS{serial}=="FDC0FD20EF00000FD0FCC4F2FFFFFF", ATTR{size}=="3907027120", SYMLINK+="backup", RUN+="/usr/bin/udbdiskplugged", OPTIONS="last_rule"
+SUBSYSTEMS=="usb", KERNEL=="sd*", ATTRS{serial}=="FDC0FD20EF00000FD0FCC4F2FFFFFF", ATTR{size}=="3907027120", SYMLINK+="backup", RUN+="/usr/bin/udbdiskplugged"
 </code>
-Sie besagt, wenn ein Gerät des Typs "sd" am USB-Bus mit der Seriennummer "FDC0FD20EF00000FD0FCC4F2FFFFFF" und der genannten Partitionsgröße erkannt wird, soll unter "/dev" ein Symlink unter dem Namen "backup" angelegt werden, der auf das gefundene Gerät verweist (/dev/sdX1). Danach soll das Script //**udbdiskplugged**// ausgeführt und keine weitere Regel angewendet werden.
+Sie besagt, wenn ein Gerät des Typs "sd" am USB-Bus mit der Seriennummer "FDC0FD20EF00000FD0FCC4F2FFFFFF" und der genannten Partitionsgröße erkannt wird, soll unter "/dev" ein Symlink unter dem Namen "backup" angelegt werden, der auf das gefundene Gerät verweist (/dev/sdX1). Danach soll das Script //**udbdiskplugged**// ausgeführt werden.
+=== Sicherung konfigurieren ===
+Sind alle Sicherungsfestplatten vorbereitet, kann die Sicherung selbst konfiguriert werden. Dies erledigt das Script //**udbconf**//
+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:
+  * **root**
+  * **home**
+  * **srv**
+  * **var**
+Sollten Sie die Namen der Volume-Group und der darin liegenden Volumes nicht mehr wissen, können Sie sie mit folgenden Kommandos anzeigen:
+**Volume-Group scannen:**
+<code>
+linux:~ # vgscan -v
+</code>
+**Logical Volumes scannen:**
+<code>
+linux:~ # lvscan -v
+</code>
-Der Parameter "last_rule" wird leider von neueren UDEV-Versionen nicht mehr berücksichtigt. Es kann also sein, das weitere UDEV-Regeln, auf die das Gerät passt ausgeführt werden. Ist in diesem Fall aber kein Beinbruch.
+Weiterhin müssen Sie die Größe des zu verwendenden Snapshot-Volumes festlegen. Die maximal mögliche Größe zeigt //**udbconf**// an. Normalerweise sollte eine Snapshot-Volume-Größe von 20GB ausreichen.
-Sind alle Festplatten vorbereitet, kann die Sicherung selbst konfiguriert werden. Dies erledigt das Script //**udbconf**//:
+**udbconf starten:**
 <code>
@@ Zeile 81: / Zeile 142: @@
 Konfiguration abgeschlossen
 </code>
-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.
 Hier die resultierende Konfigurationsdatei:
@@ Zeile 116: / Zeile 175: @@
 </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</code> angepasst werden.
+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.
 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:
@@ Zeile 125: / Zeile 184: @@
 </code>
-von den führenden Kommentarzeichen ('//'). 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.
+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 ===
+Vor allem, wenn Sie die Einrichtung remote vornehmen ist es wichtig einen Test der Sicherung durchführen zu können, ohne, dass Ihnen helfende Hände zur Seite stehen. Dazu müssen Sie einen "uevent" triggern, damit die neue UDEV Erkennungsregel angewendet wird:
+<code>
+linux:~ echo change > /sys/block/sdX/uevent
+</code>
 ==== 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.
+=== SSH vorbereiten ===
+Damit die Sicherung über SSH erfolgen kann, muss sich der Benutzer "root" des Quell-Servers ohne Passwort per SSH am Sicherungsserver anmelden können. Es ist nicht notwendig, dass auch auf dem Sicherungsserver das Konto des Benutzers "root" verwendet wird. Es genügt dort ein Benutzerkonto, welches Schreibrecht im Zielverzeichnis der Datensicherung hat.
+Die passwortlose Anmeldung gelingt, wenn die Authentifizierung am Sicherungsserver mit einem Schlüssel erfolgt. Dieser Schlüssel kann auf dem Quellserver (angemeldet als Benutzer "root") einfach generiert werden:
+<code>
+Generating public/private rsa key pair.
+Enter file in which to save the key (/root.sshid_rsa):
+Enter passphrase (empty for no passphrase):
+Enter same passphrase again:
+Your identification has been saved in /root/.ssh/id_rsa.
+Your public key has been saved in /root/.ssh/id_rsa.pub.
+The key fingerprint is:
+fb:8b:20:3d:97:25:09:e7:ef:fe:63:d1:b3:49:1f:e0 [MD5] root@server
+The key's randomart image is:
++--[ RSA 2048]----+
+|                 |
+|                 |
+|      . .        |
+|       + .   .   |
+|        S . ...  |
+|     .   *  .E+. |
+|    . + + .  o =.|
+|     . + +  o o .|
+|        ..=+..   |
++--[MD5]----------+
+</code>
+Kopieren Sie dann (auf sicherem Weg) den öffentlichen Teil (public key) des erzeugten Schlüsselpaares in des Home-Verzeichnis des Backup-Benutzerkontos auf dem Sicherungsserver:
+<code>
+linux:~ # scp .ssh/id_rsa.pub backup@backupserver:~
+</code>
+Melden Sie sich jetzt am Backupserver mit diesem Konto an und hängen Sie den Schlüssel an die Datei "authorized_keys" in dessen Homeverzeichnis an:
+<code>
+backup@backupserver:~ # cat id_sa.pub >> .ssh/authorized_keys
+</code>
+Damit der SSH-Dienst des Backup-Servers die Anmeldung per Schlüssel akzeptiert müssen in der Konfigurationsdatei des SSH-Servers <file>/etc/ssh/sshd_config</file> folgende Einträge vorhanden sein:
+<code>
+...
+PubkeyAuthentication yes
+# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
+# but this is overridden so installations will only check .ssh/authorized_keys
+AuthorizedKeysFile      .ssh/authorized_keys
+...
+</code>
+Ist das der Fall, können sie einen Login-Versuch unternehmen:
+<code>
+linux:~ ssh backup@backupserver
+</code>
+Gelingt dies ohne Passwortabfrage, ist die Vorbereitung abgeschlossen.
+=== 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:
+<code>
+invis:~ # rdbunetconf
+</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.
 ===== Durchführung und Kontrolle =====
+==== Sicherung auf Backupserver ====
+Wird auf einen Server gesichert, müssen Sie sich um die Durchführung der Datensicherung keine Gedanken machen, sie erfolgt automatisch, zeitgesteuert.
+==== Sicherung auf externe Festplatten ====
+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.
+//**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.
+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.
+===== Daten wiederherstellen =====
+... work in progress ...
+===== 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....
+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.
+====== Kopano Datensicherung ======
+Die Groupware Kopano bringt ein eigenes Brick-Level Backup-System mit. invis-Server sind so eingerichtet, dass sie täglich abwechselnd einmal die komplette Kopano-Datenbank in Form eines Dumps sichern und einmal das Bricklevel-Backup durchführen. Dabei dient die gesicherte Datenbank als Disaster-Recovery, also dem Wiederherstellen der gesamten Datenbank im Falle eines Crashs und das Bricklevel-Backup dem Wiederherstellen einzelner Elemente, beispielsweise wenn diese versehentlich gelöscht wurden.
+Ziel beider Sicherungen ist das Verzeichnis: <file>/srv/shares/sicherungen</file>
+===== Wiederherstellung einzelner Elemente aus dem Brick-Level Backup =====
+Das benötigte Werkzeug ist **//kopan-backup//**, es bietet verschiedene Möglichkeiten Elemente eines geicherten Kopano-Stores wiederherzustellen. Beginnen wir damit uns den Inhalt der Sicherung anzeigen zu lassen. Wechseln Sie dazu ins Verzeichnis in dem die gesicherten Stores liegen:
+<file>/srv/shares/archiv/sicherungen/kopanostores</file>
+Der folgende Befehl gibt den gesamten Inhalt eines gesicherten Benutzer-Stores aus:
+<code>
+invis:/srv/shares/archiv/sicherungen/kopanostores # kopano-backup --index username
+</code>
+Im Beispiel steht "username" sowohl für den Namen des Sicherungverzeichnisses eines Benutzers, als auch für den aktiven Benutzer in dessen Store ein oder mehrere Elemente wiederhergestellt werden sollen.
+Mit der Option **''-u username2''** können Elemente auch in einen anderen aktiven Store wiederhergestellt werden.
+Um die Ausgabe einzugrenzen, ist **//grep//** ein geeignetes Werkzeug:
+<code>
+invis:/srv/shares/archiv/sicherungen/kopanostores # kopano-backup --index username | grep Posteingang
+</code>
+Die Ausgabe der Informationen erfolgt tabellarisch, Spaltentrenner ist das Komma. Nachfolgend der Aufbau der Zeilen:
+<code>
+Eindeutige ID,Ordner,Datum Uhrzeit,Betreff oder Property
+</code>
+Anhand der ID können einzelne Elemente wiederhergestellt werden. Suchen Sie zunächst wie oben gezeigt das wiederherzustellende Element, beispielsweise anhand des Betreffs oder des Datums eines Elementes. Nutzen Sie jetzt die ID des gesuchten Elements um es wiederherzustellen:
+**Wiederherstellen eines einzelnen Elementes**
+<code>
+/srv/shares/archiv/sicherungen/kopanostores # kopano-backup --restore username --sourcekey DFD123BE9FD84F7AB08E00DD959F2730080100000000
+</code>
+**Wiederherstellen aller Elemente eines Ordners**
+<code>
+/srv/shares/archiv/sicherungen/kopanostores # kopano-backup --restore username -f Posteingang
+</code>
+Dabei wird im Store des Benutzers nichts überschrieben. Bereits vorhandene Elemente werden automatisch übersprungen.
+**Wiederherstellung nach Datum**
+Auch eine zeitliche Eingrenzung der Wiederherstellung auf ein Datum oder einen Datumsbereich ist möglich.
+<code>
+/srv/shares/archiv/sicherungen/kopanostores # kopano-backup --restore username -b 2014-01-01 -e 2015-01-01
+</code>
+Die Optionen **''-b''** und **''-e''** stehen wie kaum anders zu vermuten für "begin" und "end".
+**Komplexeres Beispiel**
+Die hier gezeigten Beispiele lassen sich selbstverständlich auch kombinieren.
+Wenn Sie beispielsweise alle Mails aus dem Posteingang eines Users aus einem bestimmten Zeitraum in einen Unterordner eines anderen Users wiederherstellen wollen sähe das wie folgt aus:
+<code>
+/srv/shares/archiv/sicherungen/kopanostores # kopano-backup --restore username1 -f Posteingang -b 2014-01-01 -e 2015-01-01 -u username2 --restore-root from_username1
+</code>
+Zu erwähnen wäre noch die Option **''- -recursive''**, sie stellt alle Elemente eines Ordners inklusive Unterordner wieder her.
+===== Wiederherstellung der vollständigen Datenbank =====
+//**Achtung**: Die Wiederherstellung der Kopano-Datenbank sollten Sie nur durchführen, wenn die vorhandene Datenbank irreparabel beschädigt ist. Die vorhandene Datenbank wird bei der Wiederherstellung vollständig überschrieben.//
+Es gibt zwei mögliche Vorgehensweisen. Die Sicherung liegt gezippt vor. Sie können die Datei, wenn gewünscht zunächst entzippen und dann wiederherstellen, oder Sie führen beide Schritte in einem durch.
+**2 Schritte**
+<code>
+invis:~ # gunzip gunzip /srv/shares/archiv/sicherungen/vollsicherungen/datenbanksicherungen/20171003/kopano.invis.20171003.gz
+invis:~ # mysql -u root -p kopano < /srv/shares/archiv/sicherungen/vollsicherungen/datenbanksicherungen/20171003/kopano.invis.20171003
+</code>
+**1 Schritt**
+<code>
+invis:~ # gunzip < /srv/shares/archiv/sicherungen/vollsicherungen/datenbanksicherungen/20171003/kopano.invis.20171003.gz | mysql -u root -p kopano
+</code>