Workflow zur Migration benannter Docker-Volumes zwischen zwei Heimservern

Der sichere Ansatz besteht darin, ein stillgelegtes Archiv oder eine synchronisierte Kopie in ein ausdrücklich identifiziertes Ziel-Volume zu übertragen und anschließend eine Prüfung per Prüfsumme sowie eine Anwendungsvalidierung als Abfolge beobachtbarer Prüfschritte zu behandeln, nicht als einzelnen Befehl.

Auf zwei Linux-Heimservern mit Docker Compose besteht das praktische Risiko darin, dass ein zustandsbehafteter Container auf einen anderen Host verschoben werden muss, ohne ein aktives oder falsch benanntes Volume zu kopieren. Erfassen Sie zunächst die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungsmerkmal, interpretieren Sie erfolgreiche und fehlgeschlagene Ergebnisse, bevor Sie eine weitere Variable ändern, und stoppen Sie, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie offengelegt würde. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Beweislage eine Eskalationsgrenze erreicht.

Quell- und Ziel-Volume-Verträge identifizieren

Erfassen Sie den Image-Digest des Quellcontainers, den Compose-Projektnamen, den Dienst, den Volume-Schlüssel, den tatsächlichen Docker-Volume-Namen, das Einhängeziel, den Volume-Treiber und die Anwendungsversion. Verwenden Sie docker inspect und docker volume inspect; leiten Sie den physischen Pfad nicht allein aus einer YAML-Bezeichnung ab.

Compose versieht benannte Volumes normalerweise mit dem Projektnamen als Präfix, sofern kein expliziter Name oder ein externes Volume verwendet wird. Rendern Sie auf dem Ziel die Compose-Konfiguration und erstellen Sie das vorgesehene leere Volume ausdrücklich, damit die Migration nicht in einem Volume landet, während der Dienst ein anderes startet.

Wenn das Volume eine Datenbank enthält, verwenden Sie deren nativen Dump oder eine unterstützte Sicherung als primären portablen Wiederherstellungspfad und behandeln Sie die Volume-Kopie als Wiederherstellungspunkt für dieselbe Version. Stoppen Sie, wenn der Treiber remote ist, der Quellspeicher instabil wird oder der Anwendungsstatus zusätzliche Volumes umfasst, die nicht Teil des Umfangs sind.

Schreibvorgänge stilllegen und eine metadatenerhaltende Kopie erstellen

Versetzen Sie die Anwendung in den Wartungsmodus, stoppen Sie Hintergrundaufgaben und beenden Sie anschließend Anwendung und Datenbank ordnungsgemäß. Bestätigen Sie, dass kein Container das Volume mit Schreibzugriff eingehängt hat. Erstellen Sie ein Archiv über einen temporären Container oder verwenden Sie eine kontrollierte Dateisystemkopie, die numerische Eigentümer, Berechtigungen, symbolische Links, bei Bedarf erweiterte Attribute und Sparse-Dateien erhält.

Eine unabhängige Anleitung zur Migration von Docker-Volumes mit rsync zeigt, wie Volume-Daten mit rsync verschoben werden. Entscheidend ist, dass die Quelle stillgelegt sein muss und der Kopierbefehl auf den Inhalt des identifizierten Volumes zugreift, statt blind das interne Docker-Verzeichnis zu manipulieren, während der Daemon es verwendet.

Erstellen Sie ein Manifest mit Dateianzahl, Gesamtgröße in Bytes, repräsentativen Hashes und Archivprüfsumme. Lassen Sie das Quell-Volume und die native Sicherung unverändert; die Kopierstufe ist nur dann erfolgreich, wenn das Übertragungsartefakt auf dem Zielhost lesbar ist.

In das ausdrücklich angegebene Ziel-Volume wiederherstellen

Überprüfen Sie die Kapazität des Zieldateisystems, die Verfügbarkeit von Inodes, die erwarteten UID- und GID-Zuordnungen sowie die Version des Anwendungs-Images. Stellen Sie das Archiv in das leere Ziel-Volume wieder her, ohne dessen Verzeichnisstruktur auf oberster Ebene abzuflachen, und vergleichen Sie anschließend Eigentümer, Anzahlen, Größen und ausgewählte Hashes.

Eine Community-Diskussion über den Fehlerfall bei der Migration eines benannten Volumes zeigt, warum das direkte Ersetzen von Dateien in den internen Docker-Volume-Verzeichnissen fehlschlagen oder einen verwirrenden Zustand hinterlassen kann. Verwenden Sie die Laufzeit, um das Volume in einen Hilfscontainer einzuhängen, und führen Sie die Wiederherstellung über diese kontrollierte Schnittstelle durch.

Verbinden Sie zunächst nur eine verworfene Kopie des Dienstes und verwenden Sie alternative Ports ohne Zugriff auf produktive Gegenstellen. Wenn die Anwendung Schemaaktualisierungen oder beschädigte Daten meldet, stoppen Sie und stellen Sie das Volume nach Klärung der Versionskompatibilität erneut aus dem unveränderten Artefakt wieder her.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Umschalten und einen Rollback-Host behalten

Starten Sie die Abhängigkeiten vor der Anwendung, überprüfen Sie Protokolle, Anmeldung, aktuelle Datensätze, Anhänge, geplante Aufgaben und einen verworfenen Schreibvorgang. Starten Sie den Ziel-Stack neu und bestätigen Sie, dass er dasselbe benannte Volume erneut einbindet. Aktualisieren Sie Proxy oder DNS erst, wenn diese Prüfungen erfolgreich sind.

Der zugehörige ZimaSpace-Artikel über konsistente Sicherungen von Containerdaten ist hilfreich, wenn das Ziel trotz erfolgreicher Kopie leer startet. Vergleichen Sie die Quelle der Laufzeit-Einbindung mit dem vorgesehenen Volume, bevor Sie die Daten erneut kopieren; wiederholte Kopien in das falsche Ziel erhöhen nur die Unklarheit.

Lassen Sie die Quellanwendung gestoppt und das alte Volume schreibgeschützt, bis auf dem Ziel eine neue Sicherung und ein Wiederherstellungstest erfolgreich waren. Führen Sie einen Rollback durch, indem Sie den Datenverkehr nur dann an die unveränderte Quelle zurückleiten, wenn auf dem Ziel keine neuen Schreibvorgänge akzeptiert wurden; andernfalls stoppen Sie und führen Sie einen bewussten Datenabgleich durch.