Backup Best Practice

[oekomat]

Hallo zusammen,

 

bin echt begeistert, von den unraid Funktionen und baue nach und nach immer mehr Funktionen auf. Jetzt kommt das Thema Backup
1. vom Cache mit Containern (ca 100GB)

2. vom array (ca 3 TB)

 

Für 1. bin ich über Appdata Backup/Restore gestolpert und wollte meine appdata über remote-SMB auf eine alte Synology sichern. Problem 1 Container werden während transfer gestoppt, Problem 2 der Stopp der Container ist für einige Docker (z.b. Smarthome mit zigbee2mqtt) zu lange. Selbst nachts 1 Stunde ohne einige Container wäre ein nogo.

 

Wie handhabt ihr das?

 

Gruß oekomat

M.2 1TB Samsung für den Cache
1 Pool mit 1 TB SSD
1 Array mit 2x 6TB WD

[alturismo]

11 minutes ago, oekomat said:

Wie handhabt ihr das?

 

Container nicht stoppen und evtl. damit leben dass das Backup nicht in Ordnung ist

 

oder du machst manuell ein script und machst

 

Stop Container A, Backaup appdata Container A, Start Container A

Stop Container B, ....

denke ist selbsterklärend

 

ps. ich mache die o.g. Variante  damit leben ....

[oekomat]

6 minutes ago, alturismo said:

oder du machst manuell ein script und machst

 

Stop Container A, Backaup appdata Container A, Start Container A

Stop Container B, ....

denke ist selbsterklärend

 

 

ok, wäre eine Möglichkeit. Ggf. bestimmt mit App "User Scripts" am einfachsten umzusetzen und die Scripte auch verwaltbar.

 

6 minutes ago, alturismo said:

Container nicht stoppen und evtl. damit leben dass das Backup nicht in Ordnung ist

ps. ich mache die o.g. Variante  damit leben ....

 

das wäre dann der Plan B  

 

Danke für deinen Input.

[oekomat]

34 minutes ago, alturismo said:

ps. ich mache die o.g. Variante  damit leben ....

wie hast du das umgesetzt? (vergessen zu fragen)

[hawihoney]

3 hours ago, oekomat said:

Selbst nachts 1 Stunde ohne einige Container wäre ein nogo.

 

Zum Beispiel MariaDB und Nextcloud in einem User Script - 19 Sekunden heute morgen. Ist das ein Problem?

 

docker stop nextcloud
docker stop mariadb

rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/disk17/Backup/Tower/system/appdata/mariadb/
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud/
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud.data/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud.data/

docker start mariadb
docker start nextcloud

 

[oekomat]

14 minutes ago, hawihoney said:

 

Zum Beispiel MariaDB und Nextcloud in einem User Script - 19 Sekunden heute morgen. Ist das ein Problem?

 

docker stop nextcloud
docker stop mariadb

rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/mariadb/ /mnt/disk17/Backup/Tower/system/appdata/mariadb/
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud/
rsync -avPX --delete-during /mnt/pool_nvme/system/appdata/nextcloud.data/ /mnt/disk17/Backup/Tower/system/appdata/nextcloud.data/

docker start mariadb
docker start nextcloud

 

 

19 sek gehen gerade noch so  - das wäre genial, sieht aber danach aus, als ob das Backup in deinem Unraid liegt und nicht extern auf einen smb mount, oder?

[alturismo]

2 hours ago, oekomat said:

wie hast du das umgesetzt? (vergessen zu fragen)

ich nutze luckybackup ...

 

wobei wenn ich mich recht erinnere, ist bei dem von dir genutzten plugin sogar die Option drin zum wählen ... ob die Container gestoppt werden sollen oder nicht ...

 

2 minutes ago, oekomat said:

19 sek gehen gerade noch so  - das wäre genial, sieht aber danach aus, als ob das Backup in deinem Unraid liegt und nicht extern auf einen smb mount, oder?

