Welche Sicherungsmethode hält einen laufenden Datenbank-Container auf einem Heim-NAS konsistent?

Für die meisten Heim-NAS- und selbstgehosteten Servernutzer ist der sicherste Standard ein datenbankspezifisches logisches Backup, das während des laufenden Datenbankbetriebs erstellt wird, gefolgt von einem normalen Backup dieses Dumps zusammen mit der Container-Konfiguration und den Anwendungsdateien. Verwenden Sie eine kurze gestoppte Container-Kopie, wenn Ausfallzeiten akzeptabel sind, und verwenden Sie einen koordinierten Dateisystem-Snapshot nur, wenn die Datenbank geleert, gesperrt, gecheckpt oder anderweitig für den Snapshot vorbereitet wurde. Eine einfache Kopie eines laufenden Datenbankvolumes ist keine konsistente Backup-Methode.

Definieren Sie „Konsistent“ als eine Wiederherstellung, die die Datenbank akzeptiert

Ein konsistentes Backup ist nicht nur ein vollständiger Ordnerbaum. Nach der Wiederherstellung muss die Datenbank-Engine starten, Transaktionen korrekt wiederherstellen, Integritätsprüfungen bestehen und einen zeitpunktbezogenen Zustand präsentieren, den die Anwendung nutzen kann. Auf einem Heimserver mit Immich, Nextcloud, Paperless-ngx, Home Assistant oder einer anderen selbstgehosteten App bedeutet das, dass Datenbank, Uploads, Konfiguration und Secrets miteinander übereinstimmen müssen.

Container-Persistenz erklärt nur, wo die Dateien gespeichert sind. Sie macht eine laufende Datenbank nicht sicher kopierbar. Eine Datenbank kann aktive Transaktionen, zwischengespeicherte Seiten, Write-Ahead-Logs, temporäre Dateien oder Metadaten haben, die sich ändern, während die NAS-Backup-Software das Volume liest.

Methode 1: Verwenden Sie einen datenbankspezifischen logischen Dump als Standard für Heim-NAS

Ein logischer Dump fordert die Datenbank-Engine auf, eine konsistente Darstellung von Schemata und Datensätzen zu exportieren. Für einen bescheidenen PostgreSQL- oder MariaDB-Container auf einem Familien-NAS ist dies normalerweise die einfachste Methode, um geplante Backups durchzuführen, zu überprüfen, extern zu kopieren und in einen sauberen Ersatzcontainer wiederherzustellen. Ein aktueller Docker-Backup-Leitfaden zeigt dieses Muster, indem datenbankspezifische Dumps aus einem geplanten Backup-Container ausgeführt werden.

Schreiben Sie den Dump in ein dediziertes Backup-Verzeichnis außerhalb des Live-Datenvolumes. Lassen Sie dann den NAS-Backup-Job den Dump, die Compose-Datei, die Umgebungs-Vorlage, die Anwendungs-Konfiguration und hochgeladene Daten schützen. Legen Sie keine Produktionspasswörter im Dump-Dateinamen oder in ungeschützten Logs offen.

Methode 2: Datenbank kurz anhalten, bevor das Volume kopiert wird

Eine Kopie eines gestoppten Containers ist einfach und physisch vollständig. Stoppen Sie zuerst die Anwendungsschreiber, stoppen Sie die Datenbank sauber, bestätigen Sie, dass der Prozess beendet ist, kopieren Sie das gesamte persistente Volume oder das bindgemountete Datenbankverzeichnis und starten Sie dann den Stack neu. Ein Docker- und MariaDB-Leitfaden beschreibt physische Volumenkopien als schnell, aber versionsabhängig und normalerweise mit Ausfallzeiten verbunden.

Diese Methode funktioniert gut für ein kleines Heim-NAS, bei dem ein paar Minuten Wartung akzeptabel sind und die Wiederherstellung eine kompatible Datenbankversion verwendet. Sie ist weniger portabel als ein logischer Dump und kann die Ausfallzeit verlängern, wenn das Volume groß ist. Bewahren Sie den Datenbank-Image-Tag und das Speicherlayout mit dem Backup auf, damit Sie keine physischen Dateien in eine inkompatible Engine-Version wiederherstellen.

