Persistente Volumes und Snapshots auf Dockup

Persistente Volumes und Snapshots lösen zwei unterschiedliche Probleme. Ein Volume hält Dateien über den Austausch von Containern und Deployments hinweg vor. Ein Snapshot erfasst den Zustand des Volumes zu einem bestimmten Zeitpunkt, damit Operatoren diesen Zustand später prüfen, aufbewahren oder wiederherstellen können.

Das Container-Dateisystem ist austauschbar. Alles, was ein Deployment überdauern muss – Uploads, generierte Medien, Indizes, Package-Artefakte oder von der Anwendung verwaltete Dateien – benötigt einen explizit festgelegten persistenten Speicherort.

Welche Anwendungsdaten gehören auf persistenten Speicher?

Verwende ein Volume, wenn die Anwendung Dateien besitzt, die sich nicht kostengünstig oder zuverlässig aus einer anderen Quelle rekonstruieren lassen.

Daten	Volume?	Bessere Alternative, falls verfügbar
Benutzer-Uploads	Ja	Object Storage, falls die Architektur dies verwendet
Generierte Thumbnails	Vielleicht	Aus den Originalen neu generieren
Suchindex	Vielleicht	Aus der Quelldatenbank neu erstellen
Build-Artefakte	Meistens nein	Während des Deployments neu erstellen
Anwendungslogs	Meistens nein	Runtime-Log-System
PostgreSQL-Datenverzeichnis	Nicht als App-Volume	Verwaltetes PostgreSQL
Temporärer Cache	Nein	Redis oder ephemerer Speicher
Lokale SQLite-Produktionsdatenbank	Riskant	Verwaltete Datenbank für gleichzeitige Zugriffe und Backups

Ein Volume sollte genau einen eindeutigen Besitzer und Mount-Pfad haben. Wenn zwei nicht zusammengehörige Prozesse in dasselbe Verzeichnis schreiben, werden Wiederherstellung und Analyse von Berechtigungen schwieriger.

Schätze vor dem Hinzufügen von Speicher die anfängliche Größe, die Wachstumsrate, die Aufbewahrungsanforderungen und das Recovery-Ziel. Speicherplatz wird pro Minute gegen das Guthaben des Plans abgerechnet. Ungenutzte Kapazität und unkontrolliertes Dateiwachstum verursachen daher Kosten.

Wie erstellt und prüft man ein Dockup-Volume?

Liste vorhandene Volumes für den exakten Service auf:

dockup volume list production/web --json

Füge ein Volume mit Namen, absolutem Container-Pfad und Größe in Gigabyte hinzu:

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

Die Anwendung muss nach /app/uploads schreiben. Das Schreiben nach /uploads oder in ein anderes lokales Verzeichnis leitet die Daten nicht automatisch in den Mount um.

Prüfe nach dem Deployment, ob die Anwendung in den angegebenen absoluten Mount-Pfad schreibt und nicht in das austauschbare Container-Dateisystem.

Prüfe die tatsächliche Speicherbelegung mit der zurückgegebenen Volume-ID:

dockup volume usage <volumeId> production/web --json

Vergleiche die tatsächliche Nutzung mit der zugewiesenen Größe und den Anwendungsmetriken. Richte Alarme ein, bevor das Dateisystem voll ist. Ein volles Volume kann zu unvollständigen Schreibvorgängen, fehlgeschlagenen Uploads oder Anwendungsabstürzen führen.

Prüfe die Erwartungen an den Dateibesitzer. Der Runtime-Benutzer des Containers muss den Mount-Pfad lesen und beschreiben können, ohne weitergehende Berechtigungen als erforderlich zu erhalten.

Wie schützen Volume-Snapshots Daten?

Ein Snapshot auf Abruf erfasst den Inhalt des Volumes:

dockup volume snapshot <volumeId> production/web --json

Liste verfügbare Snapshots auf:

dockup volume snapshots <volumeId> production/web --json

