rsync Backup von server

[sorcim]

Hallo zusammen,

ich habe einen Heimserver, auf dem u.A. eine Nextcloud Instanz, sowie zwei Datenbankserver (postgresql und mariadb) laufen.

Ich möchte in regelmäßigen Abständen ein Backup dieser Daten auf diesem Heimserver erstellen. Dafür habe ich mir ein Script geschrieben, das die Verzeichnisse /root, /etc, /home, /boot, /opt und /mnt mittels rsync über ssh auf eine externe Festplatte synchronisiert. In diesen Verzeichnissen liegen auch die Daten aus der Datenbank. Für rsync werden die Optionen -av --delete --relative --recursive verwendet.

Jedenfalls hängt sich rsync ziemlich lange an der Datei /mnt/nvme_raid/docker/general/bind-volumes/mariadb-data/ib_logfile0 auf. Da diese Datei lediglich ~100MB groß ist, muss irgendetwas hier die Synchronisation blockieren. Während der Synchronisation läuft natürlich der Server weiter und vermutlich werden auch regelmäßig Datenbankzugriffe etc gelogged. Könnte dies im Zusammenhang stehen?

Ansonsten:
- Ist es eine gute Idee, wie beschrieben von einem laufenden Serverbetrieb ein Backup zu erstellen?
- Wie kann ich herausfinden, wieso rsync bei der angesprochenen Datei so lange (schon über 2 Stundn!) hängt?

Vielen Dank und viele Grüße

[schwedenmann]

Hallo

Ist es eine gute Idee, wie beschrieben von einem laufenden Serverbetrieb ein Backup zu erstellen?

Zumindest für die dbms eine schlechte Idee.

da sind mariabackup, pgbackrest, oder dumps die bessere Wahl.

mfg
schwedenmann

[niemand]

Während der Synchronisation läuft natürlich der Server weiter und vermutlich werden auch regelmäßig Datenbankzugriffe etc gelogged. Könnte dies im Zusammenhang stehen?

Ja.

Ist es eine gute Idee, wie beschrieben von einem laufenden Serverbetrieb ein Backup zu erstellen?

Nein. Wie schwedenmann schon schreibt: vom DBMS macht man das Backup mit dessen eigenen Werkzeugen, und auch ansonsten sieht man zu, dass keine der zu sichernden Dateien mehr zum Schreiben geöffnet sind. Ansonsten kann’s auch mal passieren, dass das Backup schlicht unbrauchbar ist.

[GregorS]

- Ist es eine gute Idee, wie beschrieben von einem laufenden Serverbetrieb ein Backup zu erstellen?

Zumindest für die Zeit des Backup-Laufs sollten keine oder möglichst wenige Dateien zum Schreiben geöffnet sein. Wenn Du das Backup in ein Skript packst, kannst Du die betreffenden Programme ja beenden (kill -SIGTERM ...) und danach wieder starten.

[sorcim]

Hallo zusammen,

der Heimserver beinhaltet viele Daten (~3TB), d.h. die Sicherung selbst dauert schon eine ganze Weile (selbst wenn ich sie lokal laufen lassen würde). Mir ist klar, dass bei einem Backup nicht immer alle Dateien neu kopiert werden müssen, da rsync ja nur geänderte Dateien neu kopiert, aber trotzdem möchte ich die Downtime natürlich begrenzen oder am Besten ganz eliminieren. Welche Lösungen gibt es hier, wenn man für den Server nicht gleich einen zweiten Fallback-Server aufstellen will?

[GregorS]

Welche Lösungen gibt es hier, wenn man für den Server nicht gleich einen zweiten Fallback-Server aufstellen will?

Diese Info solltest Du in der Doku zu den betreffenden Programmen finden können. Von einer Software, die ernst genommen werden will, erwarte ich das.

[uname]

Du kannst oder solltest die Anwendungen, die die Datenbank nutzen, deaktivieren oder in den Wartungsmodus setzen.

Beispiel Nextcloud

[MSfree]

der Heimserver beinhaltet viele Daten (~3TB), d.h. die Sicherung selbst dauert schon eine ganze Weile (selbst wenn ich sie lokal laufen lassen würde).

Jein. Die erste Sicherung muß natürlich eine vollständige Kopie sein, und das dauert dann bei 3TB um die 9 Stunden über GBit-Ethernet, von Festplatte zu Festplatte schafft man es in ca. 6 Stunden, von SSD zu SSD in 2 Stunden.

Alle weiteren Sicherungen kann man inkrementell durchführen. Wenn sich da am Tag nur ein paar GByte an Dateien ändert, dauert das Backup nur noch Minuten.

aber trotzdem möchte ich die Downtime natürlich begrenzen oder am Besten ganz eliminieren.

Man kann rsync im laufenden Betrieb durchführen. Wenn jemand beispielsweise gerade Steuererklärung.docx in Word bearbeitet, dann landet auf der Sicherung halt der Stand von gestern. Der aktuelle Stand wird dann erst mit der nächsten Sicherung erfaßt. Mit den meisten Dateien geht das völlig unproblematisch.

Eine gewisse Ausnahme stellen Datenbanken dar. Ich habe mariadb für mein Mediawiki im Einsatz. Mariadb läßt sich im laufenden Betrieb mittels mysqldump auf eine Datei sichern, die ich dann mit rsync auf das Sicherungssystem bringe. Dadurch brauche ich überhaupt keinen Kopfstand zu machen und die DB in den Wartungsmodus zu versetzen, denn darum kümmert sich mysqldump selbst. Natürlich sollte man dann den Zeitpunkt von mysqldump so legen, daß nicht zur gleichen Zeit rsync läuft. Nur, wenn man es mit riesigen Datenbanken zu tun hat, muß man sich um effizientere Methoden als mysqldump kümmern. Mein Mediawiki ist als .gz komprimiert nur ein paar MByte groß.

Ich brauch hier wohl nicht zu erwähnen, daß ich Backups vom Betriebssystem für überflüssig halte, denn das läßt sich durch einen Neuisntallation wiederherstellen. Was man installiert hat und wie es konfiguriert wurde, sollte man sich allerdings dokumentieren, damit die Wiederherstellung nicht zum Ratespiel wird. Nur, wenn man es mit Hochverfügbarkeit zu tun hat, braucht man eine direkte Sicherung des Betriebssystems. Im Heimbereich darf ein Server auch mal 4 Tage ausfallen, bis man ihn wieder aufgesetzt hat, das ist schlimmstenfalls ein wenig unbequem. Außerdem bietet einem eine Neuinstallation auch die Chance, das schon lange geplante aber nie durchgeführte dist-upgrade auf eine aktuellere Debianversion gleich zwangsweise durchzuführen.

[homer65]

Da Du auch postgresql erwähnt hast. Mit pg_dump macht man Sicherungen einer einzelnen Datanbank. Mit pg_dumpall kannst Du alle Datenbanken eines Servers sichern.