Methode 3: Koordinieren Sie einen schnellen Snapshot mit der Datenbank

ZFS-, Btrfs-, LVM- und NAS-Snapshot-Systeme können ein großes Datenbankvolume schnell erfassen, aber der Snapshot muss mit der Datenbank koordiniert werden. Für MariaDB oder MySQL kann das ein kurzes Sperr- oder Flush-Fenster bedeuten; für PostgreSQL kann es der unterstützte Backup- oder Checkpoint-Prozess der Datenbank sein; für eine anwendungsverwaltete Datenbank kann es ein Pre-Snapshot-Hook sein.

Eine Diskussion über Datenbanksnapshots erklärt, dass eine Live-Kopie auf der Festplatte intern inkonsistent sein kann, es sei denn, die Datenbank wird eingefroren oder der Snapshot wird atomar erstellt. Das Sperr- oder Ruheintervall sollte kurz sein: Datenbank vorbereiten, Snapshot erstellen, Schreibzugriffe freigeben und den Snapshot später kopieren.

Diese Methode ist nützlich, wenn die Datenbank zu groß für häufige logische Dumps ist oder wenn ein geringeres Wiederherstellungspunktintervall benötigt wird. Sie erfordert sorgfältigeres Skripting und Wiederherstellungstests als ein grundlegender Home-Server-Dump-Workflow.

Behandeln Sie Docker-Image oder Container-Export nicht als Datenbanksicherung

Das Container-Image enthält die Anwendungs-Laufzeitumgebung, nicht unbedingt die live persistenten Daten. Das Exportieren oder Committen des Containers kann benannte Volumes auslassen und fordert die Datenbank nicht auf, einen konsistenten Wiederherstellungspunkt zu erstellen. Ein Backup-Konto für PostgreSQL-Container kommt zu dem Schluss, dass Docker save und commit keine PostgreSQL-spezifischen Backup-Techniken ersetzen.

Für einen ZimaOS- oder Docker-Heimserver halten Sie die Bereitstellungsdefinition und den Datenschutzplan getrennt: Bewahren Sie Compose-Dateien und Image-Tags auf, damit der Dienst neu aufgebaut werden kann, und bewahren Sie die Datenbank durch eine datenbankkonsistente Methode, damit ihr Zustand wiederhergestellt werden kann.

Kopieren Sie niemals ein aktiv beschriebenes Datenbankvolumen einfach so

NAS-Backup-Software kann verschiedene Datenbankdateien zu unterschiedlichen Zeitpunkten lesen. Das resultierende Archiv kann eine Datendatei aus einem Transaktionszustand, ein Log aus einem anderen und Metadaten aus einem dritten enthalten. Ein Überblick über Open-Source-SQL-Backup-Methoden warnt, dass eine Datenbank in Bewegung zu einem inkonsistenten Zeitpunkt erfasst werden kann, während wichtiger Zustand noch im Speicher ist.

Crash-Recovery kann einige atomar erfasste Snapshots reparieren, aber eine gewöhnliche rekursive Dateikopie ist nicht atomar. Wenn die App keine Ausfallzeit toleriert, verwenden Sie einen logischen Dump, ein unterstütztes physisches Backup-Tool oder einen koordinierten Snapshot.

Behandeln Sie SQLite-Container als Datenbanken, nicht als gewöhnliche Dateien

Viele Heimserver-Apps verwenden SQLite, weil es kompakt und einfach zu deployen ist. Das Risiko besteht darin, dass Administratoren eine .db-Datei sehen und annehmen, sie könne kopiert werden, während die App schreibt. Im WAL-Modus können kürzlich abgeschlossene Änderungen noch außerhalb der Hauptdatei liegen. Ein praktischer SQLite-Wiederherstellungsartikel empfiehlt die Nutzung des Online-Backup-Mechanismus oder eine sauber geschlossene Kopie statt das Kopieren einer laufenden Datenbankdatei.

Verwenden Sie das integrierte Backup der Anwendung, falls vorhanden. Andernfalls nutzen Sie die eigene Online-Backup-Funktion von SQLite oder stoppen Sie die Anwendung sauber, bevor Sie das gesamte Datenbankverzeichnis kopieren. Kopieren Sie nicht nur die Hauptdatenbankdatei und lassen Sie das Journal oder den WAL-Zustand zurück.