Snapshots lesen das Volume schreibgeschützt und erfordern nicht, dass die Anwendung in ein spezielles Snapshot-Verzeichnis schreibt. Sie sind vor einer riskanten Dateimigration, einer umfassenden Medienüberarbeitung oder einer Anwendungsänderung nützlich, die gespeicherte Daten umwandelt.

Ein Volume-Snapshot ist nicht automatisch anwendungskonsistent. Wenn die Anwendung gerade mehrere zusammengehörige Dateien schreibt, kann der Snapshot diese zu leicht unterschiedlichen Zeitpunkten erfassen. Verwende bei einer verwalteten Datenbank das Backup-System der verwalteten Datenbank, statt ihr unverändertes Datenverzeichnis zu snapshotten.

Lege fest, wann die Anwendung in einen ruhenden Zustand versetzt werden sollte. Vor einem wichtigen Snapshot kann eine kurze Wartungs- oder Schreibpause sinnvoll sein. Dokumentiere die Snapshot-ID, den Grund und den erwarteten Wiederherstellungspunkt.

Wie sollte die Aufbewahrung von Snapshots geplant werden?

Wähle Zeitpunkt und Aufbewahrungsdauer der Snapshots anhand der Recovery-Anforderungen und nicht aus Gewohnheit. Erstelle vor jeder riskanten Dateimigration, Bereinigung oder Formatänderung einen Snapshot auf Abruf und dokumentiere die zurückgegebene Snapshot-ID.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Recovery-Anforderung	Vorgehen bei Snapshots	Einschränkung
Dateimigration rückgängig machen	Direkt vor der Änderung einen Snapshot erstellen	Spätere Schreibvorgänge sind nicht enthalten
Historische Zeitpunkte bewahren	Nach einer Richtlinie gekennzeichnete Wiederherstellungspunkte aufbewahren	Die Aufbewahrung muss aktiv überprüft werden
Häufige Schreibvorgänge schützen	Ein für die Daten geeignetes anwendungsseitiges Backup ergänzen	Ein Snapshot zu einem bestimmten Zeitpunkt bietet keinen kontinuierlichen Schutz
Archivierung aus Compliance-Gründen	Einen dedizierten Archivierungs-Workflow verwenden	Operative Snapshots erfüllen möglicherweise nicht die Richtlinien

Prüfe, ob die erwarteten Snapshots tatsächlich vorhanden sind. Eine dokumentierte Aufbewahrungsrichtlinie ist kein Beleg dafür, dass ein verwendbarer Wiederherstellungspunkt erstellt wurde.

Wie stellt man einen Volume-Snapshot sicher wieder her?

Eine Wiederherstellung ersetzt den aktuellen Inhalt des Volumes und startet den Container neu:

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

Dies ist ein störender Vorgang, der den Zustand verändert. Vor der Wiederherstellung:

1. Bestätige den exakten Service sowie Volume- und Snapshot-ID.
2. Erläutere, welche aktuellen Dateien ersetzt werden.
3. Stoppe neue Schreibvorgänge oder begrenze sie, sofern möglich.
4. Erstelle einen aktuellen Snapshot des gegenwärtigen Zustands, falls dieser später benötigt werden könnte.
5. Dokumentiere die Kompatibilität von Anwendung und Schema.
6. Hole eine ausdrückliche Produktionsfreigabe ein.
7. Plane die Überprüfung nach der Wiederherstellung.

Prüfe nach der Wiederherstellung den Containerzustand und das Verhalten der Anwendung:

dockup status production/web --json
dockup logs production/web --json

Teste repräsentative Dateien, Berechtigungen, Indizes und Anwendungsreferenzen. Ein erfolgreicher Wiederherstellungsbefehl bestätigt, dass der Snapshot angewendet wurde. Er bestätigt jedoch nicht, dass jeder Anwendungsdatensatz auf eine gültige Datei verweist.

Das Modell der Produktionsleitplanken für AI-Agenten sollte eine Wiederherstellung auch dann als genehmigungspflichtig behandeln, wenn es sich um einen Recovery-Vorgang handelt.

