Backup Strategie Server

Martin schrieb:

Ich habe mir snapper angesehen.

Snapper macht Snapshots von Subvolumes, das ist kein Backup. Kann aber als Datenquelle für Backups dienen, wenn du die Snapshots wegsichern willst.

Im Zusammenhang mit Docker: Vorsicht, Docker-Container auf btrfs haben stapelweise eigene Subvolumes (/var/lib/docker/btrfs/subvolumes), die dabei aus dem Backup fliegen.

Und bei Datenbanken sind Snapshots auch nicht so toll. Die Datenbank-Files sind dabei (hoffentlich) als No-COW angelegt, werden durch die Snapshots aber trotzdem zu COW gezwungen. Geht auf die Performance.

Würde mir für Docker&Datenbank eher klassische Backup-Strategien anschauen.

Εrnst B. schrieb:

Snapper macht Snapshots von Subvolumes, das ist kein Backup. Kann aber als Datenquelle für Backups dienen, wenn du die Snapshots wegsichern willst.

Richtig das ist mir bewusst und so in etwas dachte ich es mir. Es wird ein Snapshot gemacht und dann mit was anderem auf eine Platte kopiert, die ich herausziehen kann.

Εrnst B. schrieb:

Im Zusammenhang mit Docker: Vorsicht, Docker-Container auf btrfs haben stapelweise eigene Subvolumes (/var/lib/docker/btrfs/subvolumes), die dabei aus dem Backup fliegen.

Die Containerdaten liegen im Btrfs aber nicht die container selber. Die Container möchte ich auch gar nicht sichern sondern nur die Compose files und die Daten dazu.

Datenbanken habe ich als nocow angelegt. Ich habe gelesen, dass es nur eine Fragmentierung zu Folge hat und man sich das auch sparen könnte.

Εrnst B. schrieb:

Würde mir für Docker&Datenbank eher klassische Backup-Strategien anschauen.

Klassiche Strategie heißt? Docker kurz beenden, Daten kopieren und dann weiter?

Dennoch suche ich noch eine Lösung dafür, dass man erkennt ob die enstprechende Backup Platte auch gemountet werden kann. Es kann sein, dass vergessen wurde die Platte wieder zu wechseln.

Bisher habe ich immer duplicity mit pre und post scripts benutzt.

Gustav G. schrieb:

Klassiche Strategie heißt? Docker kurz beenden, Daten kopieren und dann weiter?

Datenbanken: mysqldump, pg_dump... Docker: Dockerfiles, compose-Files, evtl. Daten-Volumes, wenn die nicht nur temporäre Daten enthalten. Rest kannst du ja wieder frisch herunterladen oder bauen.

Gustav G. schrieb:

Dennoch suche ich noch eine Lösung dafür, dass man erkennt ob die enstprechende Backup Platte auch gemountet werden kann.

eigenes Backup-Script, mounten, schauen ob's geklappt hat, sonst E-Mail?

Für die Daten-Volumes geht das auch recht gut per snapper und "btrfs send", wenn man etwas Shell-script basteln mag.

Bei mir läuft das über die $ORDNER/.snapshots Schaut nach welche da schon gesichert sind (Hab da einfach ein File in den Ordner getouched), und schreibt per "btrfs send" die Differenz zwischen dem aktuellen und zuletzt gesicherten Snapshot raus. (falls kein parent gefunden wird, eben ein komplettes send)

per snapper -c $config modify -d ... -c ... wird dann auch die Cleanup-Strategy für den Snapshot geändert, damit der gesicherte Snapshot auch garantiert für den nächsten Lauf vorhanden ist.

snapper macht bei mir stündlich Backups, damit die per SAMBA auch für die Windows-Anwender zur Verfügung stehen. Backup läuft aber nur nachts, und nimmt halt den Snapshot der grad da ist..

Schau dir mal Proxmox Backup Server an. Für mich die perfekte Lösung für Container, VMs (selbstverständlich beides auch in redunaten Laufzeiten) und selbstverständlich physischen Hosts.

Ich bin damit sehr zufrieden.

(P.s. kostet natürlich eine physische Maschine, aber ich gehe mal stark davon aus die hast du über.)