Wählen Sie die Methode nach Ausfallzeit, Datenbankgröße und Wiederherstellungsportabilität

Sichern Sie die gesamte selbstgehostete Anwendung, nicht nur die Datenbank

Ein brauchbares Wiederherstellungspaket sollte das Datenbank-Backup, die Docker-Compose-Datei, Image-Versionen, Umgebungsvariablen oder ein wiederherstellbares Geheimnis-Paket, Reverse-Proxy-Einstellungen, Anwendungskonfiguration, hochgeladene Dateien und alle Verschlüsselungsschlüssel enthalten. Nur das SQL-Dump zu sichern, kann Datensätze wiederherstellen, aber die App daran hindern, Fotos, Dokumente, Thumbnails, Zertifikate oder Speicherpfade zu finden.

Für die Wiederherstellungsplanung von Heimservern erklärt der ZimaSpace-Leitfaden zu Bind-Mounts und benannten Volumes, warum sichtbare Speicherpfade die Wiederherstellung unterstützen, aber dennoch kein anwendungs-konsistentes Datenbank-Backup ersetzen.

Beweisen Sie die Methode durch Wiederherstellung in einem neuen Container

Erstellen Sie einen isolierten Test-Stack mit einem neuen Projektnamen, anderen Host-Ports und einem temporären Datenverzeichnis. Stellen Sie den Dump oder Snapshot wieder her, starten Sie die Datenbank, führen Sie Integritäts- oder Konsistenzprüfungen durch und verbinden Sie dann eine Testkopie der Anwendung. Bestätigen Sie, dass Benutzer, Datensätze, Anhänge und aktuelle Transaktionen vorhanden sind.

Messen Sie sowohl den Wiederherstellungspunkt als auch die Wiederherstellungszeit. Wenn ein logischer Dump konsistent ist, aber zu lange zum Wiederherstellen benötigt, behalten Sie ihn als portable Wiederherstellungsschicht und fügen Sie einen schnelleren koordinierten Snapshot hinzu. Wenn eine Kopie des gestoppten Volumens schnell wiederhergestellt wird, aber nur auf dieselbe Datenbankversion, behalten Sie einen logischen Dump als Fallback für Migrationen.

FAQ

Reicht es aus, einen Datenbank-Container vor dem Kopieren des Volumens zu pausieren?

Nicht als allgemeine Regel. Das Pausieren friert den Prozess ein, beweist aber nicht, dass die Datenbank den korrekten Zustand für ein portables Backup geschrieben hat. Verwenden Sie einen datenbankspezifischen Dump, ein sauberes Herunterfahren oder ein dokumentiertes Quiesce-und-Snapshot-Verfahren.

Reicht ein NAS-Snapshot allein für PostgreSQL oder MariaDB aus?

Nur wenn der Snapshot atomar und mit dem von der Datenbank unterstützten Konsistenzprozess koordiniert ist. Ein unkoordinierter Snapshot kann lediglich absturzkonform sein, und eine nicht-atomare Dateikopie kann noch schlechter sein.

Was sollte ich für eine SQLite-basierte Heimserver-App sichern?

Verwenden Sie den Export der App oder das SQLite-Online-Backup, wenn verfügbar. Bewahren Sie außerdem die App-Konfiguration, die Compose-Datei, Geheimnisse, Anhänge und das Verzeichnis, das die Datenbank enthält, auf, anstatt nur die Hauptdatei anzunehmen. .db Datei ist die gesamte Anwendung.

Endgültige Empfehlung

Verwenden Sie geplante logische Dumps als Standard für die meisten PostgreSQL- und MariaDB-Container auf einem Heim-NAS. Verwenden Sie eine saubere Kopie des gestoppten Volumens, wenn eine kurze Ausfallzeit akzeptabel ist, und verwenden Sie koordinierte Snapshots oder datenbankspezifische physische Tools, wenn die Datenbank groß ist oder das Wiederherstellungspunktfenster eng ist. Welche Methode Sie auch wählen, stellen Sie sie in einem neuen Container wieder her, bevor Sie ihr vertrauen.