Praxis: Backup Docker Container-Daten: Volumes / Bind Mounts

This page is also available in English

In meinem Artikel ÔÇ×Alle Docker-Container: Host ├╝bersiedeln, Theorie und PraxisÔÇť, bin ich bereits ein klein wenig auf das Thema Backup eingegangen. Wer den Artikel verfolgt hat, wei├č, dass ich die Daten meiner Docker-Container ├╝ber Bind-Mounts auslagere und mit rsync sichere. Gestartet wird der Backup-Job ├╝ber crontab. Doch zun├Ąchst habe ich mir Gedanken gemacht, was beim Einsatz von Docker in einem Single-Server-Setup eigentlich gesichert werden muss:

Docker Container Backup?

Bei der Verwendung von Volumes oder Bind-Mounts m├╝ssen die Containerdaten nicht gesichert werden. Voraussetzung ist allerdings, dass der Container beim Austausch oder Neuanlegen mit den urspr├╝nglichen Optionen oder mit der urspr├╝nglichen Docker Compose-Datei erstellt wird. Aus diesem Grund empfehle ich die Verwendung von Docker Compose, da die docker-compose.yml-Datei verschiedene Container einfach zu einem Service kombinieren kann und dabei s├Ąmtliche Optionen f├╝r das Erstellen der Container in einer Datei hinterlegt und damit dokumentiert. Ein einfaches "docker compose up" startet die hinterlegten Container mit den angegebenen Optionen, auch wenn die Container noch nicht oder nicht mehr vorhanden sind. Daten, die dabei nicht verloren gehen sollen, k├Ânnen in Volumes oder Bind-Mounts, also bestimmten Ordnern au├čerhalb des Containers ausgelagert werden. Das Wichtigste an einem Container sind also die verwendeten Optionen, mit denen dieser erstellt wurde - am einfachsten in Form einer docker-compose.yml-Datei - und die Daten der verwendeten Volumes oder Bind-Mounts.┬áF├╝r das Sichern von Docker Volumes schaut der offizielle Weg wie folgt aus:

Backup / Restore: Docker Volumes

Ein Blick in die offizielle Dokumentation von Docker empfiehlt f├╝r ein Backup oder Restore einen eigenen Container zu starten und das Volume ├╝ber einen Bind-Mount auf den Host zu ├╝bertragen:

Volume sichern:

docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

Volume wiederherstellen:

 docker run --rm --volumes-from datavolume-name -v $(pwd):/backup image-name bash -c "cd /path-to-datavolume && tar xvf /backup/backup.tar --strip 1"

Quelle, siehe: https://docs.docker.com/storage/volumes/ (Abrufdatum: 06.09.2022)

Mir ist bewusst, dass Docker-Volumes die bevorzugte Variante f├╝r das Speichern von Docker-Daten sind, ich habe mich bei meinem Setup dennoch gegen den Einsatz von Volumes entschieden. Der Grund daf├╝r ist, dass einfache Ordner (Bind-Mounts) von einem einzelnen Server wesentlich einfacher gesichert werden k├Ânnen. Siehe auch, Docker Volumes.

Bind-Mounts sichern

Beim Einsatz von Bind-Mounts k├Ânnen bestimmte Ordner der Docker-Container auf einen definierten Ordner am Host gemappt werden. Die Ordner enthalten alle relevanten Daten der Container, wodurch sich auch das Backup auf diese Ordner beschr├Ąnkt. Ein besonderes Augenmerk sollte dabei auf die verwendeten Datenbanken gelegt werden:

MySQL-Datenbank im laufenden Betrieb kopieren

Wird eine Datenbank im laufenden Betrieb kopiert, ist nicht sichergestellt, dass die Datenbank am Ziel konsistent ist. Auch wenn ich in der Vergangenheit immer wieder mal MySQL-Datenbanken im Betrieb auf meine Entwicklungsumgebung kopiert habe, hatte ich dennoch noch nie ein Problem mit einer Datenbank. Ob ein Problem entstehen kann, liegt an den Daten und haupts├Ąchlich auch daran, wie viele Daten w├Ąhrend des Kopierens ver├Ąndert werden. Fakt ist, dass das Kopieren einer Datenbank im laufenden Betrieb nicht ganz sauber ist und Probleme verursachen k├Ânnte.

L├Âsung f├╝r MySQL: mysqldump

