Docker-Daten liegen auf dem Server – warum ein Bind Mount noch kein Backup ist

Viele meiner Docker-Dienste speichern ihre Daten direkt auf dem Server. Datenbanken, Uploads und Konfigurationen liegen als Bind Mount unter /opt, /srv oder einem anderen Verzeichnis. Entferne ich einen Container und erstelle ihn neu, sind diese Daten noch da. Praktisch. Ein Backup ist es trotzdem nicht.

Den Unterschied merkt man spätestens bei einer kaputten SSD oder einem versehentlich gelöschten Ordner. Dann sind Container und Bind Mount gemeinsam weg. Ein benanntes Docker-Volume ändert daran wenig, solange es auf demselben Server liegt.

Wo liegen die Daten überhaupt?

Ich beginne mit der compose.yml. Unter volumes: stehen zum Beispiel Einträge wie ./db_data:/var/lib/mysql oder /srv/nextcloud/dateien:/var/www/html/data. Links steht die Quelle auf dem Host, rechts das Ziel im Container.

Was tatsächlich eingebunden wurde, lässt sich zusätzlich prüfen:

docker inspect CONTAINERNAME

Daraus mache ich mir eine kleine Liste. Welche Verzeichnisse enthalten Uploads? Wo liegt die Konfiguration? Welche Schlüssel brauche ich nach einer Neuinstallation? Einen Cache muss ich meistens nicht sichern. Alles, was nicht einfach aus Image oder Git-Repository zurückkommt, schon.

Bei Datenbanken reicht Kopieren nicht

Früher hätte ich wahrscheinlich einfach den kompletten MariaDB-Ordner in die Sicherung gepackt. Während die Datenbank läuft, können sich die Dateien aber mitten im Kopiervorgang ändern. Das Archiv ist dann vorhanden und sieht gut aus, lässt sich im Ernstfall aber womöglich nicht sauber starten.

Deshalb erzeugt mein Backup-Skript zuerst einen Dump jeder wichtigen Datenbank. Danach sichert Borg diese Dumps zusammen mit den eingebundenen Verzeichnissen. Bei einem Dienst mit Uploads sollten Datenbank und Dateien möglichst aus demselben Lauf stammen. Sonst kennt die Datenbank vielleicht schon ein Bild, das im gesicherten Upload-Ordner noch fehlt.

So läuft es bei mir

Nachts startet ein systemd-Timer. Zuerst werden die Datenbanken exportiert. Danach nimmt Borg die benötigten Ordner unter /opt, /srv, /var/www und /home sowie die neuen Dumps auf. Das Archiv landet außerhalb meines Servers auf einer Storage Box.

Nur weil der Timer ohne rote Meldung endet, bin ich noch nicht fertig. Ich schaue in das Protokoll, prüfe die Größe des Archivs und den freien Platz am Ziel. Ein auffällig kleines Backup kann genauso verdächtig sein wie ein abgebrochener Lauf.

Mal wirklich etwas zurückholen

Der wichtigste Test ist erstaunlich unspektakulär: Ich stelle eine harmlose Konfigurationsdatei und einen Datenbank-Dump in einem temporären Ordner wieder her. Dort prüfe ich, ob beide lesbar sind. Dafür muss ich keinen produktiven Container überschreiben.

Erst dabei fällt auf, ob Repository, Zugangsdaten und Pfade tatsächlich zusammenpassen. Ein Backup, das nie testweise geöffnet wurde, ist für mich eher eine Hoffnung als eine Sicherung.

Meine grundsätzliche Einrichtung beschreibe ich im Beitrag BorgBackup unter Debian und Ubuntu einrichten. Die Docker-Verzeichnisse sind darin nur ein weiterer, aber wichtiger Baustein.

Wann habt ihr zuletzt nicht nur das Log gelesen, sondern wirklich eine Datei aus eurem Backup zurückgeholt?