So verschieben Sie Containerdaten in einen SSD-Pool, ohne Mount-Pfade zu beschädigen

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Verschieben Sie die hostseitige Datenquelle auf die SSD, während jeder containerseitige Zielpfad unverändert bleibt.

Bei einer sicheren Migration wird die aktuelle Mount-Zuordnung als Schnittstellenvertrag behandelt. Container, Datenbanken und Medien-Apps erwarten Pfade wie /config, /data oder /media, unabhängig davon, welcher Datenträger sie bereitstellt. Der Ablauf muss Schreibvorgänge stoppen, die SSD vorhersehbar einhängen, Eigentümer und Metadaten kopieren, nur die Host-Quelle aktualisieren, den neuen Mount vor dem Start überprüfen und die ursprünglichen Daten aufbewahren, bis ein vollständiger Wiederherstellungstest erfolgreich war.

Jede aktuelle Quelle und jedes Containerziel erfassen

Exportieren Sie die Compose-Datei oder die Container-Inspektionsdaten und listen Sie jeden Bind-Mount, jedes benannte Volume, jeden tmpfs-Mount, jedes Datenbankverzeichnis, jeden Cache, jeden Transkodierungspfad und jeden Medienpfad auf. Erfassen Sie die Host-Quelle und das Containerziel getrennt.

Ein praxisnaher Leitfaden zur Volume-Migration beginnt damit, die aktuellen Daten zu lokalisieren und die Container zu stoppen, bevor die Daten an einen neuen Speicherort auf dem Datenträger kopiert werden. Diese Bestandsaufnahme verhindert, dass Konfigurationsdaten auf dem Systemdatenträger zurückbleiben.

Kennzeichnen Sie, welche Pfade den maßgeblichen Status, wiederherstellbare Caches und große Mediendateien enthalten. Gehen Sie nicht davon aus, dass ein Ordner namens data den gesamten dauerhaften Anwendungsstatus enthält.

Den SSD-Pool vor dem Docker-Start vorhersehbar einhängen

Erstellen Sie das SSD-Dateisystem oder den Pool, identifizieren Sie ihn anhand einer stabilen UUID oder eines Poolnamens und hängen Sie ihn am endgültigen Hostpfad ein. Überprüfen Sie nach einem Neustart den freien Speicherplatz, die erwarteten Dateisystemfunktionen und den Schreibzugriff.

Das Verschieben von Docker-Daten auf einen externen Speicher kann fehlschlagen, wenn der Datenträger fehlt oder beim Start an einem anderen Pfad eingehängt wird. Ein aktueller Fall mit einer externen SSD zeigt, wie die Verlagerung des Docker-Speichers die Abhängigkeit vom Ziel-Mountpfad verändert.

Konfigurieren Sie die Dienstreihenfolge oder das Automount-Verhalten so, dass Docker niemals ein leeres Fallback-Verzeichnis auf dem Systemdatenträger erstellt. Brechen Sie den Vorgang ab, wenn die SSD nicht am exakt erwarteten Pfad eingehängt ist.

Schreibvorgänge stoppen und Daten mit erhaltenen Metadaten kopieren

Stoppen Sie die Anwendung und jede Abhängigkeit, die in ihre Daten schreiben kann, einschließlich Datenbanken, Indexern, Downloadern und Hintergrundaufgaben. Verwenden Sie bei Datenbanken vor dem Kopieren von Rohdateien einen anwendungskonsistenten Dump oder ein sauberes Herunterfahren.

Eine Diskussion zu Synology-Containern empfiehlt, ein von Docker verwaltetes Volume erst dann in einen Bind-Mount zu verschieben, wenn die Volume-Daten identifiziert wurden und ihr Inhalt an der neuen Bind-Mount-Quelle erhalten wurde.

Kopieren Sie rekursiv und bewahren Sie dabei Eigentümer, Berechtigungen, Zeitstempel, Links, ACLs und, sofern unterstützt, erweiterte Attribute. Führen Sie nach dem Kopieren und vor der Änderung der Compose-Datei einen Vergleich im Testmodus oder eine Stichprobe per Prüfsumme durch.

-15% OFF

Nur den Host-Quellpfad ändern

Behalten Sie das Containerziel unverändert bei. Ändern Sie beispielsweise /oldpool/app:/config in /ssdpool/app:/config, anstatt der Anwendung einen neuen internen Pfad beizubringen.

Bind-Mounts stellen einen exakten Hostspeicherort unter einem stabilen Pfad innerhalb des Containers bereit. Eine Übersicht zum Speicher erklärt, dass diese direkte Zuordnung nützlich ist, wenn Administratoren Kontrolle über den hostseitigen Pfad benötigen.

Durch die Beibehaltung des Zielpfads vermeiden Sie Probleme mit Anwendungsdatenbanken, Bibliotheksverweisen, Skripten, Berechtigungen und Konfigurationswerten, in denen der containerseitige Pfad gespeichert ist.

Eigentümer, Labels und Datenbankkonsistenz wiederherstellen

Vergleichen Sie die von dem Image erwarteten numerischen UID- und GID-Werte mit den Eigentümern auf der SSD. Stellen Sie außerdem ACLs, SELinux-Labels, AppArmor-Freigaben und die für Sperren oder speicherabgebildete Dateien erforderlichen Mount-Optionen wieder her.

Ein Leitfaden zur Migration des Docker-Speichers unter macOS weist darauf hin, dass beim Verschieben von Docker-Daten das vollständige Speicherabbild kopiert und anschließend bestätigt werden muss, dass die Laufzeitumgebung den neuen Speicherort verwendet. Auf Linux-NAS-Systemen besteht die entsprechende Prüfung darin, sicherzustellen, dass jede konfigurierte Quelle auf die eingehängte SSD verweist.

Starten Sie zunächst nur die Datenbank und prüfen Sie die Wiederherstellungsprotokolle, bevor Sie abhängige Apps starten. Wenn eine Beschädigung oder fehlende Dateien gemeldet werden, brechen Sie den Vorgang ab und kehren Sie zur ursprünglichen Kopie zurück, anstatt Anwendungen eine leere Datenbank initialisieren zu lassen.

Mit Rückfalloption umstellen und den vollständigen Ablauf testen

Starten Sie den Stack in Abhängigkeitsreihenfolge und überprüfen Sie Konfiguration, Datenbankeinträge, Berechtigungen, Medienbibliotheken, Uploads, Downloads, Aktualisierungen und die Neuerstellung der Container. Prüfen Sie, ob neue Schreibvorgänge auf der SSD landen und der Systemdatenträger nicht weiter wächst.

Der ZimaSpace-Artikel über einen plötzlich schreibgeschützten Docker-Bind-Mount behandelt die nächsten Diagnoseschritte, wenn der migrierte Pfad zwar eingehängt wird, aber Schreibvorgänge ablehnt.

Bewahren Sie die alten Daten offline und unverändert auf, bis Backups und eine zweite Neuerstellung der Container über den SSD-Pfad erfolgreich waren. Entfernen Sie die alte Quelle erst, nachdem eine Rückfallübung gezeigt hat, dass Sie die Compose-Datei, Mounts, Datenbanken und den Anwendungsstatus wiederherstellen können.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.