dafür gibt es UAD, du mountest die externen smb shares und hast dann "lokale" /mnt ...

 

rot markiert sind smb shares welche dann in das script kämen (der Rest sind rclone mounts von cloud's)

 

[hawihoney]

28 minutes ago, oekomat said:

sieht aber danach aus, als ob das Backup in deinem Unraid liegt und nicht extern auf einen smb mount, oder?

 

Ja, 2-stufig. Das erhöht die Verfügbarkeit. 19 Sekunden aufs Array und die Container laufen wieder. Vom Array gehts nach extern. Wie lange das dann dauert spielt keine Rolle mehr.

 

[oekomat]

15 hours ago, hawihoney said:

 

Ja, 2-stufig. Das erhöht die Verfügbarkeit. 19 Sekunden aufs Array und die Container laufen wieder. Vom Array gehts nach extern. Wie lange das dann dauert spielt keine Rolle mehr.

 

wie groß ist denn dein cache, den du sicherst? ich schreibe von einem pool (cache M.2) auf einen anderen pool (SSD) 5GB/min...und habe 166 GB.

[oekomat]

15 hours ago, alturismo said:

ich nutze luckybackup ...

 

 

Hab ich beim Geek Freak schon mal gesehen. Damit kann ich doch Tasks in Reihe schalten oder?
1. Stopp Container a, Backup container a nach Ziel Ordner1, starte Container a
2. Stopp Container b, Backup container b nach Ziel Ordner2, starte Container b

usw

 

Ich würde Container mit höherer Prio woanders sichern und in einem eigenen backup, als low-prio-container. Wenn lucky das kann, wäre super. Mit Appdata Backup/Restore kann ich das nicht so gezielt machen.

[alturismo]

3 minutes ago, oekomat said:

Hab ich beim Geek Freak schon mal gesehen. Damit kann ich doch Tasks in Reihe schalten oder?

grundsätzlich, ja

 

3 minutes ago, oekomat said:

1. Stopp Container a, Backup container a nach Ziel Ordner1, starte Container a
2. Stopp Container b, Backup container b nach Ziel Ordner2, starte Container b

usw

oob, sicher nicht ... widerspricht ja dem "isolierten" docker "öko" system ...

 

Lösung wäre machbar, zum Start für den luckybackup Docker dann noch folgendes ergänzen

-v /var/run/docker.sock:/var/run/docker.sock

 

und jetzt käme der interessante Teil, du brauchst natürlich noch zumindest den docker client innerhalb luckybackup ... nur bevor du das jetzt stumpf von hier kopierst, lies dich bitte dazu ein dass du am Ende auch weißt was du hier machst und was das bedeutet ... dann weißt du auch wie du den client in luckybackup zum Laufen bekommst

 

Hinweis ... du solltest wissen das dann luckybackup Kontrolle über den docker daemon bekommt, wenn du das wirklich willst ... wäre es lösbar  

[oekomat]

23 minutes ago, alturismo said:

Hinweis ... du solltest wissen das dann luckybackup Kontrolle über den docker daemon bekommt, wenn du das wirklich willst ... wäre es lösbar  

 

Oh, Kontrolle abgeben ist immer unschön 😬

 

Danke für diese wichtigen infos. So tief stecke ich (noch) nicht im System, hätte ich mir einfacher vorgestellt. Backup machen ist das eine, aber die container am laufen zu halten das andere.

Wäre denn ein sync mit einem externen gemounteten Verzeichnis leichter und auch sicher?

 

Edit: Denn wenn ich das richtig verstanden habe, sollte ich den Appdata immer komplett sichern und nicht einzelne Container. Will ich das sicher machen, muss ich die Container stoppen, was meine Verfügbarkeit/Erreichbarkeit einschränkt.

Edited February 18, 2023 by oekomat

[alturismo]

1 hour ago, oekomat said:

Wäre denn ein sync mit einem externen gemounteten Verzeichnis leichter und auch sicher?

 

leichter, ja, sicherer ... sicher Nein, außer du mountest manuell (mit pass oder ...) und unmountest danach, ansonsten, wie bereits x-mal beschrieben, wenn dein System übernommen wurde sind auch die mounts übernommen und deine backups auch

 

alles eine Frage "Wie weit willst du gehen", für mich, auf jeden Fall ... den Kram mit mount, unmount, oder von einem client ausführen gebe ich mir persönlich nicht, aber ich bin mir darüber bewusst dass dies in dem Fall nicht "ganz sicher" ist ... mir geht es aber persönlich mehr um Ausfallschutz als vor eventuellen Attacken und das jemand bei mir alles löschen sollte ... muss jeder für sich entscheiden.

 

1 hour ago, oekomat said:

Will ich das sicher machen, muss ich die Container stoppen, was meine Verfügbarkeit/Erreichbarkeit einschränkt.

diese Frage muss doch jetzt nicht ernsthaft nochmals beantwortet werden ...  nicht böse gemeint, aber hey ... steht alles weiter oben

[oekomat]

14 minutes ago, alturismo said:

diese Frage muss doch jetzt nicht ernsthaft nochmals beantwortet werden ...  nicht böse gemeint, aber hey ... steht alles weiter oben

 

ist nicht böse von dir 🙂 . War auch keine Frage sondern eher ein gedankliches Resümee von mir gemeint. Hab das schon verstanden.
 

[Zip]

Ich nutze das Skript von @mgutt:

 

 

Edited February 18, 2023 by Zip

[hawihoney]

8 hours ago, oekomat said:

wie groß ist denn dein cache, den du sicherst?

 

Das kann ich so genau nicht sagen. Ich habe für jeden Container ein passendes User-Skript und die laufen täglich. Da sich darunter eine ziemlich umfangreiche Plex Installation befindet, und die Gesamtauslastung des Caches bei über 250 GB liegt, denke ich, dass es so in der Größenordnung liegt.

 

Die Laufzeiten der Skripte hatte ich mal protokolliert und dementsprechend getaktet. Der ganze Zinober startet jeden morgen um 04:00. Das letzte Skript startet dann um 07:20.

 

Edited February 18, 2023 by hawihoney

[Thorsten]

Ich mache die Datensicherung mit BorgBackup.... Ich finde dieses Tools super es verfügt über eine Deduplizierung d.h. es werde nur geänderte Blöcke gesichtert.

Zusätzlich kann man einfach das Backup Verzeichnis Mounten und auf jede Sicherung einfach zugreifen.

 

Bei mir läuft ein Skript welches alles Container automatisch herunterfährt und die Sicherung durchführt im Anschluss wird das Archiv noch

bereinigt von den Sicherungen sie raus altern. Danach werden die Container wieder gestartet.

 

Ich habe mal mein Skript als Beispiel begefügt. Hier zu wird allerdings BorgBackup benötigt und das entsprechende Repository für Borg muss angelegt werden.

 

z.B.

borg init --encryption=repokey-blake2 /mnt/backup/borg-backup-appdata

 

Beispiel-Skript.txt

 

Ich verfolge die 3-2-1 Backup Strategie. Ich sichere auf zwei im RAID0 Backup Festplatte zu je 4TB dann auf die Synology und zusätzlich auf die 5TB StorageBox von Hetzner. Letzteres unterschützt auch BorgBackup. Für alles Sicherung nehme ich BorgBackup in unterschiedlichen Skripten.

 

Die Gesamte Größe der Sicherungen je Medium sind ca. 2TB von den wichtigesten Daten (Bilder, Dokumente, DMS, Appdata)

 

 

Edited February 18, 2023 by Thorsten

[oekomat]

On 2/18/2023 at 6:58 PM, Thorsten said:

Ich mache die Datensicherung mit BorgBackup.... Ich finde dieses Tools super es verfügt über eine Deduplizierung d.h. es werde nur geänderte Blöcke gesichtert.

Zusätzlich kann man einfach das Backup Verzeichnis Mounten und auf jede Sicherung einfach zugreifen.

 

 

 

Das werde ich mir auf jeden Fall mal ansehen. Ansonsten kurzfristig erstmal wie @hawihoney mit folgendem Script für jeden Container. Davor Container stoppen, danach starten. Wenn alles durch, das backupappdata auf einen temp. laufenden Remote SMB Freigabe schieben:
 

rsync -aAXv /mnt/user/appdata/mariadb-official /mnt/user/backupappdata

 

[oekomat]

So, wie beschrieben habe ich das erstmal umgesetzt.

alle 2 Tage jeweils 2-3 container nacheinander stoppen
rynch auf eine PoolDevice-Platte in Unraid schieben

diese container wieder starten

 

eine Synology fährt alle paar Tage für 1 Stunde hoch
dann per User Script einen remote Mount erstellt

per Backup/Restore Data Plugin die Daten vom PoolDevice auf die Synology backupen (dafür muss kein Container gestoppt werden)

per User Script wieder umount der remote SMB

[SidM]

Hallo zusammen,

 

da der Titel ganz gut passt, dachte ich mit meinen Anliegen hier gut reinzupassen.

 

Nach über 2 Jahren Unraid bin ich richtig begeistert von den System und habe nun bereits viele Docker im Einsatz wovon ich zu beginn nicht geträumt hatte. Dazu noch 2-3 VM'S WireGuard Tunnel etc.

 

Seit ca. 1 Jahr ist auch Nextcloud mein täglicher Begleiter für Fotos, Dokumente etc. geworden und nicht mehr weg zu denken.

 

Die Daten von Nextcloud und auch alle anderen Docker einschließlich appdata befindet sich auf einem Cachepool bestehend aus 2x2TB NVME, die gespiegelt sind.

 

Nun ist es aller höchste Zeit sich um Backups dessen zu kümmern. Ich habe mir dazu vor ein paar Wochen einen Intel Nuc (NUC7i3BNK) mit 4GB RAM gekauft und dort noch eine 2TB NVME eingesetzt. Als Betriebssystem kommt hier auch Unraid zum Einsatz.

 

Ich habe nun schon sehr häufig die Erwähnung des rsync Backup Skript von @mgutt gehört und denke, dass dies auch für mich passen würde.

 

Allerdings ist mir manches noch nicht ganz klar.

 

-das Skript läuft auf dem Backup-Server?

-benötige ich zusätzlich den Docker rsync-Server? (ich denke nein, weiß aber nicht wo ich dann den SSH Key vom Server im Skript eintragen soll)

 

Vielleicht noch nützlich Infos zum "Aufbau":

 

Der Server steht bei mir und der Backup-Server bei meiner Freundin. Beide Standorte sind mit einer Fritzbox ausgestattet und permanent über VPN (IPSec) miteinander verbunden. Wireguard ist auf der 6590 leider nicht möglich, aber ich könnte durch den Backup-Server einen Wireguard-Tunnel zwischen beiden Servern einrichten.

 

Zusätzlich ist noch geplant 2 Festplatten zu holen, die ebenfalls beide abwechselnd mit dem Skript beschrieben werden wovon eine dann immer bei bekannten untergebracht ist und ich Monatlich die alte Sicherung gegen die neue Tausche. (Hier wäre es noch cool wenn man diese evtl. verschlüsseln könnte)

 

Macht das soweit sinn wie ich es mir vorstelle und das 321 Backup richtig verstanden habe?

 

[mgutt]

4 minutes ago, SidM said:

-das Skript läuft auf dem Backup-Server?

-benötige ich zusätzlich den Docker rsync-Server? (ich denke nein, weiß aber nicht wo ich dann den SSH Key vom Server im Skript eintragen soll)

Optimal wäre es, wenn das Skript auf dem Backup Server läuft und der nur lesend auf den Quellserver zugreifen kann. Dh der rsync Docker ist dann sinnvoll. Ansonsten nutzt der Backupserver den root Login, was dich extrem anfällig bei Attacken macht.

[SidM]

1 minute ago, mgutt said:

Optimal wäre es, wenn das Skript auf dem Backup Server läuft und der nur lesend auf den Quellserver zugreifen kann. Dh der rsync Docker ist dann sinnvoll. Ansonsten nutzt der Backupserver den root Login, was dich extrem anfällig bei Attacken macht.

 

Wenn möchte ich schon den optimalen und sichersten Weg gehen.

Okay also rsync Server installieren ✔️

Dort gebe ich dann nur die Pfade des eigentlichen Server's an die ich sichern möchte? Standartmäßig ist hier ja /mnt/user/ angegeben also alles. Sollte ich das nur auf die benötigten Freigaben ändern oder kann ich das auch bedenkenlos so lassen?

 

Bei schreiben bin ich gerade etwas verunsichert wurden. 

Der rsync-Server läuft ebenfalls auf dem Backup-Server und durch die Generierung des SSH Key's auf dem Client (Hauptserver) kann sich der Backup-Server als vertrauenswürdig verifizieren. Richtig?

 

Die Pfadangaben und auch das Readonly bezieht sich aber auf den Backup-Server und nicht des Hauptserver's? 

Damit wird quasi verhindert dass der Hauptserver Datein auf den Backup-Server Manipulieren kann, wenn er mal kompromittiert wird?

Andersherum würde es aber gehen?

 

Ich einem Screenshot von dir gab es im rync-Server die Variable Acess Mode mit der Option auf Read Only. Das ist im aktuellen Docker jetzt nicht mehr vorhanden also gehe ich richtig der Annahme, dass dies jetzt fest hinterlegt ist?

 

Im Skript gebe ich dann z.b. folgendes ein:

 

# source                          				# destination
"192.168.188.40:/mnt/cache/appdata"              "/mnt/user/backup/appdata"
"192.168.188.40:/mnt/cache/Nextcloud"            "/mnt/user/backup/Nextcloud"

 

 

 

 

[Revan335]

51 minutes ago, SidM said:

Ich einem Screenshot von dir gab es im rync-Server die Variable Acess Mode mit der Option auf Read Only. Das ist im aktuellen Docker jetzt nicht mehr vorhanden also gehe ich richtig der Annahme, dass dies jetzt fest hinterlegt ist?

Wenn du den Erweiterten Modus (im Template Editor) einschaltest oder in das Template selbst schaust, dann solltest du die entsprechende Option sehen. Ob die jetzt auf RO oder RW steht.

[SidM]

3 minutes ago, Revan335 said:

Wenn du den Erweiterten Modus (im Template Editor) einschaltest oder in das Template selbst schaust, dann solltest du die entsprechende Option sehen. Ob die jetzt auf RO oder RW steht.

Das war auch mein erster Gedanke, aber dort ist nichts zu finden. Beim Template habe ich auch nicht wirklich etwas gefunden, das kann aber auch mangelnden Wissen liegen.

[SidM]

Wenn ich es in dem Thread richtig vernommen habe wird es so eingerichtet:

 

-rsync-Server auf Quell-Server installieren

-SSH Key des Backupserver hinterlegen

-Skript mit gewünschten Pfaden auf Backup-Server ausführen (z.b. täglicher CRON)

 

Was mich aber noch verwundert: In der Version 1.7 des Skript steht unter ToDo: "docker container stop and start for SSH sources"

Im passenden Thread dazu aber :

 

"Unraid exclusive: Stops docker containers if the source path is the appdata path, to create consistent backups

Unraid exclusive: Creates a snapshot of the docker container source path, before creating a backup of it. This allows an extremely short downtime of the containers (usually only seconds).

 

Wie muss ich das jetzt deuten? Funktioniert das Starten und stoppen der Dockercontainer noch nicht, oder aber nur wenn das Skript auch auf dem Quell-Server ausgeführt wird?