Docker Backup - Container herunterfahren, ja oder nein ?

[Pfandfinder]

ich habe auf meinem VPS einiges mit Docker am laufen, Backups werden automatisch mit restic erstellt. Zur Sicherheit wegen der Integrität fährt ein Script die Container immer vor dem Backup herunter und dann wieder hoch. ich frage mich schon länger ob das eigentlich überhaupt notwendig ist, was meint ihr ? Kommt es auf die Backup-Art an bzw. die genutzte Software ?

Wie sieht es z.B. mit dem Synology NAS Container Manager aus wenn ich die Synology-eigene Software Hyper Backup verwende, sollte ich die Container da auch lieber vorher herunterfahren ?

 

[Rickmer]

Was ist denn im Container drin?
Einfach nur Dateien? Oder eine Datenbank?

Eine Datenbank solltest du immer in Wartungsmodus setzen bevor du ein Backup machst. Oder anderswie aufs Backup vorbereiten.

Herunterfahren ist sicherer als es nicht tun.

 

[Sebbi]

kommt drauf an was im Docker Container läuft.
Wenns ne Datenbank ist, sollte der Container heruntergefahren werden, um den konsistenten Zustand zu bewahren

 

[Pfandfinder]

paperless z.b., ja das nutzt ne DB.

 

[Sebbi]

Dann behalte das herunterfahren bei

 

[Tornhoof]

Deine Daten für den docker Container liegen doch wahrscheinlich eh nicht im Container?
Als Datei/Ordner gemounted oder als docker volume?
So oder so sollte der Container gestoppt werden.

Theoretisch kann man docker volumes live backupen, d.h. aber nur du hast keinen Datenverlust, nicht dass die laufende Software davon was mitbekommt und zb Daten flushed.

Der saubere weg ist immer shutdown

 

[Sebbi]

Theoretisch kann man docker volumes live backupen, d.h. aber nur du hast keinen Datenverlust, nicht dass die laufende Software davon was mitbekommt und zb Daten flushed.

Wenn keine Datenbank laufen würde, wäre das kein Problem. Wenn man aber eine Datenbank auf diese Weise backuped und die macht während des Sicherns einen Schreibvorgang, kann diese in einen so inkonsistenden Zustand gerade, das auch nach einer erfolgreichen Wiederherstellung die Datenbank defekt ist.

Dort kann man nur den Weg mit den sauberen Shutdown machen ODER über Backup Funktionen der (des) Datenbank(programms) selbst wenn vorhanden.

 

[und tschüss]

Das kommt immer darauf an, was man unter einem Backup versteht.

Falls du das einfache Kopieren der Dateien und Ordner meinst, also „on the fly“, ist es ratsam, die Datenbanken auszuschalten oder im Wartungsmodus bzw. Ruhestand zu versetzen. Aber sofern kein Schreibzugriff erfolgt, ist ein Backup auch nicht wirklich problematisch. Ich sichere den Dockerordner jede Nacht zu einer Zeit, wo kein Zugriff erfolgt und habe noch nie Probleme gehabt und das seit vielen Jahren ohne die Container zu stoppen!

Aus Sicherheitsgründen erstelle ich aber weiterhin einen Dump von Postgres, welcher automatisch gezippt wird und ins Backup wandert. In diesem Dump sind dann alle Datenbankeinträge, Datenbanken und User vorhanden. Es wird auch benötigt, um einen sicheren Versionssprung von z. B. Postgres16 > Postgres17 zu machen. Dieser Dump funktioniert immer und ist unabhängig von den angelegten Ordnern im jeweiligen Container. Natürlich funktioniert das auch bei anderen Datenbanken gleichermaßen ähnlich. Um diesen Dump auszuführen, nutze ich ein einfaches Script, um den Docker-Container (z. B. Postgres anzusprechen), natürlich kann der Container den Dump auch automatisch machen (zusätzlicher Postgres-Container mit anderen Variablen, Bsp. siehe Immich) oder einfach über eine GUI wie z. B. pgAdmin4. Diesen Dump nutze ich nur beim Versionsupgrade oder wenn beim Wiederherstellen der Ordnerstruktur (on the fly) etwas schiefgegangen ist. Letzteres ist aber noch nie passiert.

Da ich das Risiko für mich abschätzen kann, verzichte ich schon immer auf das Ausschalten der Datenbank. Synology macht bei der internen Postgres-Datenbank in Verbindung mit Hyperbackup auch nichts anderes, ansonsten könntest du die DiskStation während des Backups nicht mehr benutzen, weil alle Daten (DSM & Synology Apps) dort abgelegt werden. Wer Angst hat oder nicht genau weiß, was er macht, kann ja lieber zur Sicherheit die Datenbanken (Container) ausschalten oder im Wartungsmodus versetzen. Bei den nativen Datenbanken in DSM (Postgres oder MariDB) wird es mit dem Ausschalten schwer.

Da ich alle Anwendungen und Dienste in einer Postgres-Instanz laufen lasse, brauche ich auch nur ein Backup/Dump zu erzeugen, wo alle Datenbanken & User inkludiert sind. Oft wird für jede Anwendung oder Dienst im Docker-Stack ein eigener Datenbank-Container aufgestellt, was technisch nicht falsch ist und auch nicht mehr Ressourcen verbraucht, aber den Wartungsaufwand erhöht.

 

[Rickmer]

Aber sofern kein Schreibzugriff erfolgt, ist ein Backup auch nicht wirklich problematisch. Ich sichere den Dockerordner jede Nacht zu einer Zeit, wo kein Zugriff erfolgt und habe noch nie Probleme gehabt und das seit vielen Jahren ohne die Container zu stoppen!

Ich verlasse mich nicht auf Glück und habe ein Skript, dass sich vor dem Backup per SSH an der Nextcloud anmeldet, die Wartung aktiv schaltet, dann das Backup abwartet und danach per SSH die Wartung der Nextcloud wieder deaktiviert.

Das SSH Passwort ist in eine Clixml verschlüsselt exportiert und steht nicht im Klartext im Skript oder auf dem Backup Server.

Das waren einmal ein paar Minuten an Einrichtung und seitdem kein zusätzlicher Aufwand.

 

[und tschüss]

Was auch immer. Richtig ist eh nur ein Dump! Spätestens, wenn die Datenbankversion angehoben wird, wird es interessant, je nachdem, welche Datenbank du verwendest. Generell hat jede Version 5 Jahre Sicherheitsupdates. Und wie bereits oben geschrieben, können die Datenbankcontainer auch einen Dump erzeugen.

SSH ist bei mir grundsätzlich deaktiviert und wird nur bei Benutzung aktiviert. Da brauche ich mir auch keinen Gedanken, um den SSH-Key zu machen.