Wer einen Dump einer laufenden Mysql-Datenbank erstellen m├Âchte, sollte daf├╝r mysqldump verwenden. Mit mysqldump kann die Datenbank exportiert und am Zielsystem importiert werden, siehe: MySQL Befehle in Linux: Verbindung, Datenbank, Backup. Mysqldump sollte vorbereitend zu einem Backup ausgef├╝hrt werden, wodurch┬ádas erstellte Abbild der Datenbanken in das Backup aufgenommen werden kann. Da die Dumps alle Daten enthalten, m├╝ssen die eigentlichen Datenbankfiles des Containers nicht zus├Ątzlich kopiert werden.

Ôôś
Ich verwende mysqldump zus├Ątzlich zur Datensicherung.
Die erzeugten Datenbank-Dumps k├Ânnen einfach zu einem Kopierauftrag hinzugef├╝gt werden.

Hier ein Befehl von dem Remote-Computer mit dessen Hilfe ich das Backup erstelle. Der Befehl verbindet sich mit SSH auf den Server und erstellt im Datenbankcontainer einen Dump mit mysqldump und schreibt diesen in eine Datei.

ssh root@server.domain.tld "docker exec mysqlcontainer mysqldump --user=root --password=??? mysqlusername | gzip -c > /backups/db/mysqlcontainerdump.gz"

Container stoppen

Alternativ k├Ânnte der Container f├╝r die Datenbank auch gestoppt, die Files gesichert und die Datenbank im Anschluss wieder gestartet werden. Nachdem diese Variante mit einer kurzen Downtime verbunden ist, w├╝rde ich die Vorgehensweise nicht f├╝r ein Backup empfehlen.┬á

rsync -rltD --delete /var/web/libe.net/db/ /var/web/libedbcopy
docker stop libenet_libenet-mysql.1.csubj0bcuu8ssd9xyg6rbyve5  
rsync -rltD --delete /var/web/libe.net/db/ /backup/dbcopy
docker start libenet_libenet-mysql.1.csubj0bcuu8ssd9xyg6rbyve5  

Diese Variante habe ich zuletzt beim ├ťbersiedeln meines Servers versucht, siehe: Webserver mit Docker Container umziehen, Theorie und Praxis

In der Praxis: Wie ich meine Containerdaten sichere

Ich verwende Docker auf einem V-Server im Internet und zu Hause auf meiner NAS. Die Docker Container am gemieteten V-Server ├╝bertrage ich mittels rsync t├Ąglich auf meine NAS und die Daten der NAS auf eine externe Festplatte und zus├Ątzlich auf meinen Linux Receiver, siehe auch: www.script-example.com/rsync-bash-funktion.

