Backup - Wie? in welchem Umfang? Womit? - Ersuche euren Rat

[hpoperator]

Hallo liebe Community,

Ich möchte nun gerne eine backupstrategie verfolgen, doch bevor ich die verfolgen kann muss ich erstenmal klären, WAS Genau und WIE gesichert wird.

3-2-1-Strategie ist klar und ich weiss auch wie diese angewandt wird. Doch was ich nicht weiß ist, in welchem Umfang ich backups fahren soll, denn ab einem bestimmten Punkt wirds dann wohl redundant.

Aber.....bitte verzeiht, ich muss etwas ausholen, damit euch die Gesamtsituation bekannt wird....

Kurz zu meinem heimnetzwerk (und dem was ich sichern möchte):

Ich habe einen Server, auf diesem läuft als OS Openmediavault. OS ist auf einer separaten SSD installiert. Dieser Sever ist auch mein Datenspeicher mit einem ZFS-Pool:
ZFS in einen Mirror-VDEVs (2+2 gespiegelt, gestreift) (ähnlich Raid10), wobei slog auf eine 100gb ssd mit plp ausgelagert wird.
Auf diesem Server habe ich per Portainer verschiedene Docker-Container installiert, wie beispielsweise:

• Immich
• Paperless_ngx
• bookstaple
• Plex
• Jellyfin
• dozzle
• OpenArchiver
• Vikunja
• NPM

- Tautully

• checkmk
• netdata

Dann gibt es noch einen ThinClient (Wyse5070), auf diesem läuft als OS HomeAssistant (Vollwertige Imstallation) und als AddOn ist hier AdGuardHome installiert.

Nun erstelle ich noch separat einen "Backup-Server" evtl nutze ich dafür einen RasperryPi oder einen recht performanten Server den ich noch hier stehen habe, welcher aber nur startet, wenn er Backups sichert und danach wieder herunterfährt (einzig wegen dem Stromverbrauch) ~ den Pi würde ich dauerhaft laufen lassen. Hier speichere ich die Backups auf zwei unterschiedliche Platten. Zusätzlich habe ich noch eine Cloud bei Hetzner (BX11), welches für mein entferntes Backup gedacht ist.


So, nun zum eigentlichen kommend.....
Was sichere ich denn jetzt wie?
Verschiedene Docker-Container, wie beispielsweise Paperless_ngx erfordern ja quasi fast eine eigene Vorgehensweise wie man bakups fährt, andere docker ebenfalls. Auch die damit verbundenen Datenbanken und die Inhalte möchte ich gesichert wissen. Verschiedene (nicht alle) Daten aus meinem "Datengrab"/"Datenspeicher" muss ich auch sichern Portainer und OMV als übergeordnete Systeme ebenso. Da ZFS habe ich von Snapshots gelesen, die aber kein vollwertiges Backup darstellen.

Ich würde gern mit größtmöglicher Zuverlässigkeit die Backups bei Problemen "zurückspielen" können, auch vorzugsweise einzelne Applikationen (docker-Container), doch möchte ich nicht unnötigerweise Speicherressourcen verschwenden in dem ich alles doppelt und dreifach absichern muss. Inkrementelle Backups wären wünschenswert.
Ich hatte mir duplikati als docker-Container installiert, aber hier laß ich davon, dass er mit verschiedenen Protokollen von hetzner nicht so klarkommen soll, und auch recht langsam wäre. Deshalb geht die Tendenz nun wohleher zu borg (obwohl ich gern ne GUI hätte).

Wie wäre denn eure Vorgehensweise was die Datensicherung betrifft? Was würdet ihr sichern (und wie), wenn ihr diese Anforderungen erfüllen müsstet?

Ich wäre euch für Hilfestellung diesbezüglich sehr dankbar.

Freundliche Grüße

 

[JumpingCat]

Verschiedene Docker-Container, wie beispielsweise Paperless_ngx erfordern ja quasi fast eine eigene Vorgehensweise wie man bakups fährt, andere docker ebenfalls.

Wieso? Das docker-compose.yml kommt in ein git. Dann einfach nur die Volumes der Container sichern. Oder sehe ich das gap nicht was du siehst?
Ich habe schon so die Cotainer über mehrere verschiedene Rechner und Architekturen migrieren können.

 

[hpoperator]

@JumpingCat
Danke dir für deine Antwort.

Habe ich ja noch überhauptnicht bedacht das mit dem git. Stimmt aber eigentlich, das compose ist ja nur das Geflecht was um die wichtigen sachen herumgesponnen wurde, und dieses lässt sich ja leicht wieder reproduzieren. Wenn ich jetzt "stumpf" nur die volumes der Container sichere (=Daten- und Systemordner der Applikationen) habe ich doch somit nicht automatisch korrekt die damit verbundene Datenbank gesichert? Oder etwa doch? Also dann genauso stumpf die Ordner später wieder an den Bestimmungsort kopieren und gut ist? Die Datenbank muss doch dann irgendwie migriert werden.

