Können Sie einen einzelnen Container wiederherstellen, ohne den gesamten App-Stack zu ersetzen?
Ja, ein einzelner Container kann unabhängig wiederhergestellt werden, wenn seine Konfiguration, persistenten Daten und Abhängigkeiten klar vom restlichen Stack getrennt sind.
Auf einem Heim-NAS ist der sichtbare Container normalerweise ersetzbar, aber sein Anwendungsstatus kann sich über Bind-Mounts, benannte Volumes, eine separate Datenbank, Geheimnisse, Proxy-Routen und gemeinsam genutzte Netzwerke erstrecken. Eine sichere Wiederherstellung eines einzelnen Dienstes bedeutet daher nicht, einfach eine Container-ID zurückzukopieren. Stattdessen wird der betroffene Dienst eingefroren, nur sein eigener Status wiederhergestellt, aus einer bekannten Definition neu erstellt und anschließend überprüft, dass gemeinsame Abhängigkeiten und gesunde benachbarte Container unverändert bleiben.
Die Wiederherstellungseinheit vor dem Anhalten definieren
Identifizieren Sie den genau betroffenen Dienst und listen Sie jedes Objekt auf, das ihm gehört: Compose-Dienstname, Image-Tag oder -Digest, Umgebungsdatei, Geheimnisse, Bind-Mounts, benannte Volumes, veröffentlichte Ports, Netzwerkaliase, geplante Aufgaben und Reverse-Proxy-Labels.
Leitfäden zur Wiederherstellung von Docker-Volumes trennen die Container-Laufzeit vom persistenten Speicher, weil das Daten-Volume unabhängig gesichert und wiederhergestellt werden kann. Eine praxisnahe Anleitung zeigt eine getrennte Wiederherstellung von Container und Volume, anstatt den laufenden Container als einziges Wiederherstellungsobjekt zu betrachten.
Wenn die Anwendung in eine gemeinsam genutzte Datenbank oder ein gemeinsam genutztes Volume schreibt, umfasst die Wiederherstellungseinheit auch diese gemeinsame Abhängigkeit und lässt sich möglicherweise nicht mehr sicher isolieren. Halten Sie inne, bevor Sie etwas überschreiben, bis die Zuständigkeit eindeutig geklärt ist.
Den gesunden Stack und den Status des ausgefallenen Dienstes erfassen
Exportieren oder speichern Sie die aktuelle Compose-Datei, die aufgelöste Umgebung, Image-Digests, die Mount-Liste, die Netzwerkmitgliedschaft, den Gesundheitsstatus und die aktuellen Logs. Notieren Sie, welche benachbarten Dienste gesund sind, damit die Wiederherstellung eine klare Grenze ohne Auswirkungen hat.
Ein Compose-Vorgang auf Dienstebene kann gezielt einen benannten Dienst ansprechen, anstatt alles neu zu starten. Der Einzelservice-Workflow von Linux Handbook unterscheidet einen einzelnen Compose-Dienst von stackweiten Aktionen, weist jedoch auch darauf hin, dass Konfigurationsänderungen eine Neuerstellung und keinen einfachen Neustart erfordern.
Deaktivieren Sie automatische Updates und Neustartschleifen nur für den ausgefallenen Dienst. Lassen Sie Datenbanken und gemeinsam genutzte Infrastruktur weiterlaufen, sofern ihre Konsistenz keinen koordinierten Stopp erfordert.
Daten zunächst an einem isolierten Ort wiederherstellen
Stellen Sie die ausgewählte Sicherung in einem temporären Verzeichnis oder einem neuen Volume wieder her, anstatt sie direkt über den aktiven Pfad zu schreiben. Vergleichen Sie Dateianzahl, Eigentümer, Zeitstempel, Metadaten des Datenbank-Dumps und Anwendungsversion mit dem beschädigten Status.
Ein Projekt zur Volume-Sicherung dokumentiert die Verwendung eines temporären einmaligen Containers zum Einbinden und erneuten Befüllen eines Ziel-Volumes. Dadurch entsteht ein isolierter Pfad zur Volume-Wiederherstellung, bevor der Produktionsdienst darauf schreibt.
Verwenden Sie bei Datenbanken nach Möglichkeit einen anwendungsspezifischen Dump oder eine entsprechende Wiederherstellungsmethode. Eine Dateisystemkopie einer laufenden Datenbank ist bestenfalls absturzkonsistent und kann fehlschlagen, nachdem der alte Container entfernt wurde.
Überprüfen Sie die isolierte Kopie, bevor Sie die Mounts umstellen. Wenn die Sicherung nicht gelesen werden kann oder ihr Schema nicht zum vorgesehenen Image passt, bewahren Sie den aktuellen Status und wählen Sie einen anderen Wiederherstellungspunkt.
Nur den ausgefallenen Dienst mit seiner ursprünglichen Identität neu erstellen
Erstellen Sie den benannten Dienst anhand der gespeicherten Compose-Definition neu. Behalten Sie dabei denselben Projektnamen, externe Netzwerke, Dienstaliase, Ports, Geheimnisse, die UID/GID-Zuordnung und die überprüften persistenten Pfade bei.
Der Zugriff auf Mounts kann auch nach einer korrekten Datenwiederherstellung fehlschlagen, wenn Eigentümer oder Sicherheitslabels nicht mehr zum Laufzeitbenutzer passen. In einem Container-Fall unter Rocky Linux wurde der fehlende Volume-Zugriff behoben, indem Eigentümer und Sicherheitskontext überprüft wurden, anstatt die Daten erneut zu kopieren.
Starten Sie den Dienst, ohne Volumes zu löschen oder stackweite Bereinigungsbefehle auszuführen. Prüfen Sie die tatsächlich verwendeten Mounts, bevor Sie Migrationen, Scans oder Hintergrundaufgaben die wiederhergestellten Daten verändern lassen.
Abhängigkeiten wieder verbinden, ohne sie wiederherzustellen
Testen Sie aus dem wiederhergestellten Container die DNS-Auflösung und den TCP-Zugriff auf seine Datenbank, seinen Cache, den Identitätsanbieter, den Objektspeicher und das Proxy-Netzwerk. Verwenden Sie dieselben Dienstnamen und Zugangsdaten, die in der wiederhergestellten Konfiguration definiert sind.
Wenn eine gemeinsam genutzte Abhängigkeit gesund geblieben ist, stellen Sie sie nicht wieder her und ersetzen Sie sie nicht, nur weil die Anwendung keine Verbindung herstellen kann. Ein fehlender Netzwerkalias, ein erneuertes Geheimnis, ein nicht passendes Schema oder ein falscher Datenbankname kann eine funktionierende Abhängigkeit als nicht verfügbar erscheinen lassen.
Führen Sie Migrationen nur aus, wenn die wiederhergestellte Anwendungsversion und die Datenbanksicherung dies erfordern. Sichern Sie die Abhängigkeit vor jeder nicht rückgängig zu machenden Migration und brechen Sie ab, wenn die Anwendung versucht, eine leere Datenbank zu initialisieren.
Die Grenze des einzelnen Dienstes prüfen, bevor der Datenverkehr zurückkehrt
Testen Sie Anmeldung, Lese- und Schreibvorgänge, Uploads, geplante Aufgaben, API-Aufrufe, Proxy-Zugriff und einen kontrollierten Neustart. Vergleichen Sie die Neustartzähler, Logs, Ports und Datenprüfsummen der benachbarten Container mit der Erfassung vor der Wiederherstellung.
Der ZimaSpace-Leitfaden zum Zuordnen des persistenten Containerstatus vermittelt dasselbe Wiederherstellungsprinzip: Stellen Sie den Besitzer des Status wieder her, nicht eine angenommene Containerhülle.
Die Wiederherstellung ist erst abgeschlossen, wenn der wiederhergestellte Dienst die vorgesehenen Daten und Abhängigkeiten verwendet, gesunde Mitglieder des Stacks unberührt geblieben sind und eine erneute Erstellung zum selben Ergebnis führt. Wenn der gemeinsame Status nicht isoliert werden kann, eskalieren Sie zu einer koordinierten Wiederherstellung des gesamten Stacks, anstatt einen Teil-Rollback zu erzwingen.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Kann Plex eine GPU mit einem anderen Docker-Container gemeinsam nutzen?
Plex und ein weiterer Container können häufig auf dieselbe GPU zugreifen, aber du musst die Treiberunterstützung, die Gerätezuordnung, die Auslastung der Video-Engine, den Speicher...
So erkennst du, ob ein Plex-Fehler vom Client oder vom Server verursacht wird
Reproduziere dasselbe Element auf einem anderen Client, vergleiche den Sitzungspfad und sammle Serverbelege erst, nachdem der Geltungsbereich dir gezeigt hat, wo der Fehler tatsächlich...
So konfigurierst du den Plex-Cache und den temporären Transcodierungs-Speicher
Schütze den persistenten Plex-Zustand, indem du temporäre Transcodierungsdateien auf geeignetem lokalem Speicher ablegst, und überprüfe anschließend die Bereinigung, den freien Speicherplatz und das Verhalten...
