Komplettes Backup der Docker Container und/oder VMs

Zitat von AcidRain

das Plugin sichert ja im Endeffekt nur die Daten innerhalb der Docker Container, die Docker selbst aber nicht, oder?

Man sichert auch keinen "Docker". Der Container selbst sollte immer "Stateless" sein. "Stateless" heißt also "Zustandslos". Der Container weiß nur so viel, wie du ihm gibst. Man sichert die Nutzdaten des Dockers, die, wenn es relevante Daten sind, als Volume in den Docker gemountet werden und somit nativ auf der Platte eines Docker-Servers liegen. Diese Daten kann man dann in einen Backup-Prozess mit einbeziehen. Musst du deinen Server neu aufsetzen, dann fährst du dir einen neuen Docker hoch, mountest die Daten rein und bist fertig.

Das einzige, was man noch sichern könnte ist das Dockerfile welches man sich geschrieben hat oder das "Docker-Compose"-File damit Dinge mit dem richtigen Image, in der richtigen Reihenfolge oder im richtigen Netzwerk gestartet werden.

Den Docker selbst, also den Container an sich, brauchst du nicht zu sichern. Der sollte "Schall und Rauch" sein.

Nimm dir mal die 3 Stunden:

Die werden dein Leben in Bezug auf Docker verändern

Ich verstehe absolut, was du meinst.

Wenn sich ein Container ändert oder der Container eine andere Configuration benötigt, dann ist ohnehin eine Umstellung nötig. Da kommst du gar nicht drumherum. Was bringt dir das Backup einer Konfiguration einer Software, wenn die Konfiguration auf eine neuere Version der Software nicht mehr anwendbar ist? Richtig...nichts.

Was ich IMMER mache, wenn ich mir einen Docker anlege. Ich lege mir einen Ordner an, in dem ich eine README.md Datei lege. Dort schreibe ich rein, wie ich den Docker aufgesetzt habe und was welche Einstellung wo bewirkt. Ich schreibe also (und jetzt verwende ich das böseste Wort in der IT ) "Dokumentationen"

Keine Sorge...ich mach mich nicht lustig. Ganz und gar nicht ;). Aber Dokumentationen, wie du etwas aufgesetzt hast, sind das "A" und "O". Gerade bei etwas, was so Stateless ist, wie ein Docker.

Viele Container benutzen die --env Parameter um eine entsprechende Configuration dem Container mitzugeben. Das kommt dann natürlich auch auf den Docker an ob der dir diese Möglichkeit bietet. Du kannst einem Container auch ein "env"-File mitgeben. Das ist übrigens in dem Video oben nicht beschrieben. Leider.

Aber wie gesagt..wenn sich die Konfiguration des Dienstes, der dir durch den Docker angeboten wird, ändert...dann hilft dir jegliches Backup nichts.

Ein Beispielt....

Ich starte einen MariaDB Container mit folgendem Befehl:

docker run --name kodi-mariadb --env MARIADB_ROOT_PASSWORD=root_pw -d mariadb:10.7.1

Dort ist --env MARIA_ROOT_PASSWORD als "Umgebungsvariable" gegeben. Das möchte der Container so haben und damit konfiguriere ich die DB innerhalb des Containers. Jetzt mache ich mir eine README.md davon. Dann vergehen 3 Jahre und MariaDB ist dann vielleicht in Version "20" verfügbar. Dort haben sie vielleicht irgendwann den Parameter (die "Umgebungsvariable") von MARIADB_ROOT_PASSWORD zu MARIADB_MAIN_USER_PASSWORD geändert. BOOM....schon passt weder meine Konfig noch meine Dokumentation noch würden meine potentiell exportierten Konfig-Dateien passen.

Damit die passen, darfst du halt nicht updaten. "Nicht updaten" ist aber genauso beschissen

Willkommen in der Welt der IT in der sich ständig Dinge ändern und du dich immer wieder mit Dokumentationen rumschlagen und dich immer wieder aufs Neue einlesen werden musst.

Wenn du bei der entsprechenden Version bleiben möchtest und nicht updatest, dann kannst du natürlich

• den Container hoch fahren
• dich darauf "attachen"
• schauen welche Dateien zur Konfiguration benötigt werden
• dir eine Notiz machen
• den Container wieder runter fahren
• den Container erneut hoch fahren und die Ordner, in denen die Konfigdateien liegen aus dem Container heraus-mounten.

Dann würden die Config-Dateien auf der Festplatte liegen und du könntest sie einem Backup-Prozess unterziehen. Das hilft dir aber nur nicht, wenn sich die Software ändert und eine andere Konfiguration benötigt. Denn dann passt es nicht mehr. Das ist auch der Grund warum meine KEINE Container mit :latest als Tag startet. Man weiß nicht, welche Version in 3 Jahren verwendet wird, wenn ich den Container mal neu starten muss