Ich habe jedenfalls die volumes für alle docker-container übersichtlich an einem dateipfad auf meinem ZFS-Pool erstellt /omv/docker/NameDerApp.

 

[JumpingCat]

Doch, das ist ja das Konzept von der Docker.

Wenn ich jetzt "stumpf" nur die volumes der Container sichere (=Datenordner der Applikationen) habe ich doch somit nicht automatisch korrekt die damit verbundene Datenbank gesichert?

Die Datenbank ist doch immer Docker Container wo die Daten in einem Volume mit festen Pfad liegen.

 

[keinFischBitte]

Ich würde an deiner Stelle die Backupmöglichkeiten von dem Docker Plugin weiter in Betracht ziehen. Auf den beiden Seiten von omv-extras wird dazu auch einiges mitgeteilt.

https://wiki.omv-extras.org/doku.ph...s:docker_compose#schedule_updates_and_backups

 

[luckysh0t]

wobei slog auf eine 100gb ssd mit plp ausgelagert wird.

Hast du den Parameter sync=always gesetzt? Sonst wird dir ein Slog nur etwas bringen, wenn eine Applikation sync writes anfordert.

Da ZFS habe ich von Snapshots gelesen, die aber kein vollwertiges Backup darstellen

Würde ich dennoch entsprechend sinnvoll für die Datenspeicherorte aktivieren/konfigurieren, so kannst du zumindest in Windows über Vorgängerversion die Daten bei Löschen etc. recht simpel wiederherstellen.

Wie wäre denn eure Vorgehensweise was die Datensicherung betrifft? Was würdet ihr sichern (und wie), wenn ihr diese Anforderungen erfüllen müsstet?

Ich sichere meine wichtigen Daten in die Storagebox (Diese hatte ich mit einer Hetzner Cloud VM auch eine Zeitlang auf eine Storagebox an einem anderen Standort gepsiegelt.) mit einer Debian VM auf der Syncovery läuft - mit Duplicati hatte ich Probleme (korrupte Daten) und mir gefiel das proprietäre Format nicht, mit dem nur Duplikati etwas anfangen kann. Nun sichere ich meine Daten in eigene verschlüsselte Zip Archive.

Da ich in dem Fall keine riesigen Dateien sichere, lösche ich quasi in der Box nicht.

Und auf meinem Filer (OmniOS) nutze ich selbst auch Snapshots, für jedes Dataset entsprechend konfiguriert - so muss man eben nicht gleich das Backup bemühen, falls mal was gelöscht wird. Sofern der Snap noch da ist.

 

[hpoperator]

@luckysh0t
Danke für deine Antwort und sorry für meine verspätete!

habe den Parameter sync nicht auf always gesetzt, da es nicht Best Practice ist das global zu erzwingen, denn damit einhergehend generiert man einen hohen Overhead und einen Nutzen erreicht man damit nur bei Sync-IO. Dies gezielt pro Dataset zu setzen ist der richtige Weg.
Apps, die Haltbarkeit brauchen (DBs, NFS mit Sync, Apps mit fsync/O_DSYNC), erzwingen Sync selbst, alle anderen blockierst du nicht unnötig. sync=always zwingt alles synchron, bedeutet eine spürbare Latenz- und ein Durchsatzverlust, steht so auch in der Doku:

"Controls the behavior of synchronous requests (e.g. fsync, O_DSYNC). standard is the POSIX specified behavior of ensuring all synchronous requests are written to stable storage and all devices are flushed to ensure data is not cached by device controllers (this is the default). always causes every file system transaction to be written and flushed before its system call returns. This has a large performance penalty. disabled disables synchronous requests. File system transactions are only committed to stable storage periodically. This option will give the highest performance. However, it is very dangerous as ZFS would be ignoring the synchronous transaction demands of applications such as databases or NFS. Administrators should only use this option when the risks are understood."
siehe Hier

 

[luckysh0t]

sync=always zwingt alles synchron, bedeutet eine spürbare Latenz- und ein Durchsatzverlust, steht so auch in der Doku:

Ist mir bewusst, und für mich nicht relevant, daher erzwinge ich es, mit dem lokalen VM Storage im PVE.Allerdings nutze ich auch eine Intel Optane als Slog.

Aber es zeigt dass du dich mit der Bedeutung von Sync writes beschäftigt hast - Anhänger einer anderen NAS Distri verstehen dank vieler YouTuber das ganze leider falsch.