Ich verwende als Vorbereitung f├╝r ein Backup oder das ├ťbersiedeln von Container jeweils einen Ordner pro Applikation. Innerhalb des Ordners habe ich die Optionen f├╝r das Erstellen der Container in Form einer docker-compose.yml - Datei hinterlegt und als Unterordner die im docker-compose-yml-File verwendeten Bind-Mounts angelegt. Exemplarisch habe ich alle relevanten Daten eines Docker-Services ca. wie folgt organisiert:

  • ./dockerService1/docker-compose.yml
  • ./dockerService1/db/* ... Datenbankdateien
  • ./dockerService1/conf/* ... persistente Konfigfiles

In den Docker-Compose Dateien k├Ânnen die Ordner relativ zum Docker-compose-File angegeben werden

version: '3.1'

services:
  service1:
    image: test
    ...
    volumes:
      - ./dockerService1/www:/var/www

Siehe auch: Docker Daten speichern: Docker Volumes vs. Host-Ordner

Beim Einsatz von Datenbanken k├Ânnte zudem ein weiterer Unterordner f├╝r die Datenbandumps erstellt werden:

  • ./dockerService1/dbdumps/* ... Datenbankdumps

Dadurch, dass ich die eigentlichen Daten der Datenbank mithilfe von mysqldump in den dbdumps-Ordner sichere, m├╝sste ich die eigentlichen Datenbankdateien nicht mitsicher und k├Ânnte diese auch an einen anderen Ort ablegen. Auch der Einsatz von Volumes f├╝r die Datenbankfiles w├Ąre an dieser Stelle denkbar. Im Fehlerfall k├Ânnen die Dumps restored und die Datenbank somit wiederhergestellt werden.

Um den hier beschriebenen dockerService1 zu sichern, reicht es alle Dateien und Ordner unterhalb von dockerService1 zu sichern:

  • Die Datei docker-compose.yml kann den Docker-Container im Fehlerfall oder bei einem Serverwechsel erneut erstellen und
  • alle persistenten Userdaten werden ├╝ber Bind-Mounts in den Container gemappt.

Für die Datenbankcontainer habe ich in die Bash-Datei von script-example.com die hier beschriebene mysql-dump-Zeile eingefügt. 

#!/bin/bash
LOGFILE="/var/log/rsync.txt"
# ... Variablen und backup-Funktion von https://www.script-example.com/rsync-bash-funktion
# ...
ssh root@domain.tld "docker exec mysqlcontainername mysqldump --user=root --password=dbpassword dbname | gzip -c > /var/web/webservicename/dbdumps/dump.gz"
backup '-e ssh root@domaintld:/var/web' /backup/cloud
# ...
#Finish Script: Runtime-Information and Final-Summary: siehe: https://www.script-example.com/rsync-bash-funktion

Der Mysqldump wird dabei am Webserver abgelegt (ssh root@ ...) und mit rsync ├╝bertragen (backup '-e ssh ...)

Damit der Backup-Job jeden Tag l├Ąuft, habe ich das Bash-Script in Crontab eingef├╝gt:

22 0 * * * sudo /scripts/rsync-backup.sh > /dev/null 2>&1

siehe auch: Linux CronJobs - geplante Tasks | Debian crontab [erkl├Ąrt]

Fazit

Mit rsync und optional mysqldump und dem richtigen Ordner-Layout ist es sehr einfach alle Docker-Containerdaten eines Single-Server-Setups auf einen anderen Host zu ├╝bertragen und damit ein Backup zu erstellen. Um mehrere Versionen der Daten abzulegen, k├Ânnten am Backup-Host Filesystemsnapshots verwendet werden, siehe auch: ZFS vs BTRFS - Filesystem | Deduplizierung und Snapshots. Dadurch, dass Daten mit rsync auf dem Backup-Host in derselben Form wie am Quellhost abgelegt werden k├Ânnen, w├Ąre es auch denkbar die Container im Fehlerfall auf dem Backup-Host zu starten und diesen theoretisch als Standby-Server zu verwenden. Voraussetzung daf├╝r ist nat├╝rlich eine geeignete Hardware und eine geeignete Netzwerkanbindung.

positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE f├╝r deine Bewertung!

Aktualisiert: 26.12.2022 von Bernhard ­čöö


Top-Artikel in diesem Bereich


ioBroker installieren - Docker
Mit ioBroker k├Ânnen verschiedene Automatisierungsl├Âsungen oder Ger├Ąte in einem System zusammengefasst werden. Um bestimmte Gateways oder Ger├Ąte ansprechen zu k├Ânnen, werden in ioBroker verschiedene Adapter verwendet.

Home-Assistant Docker Conbee 2 und Zigbee2MQTT / deCONZ
Dank zahlreicher Integrationsm├Âglichkeiten ist Home-Assistant eine einfache Plattform f├╝r das Steuern verschiedenster Smart-Home Ger├Ąte. Im Vergleich zu ioBroker ist mir der Start mit Home Assistant wesentlich einfacher gefallen. W├Ąhrend ich f├╝r ioBroker noch am Suchen war, welches Frontend ich f├╝r meine Dashboards verwenden k├Ânnte, hatte ich mit Home-Assistant out of the box ein fertig eingerichtetes System. Die Lovelance Dashboards von Home Assistant k├Ânnen einfach in der GUI zusammengeklickt...

Bitwarden in Docker betreiben - Setup Schritt f├╝r Schritt
Bitwarden ist ein webbasierter Passwort-Manager, ├Ąhnlich LastPass, aber Open Source und der M├Âglichkeit diesen selbst zu betreiben (hosten). Wie sich Bitwarden im Vergleich zu anderen Passwort-Managern einordnet, habe ich auf folgender Seite ├╝berlegt: Passwort-Manager sicher? KeePass vs. LastPass vs. Bitwarden. Bitwarden besteht aus mehreren Services, welche ├╝ber verschiedene Container bereitgestellt werden k├Ânnen. Das relativ aufw├Ąndige Setup wurde mit "Bitwarden Unified" speziell f├╝r ein Selbs...

Fragen / Kommentare


Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details