Wie sollten sich Volumes bei Deployment und Rollback verhalten?

Bei einem Deployment werden die Anwendungscontainer ersetzt, während das gemountete Volume bestehen bleibt. Dadurch kann ein neues Image vorhandene Dateien sehen. Gleichzeitig entsteht eine Kompatibilitätsverpflichtung.

Eine neue Anwendungsversion sollte gespeicherte Dateien nicht irreversibel umwandeln, bevor ihre Veröffentlichung bestätigt ist. Wenn sie Dateiformate oder Verzeichnisstrukturen ändert, sollte die Migration nach Möglichkeit fortsetzbar und abwärtskompatibel sein.

Ein Application-Rollback führt ein älteres Deployment erneut aus:

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

Das Volume wird durch das Image nicht automatisch zurückgesetzt. Eine ältere Anwendung kann möglicherweise keine Dateien lesen, die von der neuen Version umgewandelt wurden. Koordiniere ein Image-Rollback nur dann mit der Wiederherstellung eines Snapshots, wenn beides erforderlich und genehmigt ist.

Diese Trennung ist wichtig:

Recovery-Aktion	Ändert das Image?	Ändert die Volume-Daten?
Neue Version deployen	Ja	Nein, außer die Anwendung migriert sie
Deployment zurücksetzen	Ja	Nein
Snapshot wiederherstellen	Nein	Ja
Wiederherstellen plus Rollback	Ja	Ja

Der Prozess für Deployments ohne Downtime schützt den Wechsel des Datenverkehrs, nicht die Kompatibilität von Datenformaten.

Was gehört in ein Runbook für den Betrieb dauerhaften Speichers?

Weise jedem Produktions-Volume einen Besitzer zu. Das Runbook sollte Folgendes enthalten:

• Service-Ziel und Volume-ID.
• Mount-Pfad und erwarteter Runtime-Benutzer.
• Zugewiesene Größe und Alarmschwelle.
• Beschreibung der Daten und Möglichkeit zur Rekonstruktion.
• Snapshot-Zeitplan und Aufbewahrung.
• Zuletzt verifizierter Snapshot.
• Richtlinie für die Genehmigung von Wiederherstellungen.
• Schritte zur Anwendungsvalidierung.
• Hinweise zur Kompatibilität von Image und Daten.
• Richtlinie für Wachstum und Löschung.

Prüfe die Auslastung regelmäßig:

dockup volume usage <volumeId> production/web --json

CPU, RAM und Speicherplatz werden pro Minute gemessen. Der Free-Plan bietet ein Startguthaben von 10 $, während der empfohlene Pro-Plan 20 $ pro Monat kostet und ein Nutzungsguthaben von 20 $ enthält.

Übung zur Snapshot-Wiederherstellung

Warte nicht auf einen Vorfall, um festzustellen, dass niemand weiß, welchen Snapshot er auswählen soll. Führe eine kontrollierte Übung mit einem nicht produktiven Service oder einer genehmigten Kopie durch:

1. Erstelle eindeutig erkennbare Testdateien.
2. Erstelle einen Snapshot.
3. Ändere die Dateien.
4. Stelle den Snapshot wieder her.
5. Prüfe Inhalt und Berechtigungen.
6. Beobachte den Neustart des Containers.
7. Dokumentiere Dauer und Fehlerstellen.

Eine Wiederherstellungsübung macht persistente Volumes und Snapshots von einem Kontrollkästchen zu einer getesteten Recovery-Fähigkeit.

Informationen zum initialen Servicedesign findest du unter Vom Git-Repository zur Produktion. Details zu den Befehlen findest du in der Dockup-CLI-Referenz.

Recovery-Ziele für Dateidaten definieren

Das Recovery Point Objective beantwortet die Frage, wie viele aktuelle Daten das Unternehmen verlieren kann. Das Recovery Time Objective gibt an, wie lange eine Wiederherstellung dauern darf. Ein täglicher Snapshot mit einer Aufbewahrung von sieben Kopien kann für einen internen Medien-Cache ausreichen, nicht aber für ein Produkt mit Benutzer-Uploads, das nahezu Echtzeit-Datenbeständigkeit verspricht.

