Contents — find the section you need
Change parameters and verify
Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.
Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.
The experiment controls are in English.
Explore storage boundaries in the browser
The panel models storage ownership and container connections. It does not run Docker or access your files. Choose a storage location and operation, then compare the stage diagram and evidence table. Local Docker commands below are optional follow-up work.
Each run starts from the same prepared fixture: /data/note.txt contains saved in the selected store, and /tmp/note.txt contains temporary in the container's writable layer. The image has no initial files at /data; application startup creates no files. The selected mount's read-only setting is applied after preparation. At the end, the model attempts to write a different file, /data/probe.txt. That marker never recreates the original note.
The named volume uses the default project-scoped name alpha_data. The external volume is pre-existing shared_data; the bind mount always uses the same absolute daemon-host path /srv/demo-data. Both fixed sources remain the same when changing projects. No custom volume name, anonymous volumes, tmpfs, driver options, image-to-volume population, permissions beyond the read-only mount, or other containers are modeled.
“Switch project” means alpha is taken down without deleting volumes, then beta is started. “Switch back” repeats that operation to return to alpha. A new empty beta_data can hide access to the original note without deleting alpha_data. The diagram distinguishes retained data from a readable connection. The read-only control applies only to mounts and has no effect in the writable-layer case.
Try these comparisons: restart versus recreate for the writable layer; ordinary down versus down --volumes for a managed named volume; project switching versus switching back; and managed versus external volumes during cleanup. Each removal scenario includes starting the service again. Metrics are binary outcomes (1 = yes, 0 = no), not probabilities, timings, or recovery guarantees.
Rules were checked against Docker storage, volume lifecycle, bind mounts, Compose down and Compose volume names/external volumes on 2026-09-20. This is a documentation-based state model, not a live Engine conformance test. It models neither host failure nor application/database consistency. Continue to the restore Lab to examine separate recovery checks.
Das Neuerstellen eines Containers stellt dessen Daten nicht automatisch wieder her. Ermitteln Sie die Speichergrenzen und was genau durch einen Vorgang entfernt wird. Diese Übung basiert auf der Dokumentation und wurde am 07.09.2026 geprüft. Für die Tests wurden keine Produktionscontainer oder -volumes verwendet.
Drei Speicherorte
| Ort | Besitzgrenze | Nach dem Entfernen des Containers |
|---|---|---|
| Schreibbare Ebene | Einzelner Container | Änderungen in dieser Ebene gehen verloren |
| Benanntes Volume | Unabhängiger, von Docker verwalteter Speicher | Bleibt erhalten, solange das Volume nicht entfernt wird |
| Bind-Mount | Angegebener Docker-Host-Pfad | Bleibt als Host-Dateien erhalten |
Das Stoppen/Neustarten unterscheidet sich vom Entfernen/Neuerstellen. Die Volume-Dokumentation erläutert den Lebenszyklus. Anonyme Volumes haben andere Bereinigungsregeln, einschließlich des Verhaltens mit --rm. Diese Übung verwendet ein benanntes Volume.
Übung: Erstellen eines temporären benannten Volumes
Das Beispiel setzt Docker Engine, Linux-Container und alpine:3.21 voraus. Notieren Sie die Docker-Version und den Digest des heruntergeladenen Images; Tags können sich ändern. Prüfen Sie mit docker volume ls, ob duskcoil-lifetime-demo ungenutzt ist, bevor Sie fortfahren:
docker volume create duskcoil-lifetime-demo
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data alpine:3.21 sh -c 'echo saved > /data/note.txt; echo temporary > /tmp/note.txt'
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data,readonly alpine:3.21 sh -c 'cat /data/note.txt; test ! -e /tmp/note.txt'
Erwartet: Der zweite Container liest die Daten aus /data/note.txt, während sein /tmp/note.txt fehlt. Das Entfernen des ersten Containers lässt das benannte Volume intakt. Die zweite Einbindung ist schreibgeschützt. Verwenden Sie in dieser Übung keine produktiven Servicenamen oder Daten.
Welchen Host verwendet eine Bind-Mount-Einbindung?
Bind-Mounts beziehen sich auf Pfade auf dem Host des Docker-Daemons. Ein Remote-Daemon kann möglicherweise nicht auf die Dateien Ihres lokalen PCs zugreifen. Docker Desktop führt ebenfalls eine VM-Grenze ein.
Prüfen Sie die Mounts in docker inspect <container> auf Typ, Quelle, Ziel und Lese-/Schreibzugriff. Beheben Sie einen fehlerhaften Mount in /data, bevor Sie Anwendungseinstellungen ändern. Ein Mount kann darunterliegende Dateien verdecken; unterscheiden Sie fehlende Daten von Daten, die durch ein anderes gemountetes Verzeichnis verdeckt werden.
Lesen Sie die Semantik der Compose-Bereinigung
docker compose down unterscheidet sich von docker compose down --volumes. Letzteres betrifft auch benannte Volumes, die in Compose deklariert wurden; externe Volumes werden separat verwaltet. Siehe down reference.
Das Ändern eines Compose-Projektnamens kann dazu führen, dass ein neu benanntes Volume ausgewählt wird und die Anwendung leer erscheint. Überprüfen Sie die tatsächlichen Namen, bevor Sie von einer Beschädigung ausgehen. Entfernen Sie das Test-Volume nur anhand seines spezifischen Namens, nachdem Sie bestätigt haben, dass es nicht mehr benötigt wird; eine allgemeine Volume-Bereinigung ist nicht Teil dieses Vorgangs.
Persistenz ist kein Backup
Ein Volume trennt Daten vom Lebenszyklus des Containers, schützt aber nicht unbedingt vor Festplattenausfall oder dem Löschen der Anwendung. Bewahren Sie eine separate Kopie auf und testen Sie die Wiederherstellung. Das Kopieren von Live-Datenbankdateien kann zu Inkonsistenzen führen: Verwenden Sie die von der Anwendung unterstützten Backup-Verfahren oder geeignete Shutdown-/Snapshot-Bedingungen.
Images und Compose-Dateien allein können Benutzer-Uploads und Datenbanken auslassen. Eine Datenbank allein kann erforderliche Konfigurationen, Schlüssel oder kompatible Versionen auslassen. Stellen Sie sicher, dass die wiederhergestellte Anwendung ihre Daten tatsächlich lesen kann.
Erstellen Sie ein Speicherinventar
Erfassen Sie für jeden Dienst den Pfad im Container, die tatsächliche Einbindung, die Eigentümer/Berechtigungen, die Backup-Methode, das Wiederherstellungsziel und das Datum des letzten Wiederherstellungstests. Fahren Sie dann mit der Übung zur Wiederherstellung des Home-Servers fort, um zu überprüfen, ob alle wichtigen Daten abgedeckt sind.
Kommentare
Bitte zuerst anmelden.
Noch keine Einträge.