Zurück zum Blog Self-hosting

Bleiben Ihre App-Daten nach einem Container-Neuaufbau erhalten? Eine Docker-Checkliste

Ein gestoppter Container und ein ersetzter Container sind nicht derselbe Test. Ermitteln Sie, wo Ihre Anwendung Daten und Konfiguration speichert, prüfen Sie die Bereitstellungsanleitung und testen Sie die Datenpersistenz mit einem kontrollierten Austausch.

Checkliste zum Nachverfolgen von Anwendungsdaten und Testen der Datenpersistenz beim Austausch eines Docker-Containers

Warum der Austausch eines Containers wichtig ist

Ein Container kann gestoppt und wieder gestartet oder im Rahmen einer Bereitstellungsänderung entfernt und ersetzt werden. Das sind unterschiedliche Ereignisse im Lebenszyklus. Ein erfolgreicher Neustart beweist daher nicht, dass wichtige Anwendungsdaten einen Austausch überstehen. In der Einführungsdokumentation von Docker wird Datenpersistenz als eigenes Konzept behandelt ([Docker-Dokumentation](https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-container-data/)).

Die beschreibbare Ebene eines gestoppten Containers bleibt verfügbar, bis der Container entfernt wird. Wird derselbe Container wieder gestartet, ist sie wieder da ([Dash0, „So bleiben Daten erhalten, wenn ein Docker-Container beendet wird“](https://www.dash0.com/faq/how-to-preserve-data-when-a-docker-container-exits)). Daraus lässt sich jedoch nicht ableiten, was beim Entfernen und Ersetzen mit den Daten geschieht. Testen Sie das Lebenszyklusereignis, das für Sie tatsächlich relevant ist.

  • Benennen Sie die Änderung, die Sie testen möchten: Neustart, Aktualisierung, Entfernen und Neuerstellen oder eine andere vom Anbieter verwaltete Maßnahme.
  • Verwenden Sie für einen ersten Test eine Nicht-Produktionsumgebung oder Daten, deren Verlust unproblematisch wäre.
  • Wenn Sie nicht feststellen können, ob bei einer Änderung derselbe Container weiterverwendet oder ein neuer erstellt wird, fragen Sie die Person, die die Bereitstellung verwaltet.
Warum der Austausch eines Containers wichtig ist

Speicherorte für Daten, Konfiguration und Speicher erfassen

Erstellen Sie ein kurzes Verzeichnis der Daten, die die Anwendung erstellt oder benötigt, etwa Datenbankdaten, Benutzer-Uploads, Konfiguration, generierte Dateien oder Protokolle. Dies sind Kategorien, die Sie untersuchen sollten; es bedeutet nicht, dass jede Anwendung diese Daten auf dieselbe Weise speichert.

Notieren Sie für jeden Eintrag, wo er laut Anwendungs- oder Bereitstellungsdokumentation gespeichert wird: im Container, an einem konfigurierten Mount, in einem anderen Dienst oder in der Bereitstellungskonfiguration. Kennzeichnen Sie alles, was Sie nicht überprüfen können, als unbekannt. Anwendungsspezifische Pfade und das Verhalten bei der Initialisierung müssen in der Bereitstellungsdokumentation der jeweiligen Anwendung geprüft werden.

Halten Sie für jeden konfigurierten Mount den Typ, Quelle und Ziel entsprechend der Bereitstellung, den vorgesehenen Zweck sowie das dokumentierte Verhalten beim geplanten Austauschverfahren fest. Allein aus dem Namen eines Mounts lässt sich weder ableiten, was er enthält, noch ob das Verfahren ihn beibehält.

  • Daten oder Einstellung: Was ist es, und welche Folgen hätte ein Verlust?
  • Speicherort und Beleg: Wo ist der Speicherort laut Anwendung oder Bereitstellung, und welche Anleitung oder Einstellung belegt das?
  • Lebenszyklus: Was soll mit diesem Speicherort während der geplanten Teständerung geschehen?
  • Unbekanntes: Was muss vor einer Änderung in der Produktionsumgebung geklärt werden?
Speicherorte für Daten, Konfiguration und Speicher erfassen

Prüfen Sie vor dem Test die Bereitstellungsanleitung

Prüfen Sie in der offiziellen Bereitstellungsdokumentation des Anwendungsanbieters, welche Datenpfade und Konfigurationseingaben erforderlich sind und welches Verhalten beim ersten Start oder bei der Initialisierung vorgesehen ist. Vergleichen Sie diese Vorgaben mit der tatsächlichen Bereitstellungsdefinition. Übernehmen Sie keinen Pfad aus einer anderen Installation und gehen Sie nicht davon aus, dass ein neuer Container vorhandene Daten wie vorgesehen behandelt.

Ist ein erforderlicher Pfad nicht konfiguriert, ein Initialisierungsschritt unklar oder weicht die Bereitstellung von der Anleitung ab, halten Sie inne und bitten Sie um Klärung, bevor Sie wichtige Daten für einen Test verwenden. Halten Sie fest, welche Dokumentation und Einstellungen Sie geprüft haben, damit Ihre Erwartungen sich auf die tatsächlich verwendete Bereitstellung beziehen.

  • Welche dokumentierten Pfade enthalten Zustands- oder Benutzerdaten, und ist dafür in der Bereitstellung Speicher definiert?
  • Was sagt die Anwendungsdokumentation über das Verhalten beim ersten Start oder über einen Pfad aus, der bereits Daten enthält?
  • Wie wird die Konfiguration laut Dokumentation in dieser Einrichtung bereitgestellt?
  • Welche Einstellungen oder Details zum Lebenszyklus sind noch nicht überprüft?

Einen kontrollierten Persistenztest durchführen

Testen Sie genau das Lebenszyklusereignis, das Sie untersuchen möchten, und verwenden Sie dafür Daten, deren Verlust unproblematisch wäre. Bevorzugen Sie eine Nicht-Produktionsumgebung. Ist ein Test mit einem aktiven Dienst erforderlich, holen Sie die Genehmigung ein und verwenden Sie ein risikoarmes Element, das Sie eindeutig erkennen und anschließend wieder entfernen können.

Erstellen Sie über die Anwendung ein eindeutig benanntes Testelement und notieren Sie, woran Sie es erkennen. Folgen Sie dem dokumentierten Austauschverfahren – führen Sie nicht bloß einen Stopp und Neustart durch, wenn es Ihnen um Entfernen und Neuerstellen geht. Prüfen Sie anschließend, ob das Element vorhanden und nutzbar ist, und kontrollieren Sie gesondert alle anderen erfassten Daten, die wichtig sind.

Dokumentieren Sie das Ergebnis und alle geänderten Annahmen. Ein erfolgreicher Test gilt für diese Bereitstellung und dieses Verfahren. Er belegt nicht, wie sich jede Datenkategorie oder ein anderes Wiederherstellungsszenario verhält.

  • Vorher: Notieren Sie die Anwendung, die Bereitstellung, das Testelement und die geplante Lebenszyklusmaßnahme.
  • Nachher: Prüfen Sie das Testelement und alle weiteren wichtigen Datenkategorien.
  • Dokumentieren: Halten Sie Verfahren, Ergebnis, fehlende oder geänderte Daten und offene Fragen fest.
  • Aufräumen: Entfernen Sie das Testelement gegebenenfalls und bestätigen Sie, dass die Anwendung wieder im vorgesehenen Zustand ist.

Datenpersistenz, Backups und Zuständigkeiten auseinanderhalten

Datenpersistenz und Backups beantworten unterschiedliche Fragen. Dass ein Speicherort ein bestimmtes Austauschverfahren übersteht, sagt nicht aus, ob sich Daten nach einem Verlust oder Fehler wiederherstellen lassen. Dokumentieren Sie getrennt, welche Daten gesichert werden müssen, was ein Backup umfasst, wie die Wiederherstellung funktioniert und wer für die einzelnen Schritte zuständig ist.

Klären Sie außerdem, wer auf die Anwendung, ihre Speicherkonfiguration und etwaige Wiederherstellungsmechanismen zugreifen kann. Gehen Sie nicht davon aus, dass sich aus dem Hosting-Modell ergibt, welche Daten abgedeckt sind, wie lange sie aufbewahrt werden oder wer sie wiederherstellen kann.

Airbip bietet konfigurierbare tägliche, wöchentliche und monatliche Backups. Aus den verfügbaren Produktinformationen geht nicht hervor, welche Anwendungsdaten die einzelnen Backups umfassen oder wie die Wiederherstellung abläuft. Klären Sie diese Details entsprechend Ihrem Bedarf.

  • Ermitteln Sie, welche Daten wiederherstellbar sein müssen und wer den Backup-Umfang bestätigt.
  • Fragen Sie, was Backups umfassen und ausschließen sowie wie eine Wiederherstellung beantragt und durchgeführt wird.
  • Klären Sie, wer auf die Anwendungsdaten und Bereitstellungseinstellungen zugreifen oder sie verwalten kann.
  • Trennen Sie Erwartungen an Backups und Wiederherstellung vom Ergebnis des Persistenztests.

Fragen an einen Managed-Hosting-Anbieter

Bitten Sie um Antworten, die sich auf die Bereitstellung Ihrer Anwendung und das konkrete Lebenszyklusereignis beziehen, das Sie interessiert, statt sich auf allgemeine Zusicherungen zu verlassen. Nutzen Sie die Antworten, um zu beurteilen, ob das Managed-Modell zu Ihren Anforderungen an Daten, Zugriff und Governance passt.

Airbip betreibt Anwendungsinstanzen als Docker-Workloads auf seinen Cloud-Servern und verwaltet den Lebenszyklus der Dienste. Das Routing und die TLS-Zertifikate werden über Traefik und Let’s Encrypt automatisiert. Außerdem bietet Airbip konfigurierbare tägliche, wöchentliche und monatliche Backups. Diese Funktionen legen für sich genommen nicht fest, welche Anwendungspfade einen Austausch überstehen oder was ein Backup umfasst.

Kann ein Anbieter die benötigten Bereitstellungsdetails nicht klären oder erfüllt sein Dienst Ihre Governance-Anforderungen nicht, sollten Sie ein Bereitstellungsmodell prüfen, das Ihnen die erforderliche Kontrolle bietet.

  • Welche konkrete Maßnahme gilt bei meiner Instanz als Container-Austausch, und welche Daten- und Konfigurationsspeicherorte bleiben dabei erhalten?
  • Worauf stützt sich diese Auskunft, und wo kann ich die anwendungsspezifischen Speichereinstellungen einsehen?
  • Was umfassen Backups, wie funktioniert die Wiederherstellung und wer ist für die einzelnen Schritte zuständig?
  • Welche Zugriffskontrollen gelten, und welche Änderungen oder Maßnahmen liegen weiterhin in meiner Verantwortung?

Häufige Fragen

Verschwinden Daten in einem gestoppten Docker-Container sofort?

Nein. Die beschreibbare Ebene eines gestoppten Containers bleibt verfügbar, bis der Container entfernt wird. Wird derselbe Container wieder gestartet, ist sie wieder da. Daraus lässt sich nicht ableiten, was beim Entfernen und Ersetzen des Containers geschieht.

Ist ein Neustart des Containers ein geeigneter Persistenztest?

Damit wird der Neustart desselben Containers getestet, nicht unbedingt dessen Entfernen und Ersetzen. Wenn Sie den Austausch untersuchen möchten, folgen Sie dem dokumentierten Austauschverfahren in einer sicheren Umgebung.

Sind benannte Volumes und Bind-Mounts für meine Anwendungsdaten automatisch sicher?

Gehen Sie nicht davon aus. Prüfen Sie die Bereitstellungsanleitung der Anwendung und die tatsächlichen Bereitstellungseinstellungen, um festzustellen, welche Pfade eingebunden sind, was sie enthalten und was bei der geplanten Teständerung geschieht.

Was sollte ich einen Managed-Hosting-Anbieter zur Datenpersistenz fragen?

Fragen Sie, welche Daten- und Konfigurationsspeicherorte beim konkreten Austauschverfahren erhalten bleiben, was Backups umfassen, wie die Wiederherstellung abläuft und welche Zuständigkeiten bei Ihnen verbleiben.

Quellen und weiterführende Literatur

  1. Persisting container data — Docker
  2. How to Preserve Data When a Docker Container Exits — Dash0