Dokumentiere beide Werte und teste die tatsächliche Wiederherstellungsdauer. Die Geschwindigkeit der Snapshot-Erstellung, die Datenmenge, der Neustart des Containers, die Dateivalidierung und die erneute Indizierung der Anwendung tragen allesamt zur Recovery-Zeit bei.

Dateilöschung und Wachstum kontrollieren

Persistenter Speicher kann volllaufen, weil die Anwendung temporäre oder ersetzte Dateien nie entfernt. Füge auf Anwendungsebene eine Aufbewahrungsrichtlinie hinzu und unterscheide zwischen logischer Löschung und sofortiger physischer Löschung. Ein kurzes Wiederherstellungsfenster kann es rechtfertigen, die endgültige Löschung zu verzögern.

Vor einer umfassenden Bereinigung:

1. Messe die aktuelle Volume-Nutzung.
2. Erstelle eine Liste der zu löschenden Dateien.
3. Erstelle einen Snapshot.
4. Führe die Bereinigung in begrenzten Batches aus.
5. Prüfe die Anwendungsreferenzen.
6. Bestätige, dass der erwartete Speicherplatz freigegeben wurde.

Dadurch erhalten persistente Volumes und Snapshots eine präventive Funktion und dienen nicht nur der Reaktion auf Vorfälle.

Snapshot-Bestand prüfen

Überprüfe regelmäßig Snapshot-IDs, Erstellungszeitpunkte, Aufbewahrung und den letzten erfolgreichen Wiederherstellungstest. Ein konfigurierter Job ohne aktuellen, nutzbaren Snapshot ist kein Recovery-System.

Berechtigungen für Wiederherstellungen festlegen

Lege fest, wer eine Wiederherstellung in der Produktion genehmigen darf und wer die Validierung danach durchführt. Die Trennung von Genehmigung und Ausführung verringert das Risiko, dass Dringlichkeit die Prüfung von Ziel und Snapshot umgeht.

Mit einem überprüfbaren Deployment beginnen

Erstelle ein nicht produktives Volume, fertige einen Snapshot an, ändere eine Testdatei und schließe eine Wiederherstellungsübung ab, bevor du unwiederbringliche Produktionsdaten speicherst.

Kostenlos auf app.dockup.ai starten. Der Free-Plan kostet 0 $ pro Monat, enthält ein Startguthaben von 10 $ und unterstützt einen Workspace, drei Datenbanken und drei Deployments.

FAQ

Bleibt ein Dockup-Volume bei einem Deployment erhalten?

Ja. Das Volume bleibt persistent, während die Service-Container ersetzt werden, sofern die Anwendung weiterhin den konfigurierten Mount-Pfad verwendet.

Ist ein Volume-Snapshot das richtige Backup für PostgreSQL?

Nein. Ein Snapshot eines laufenden Datenverzeichnisses ist möglicherweise nicht transaktionskonsistent. Verwende für verwaltete Datenbanken vorzugsweise das Backup-System der verwalteten Datenbank.

Was passiert bei der Wiederherstellung eines Volume-Snapshots?

Der aktuelle Inhalt des Volumes wird durch den ausgewählten Snapshot ersetzt und der Container neu gestartet. Daher sollte der Vorgang genehmigt und überprüft werden.

Kann Dockup Volume-Snapshots planen?

Ja. Der Befehl für den Volume-Zeitplan unterstützt tägliche Snapshots mit einer Aufbewahrungsanzahl. Der Zeitplan kann ausdrücklich deaktiviert werden.

Wird beim Zurücksetzen einer Anwendung auch ihr Volume zurückgesetzt?

Nein. Der Verlauf der Anwendungsdeployments und der Verlauf der Volume-Snapshots sind getrennt. Koordiniere beides nur, wenn der Recovery-Plan dies erfordert.