Mit Dokumentation zum Datenverlust

Wie ihr sicher gemerkt habt, beschäftige ich mich im Rahmen eines Wochenend-Projekts mit „Kanboard im Container…“ im Speziellen und Linux-Containern im Allgemeinen. Die Einrichtung von „Backup und Restore im Kanboard-Container-Land“ liegt bereits hinter mir. Und das ist gut so, habe ich doch nun den ersten Datenverlust erlitten und musste meine Daten wiederherstellen.

Die etwas unglückliche Verkettung von Umständen, welche zum Datenverlust führten, möchte ich in diesem Artikel festhalten, so dass euch diese Erfahrung erspart bleiben kann.

Die Vorgeschichte

Da Container zustandslose Gebilde sind, nutze ich podman volumes, um die anfallenden Daten persistent zu speichern.

Als Einsteiger in die Thematik habe ich mich an der offiziellen Container-Dokumentation von Red Hat entlang gehangelt und bin den Anweisungen in Kapitel 3.4. Sharing files between two containers (die Dokumentation wurde überarbeitet; das Kapitel existiert so nicht mehr) gefolgt. Dort wird beschrieben, wie man den Volume-Pfad einer Variablen zuweist, welche später verwendet wird, um das Volume über den Pfad in den Container einzuhängen.

Da ich es nicht besser wusste, bin ich der Anleitung Schritt-für-Schritt gefolgt. Dies führte zu einer funktionierenden Konfiguration, in der meine Daten persistent gespeichert wurden.

Kommando ‚podman volume prune‘ und die Daten waren weg

Am Ende meiner Spielerei wollte ich das Spielfeld bereinigen. Dabei bin ich auf das Kommando podman volume prune gestoßen, welches laut podman-volume-prune(1) alle Volumens entfernt, die sich nicht in Verwendung befinden. Dies klang nach genau dem Befehl, nach dem ich gesucht habe.

TL;DR: Nach der Ausführung des Kommandos waren meine Volumes weg. Auch jene, die aktiv in laufenden Container-Instanzen eingehängt waren.

Die Analyse

Nach ein paar Tests und einer Internetrecherche stand die Ursache für das Verhalten fest. Diese ist im GitHub Issue #7862 dokumentiert und besagt, dass podman volume prune in Verwendung befindliche Volumes löscht, wenn diese über ihren Pfad und nicht über ihren Namen eingehängt wurden. Da ich wie oben beschrieben der Dokumentation von Red Hat strikt gefolgt bin, welche aber genau den Pfad und eben nicht den Namen verwendet, waren Ursache und Erklärung für den Datenverlust gefunden.

Die Folge

In Folge meiner Erfahrungen habe ich zwei Anfragen zur Produktverbesserung (englisch: Request For Enhancement oder kurz RFE) gestellt:

  1. Bug 1914096 – Needs improvement: Building, running, and managing containers: 3.4. Sharing files between two containers
  2. RFE: Let `podman volume prune` show the volumes that are going to be removed

Die erste Anfrage ist an Red Hat adressiert, mit der Bitte, in der Dokumentation den Volume-Namen an Stelle des in einer Variablen gespeicherten Volume-Pfades zu benutzen. Damit sollte verhindert werden, dass andere, die der Dokumentation folgen, die gleichen Erfahrungen wie ich machen müssen.

Als Ziel wird die Veröffentlichung von RHEL 8.4 anvisiert. Dieses Release sollte im Mai bzw. Juni 2021 erscheinen. Ich bin gespannt. Ich würde mich über eine frühere Aktualisierung der Dokumentation freuen. Update 2021-01-25: Bereits am 20. Januar wurde eine neue Version der Dokumentation veröffentlicht. In dieser war nur noch ein kleiner Tippfehler enthalten. Der Bug wurde mit dem heutigen Datum (25.01.2021) geschlossen. So ist sichergestellt, dass hier niemand mehr in die Falle tappt. Vielen Dank ans RHEL-Docs-Team im Allgemeinen und Gabriela im Speziellen.

Die zweite Anfrage richtet sich an das Upstream-Projekt. Sie beinhaltet den Vorschlag, podman volume prune (um eine Option) zu erweitern, so dass die Liste der zu löschenden Volumes angezeigt wird, bevor man die Entfernung bestätigt. Stand 17.01.2021 existiert bereits ein Pull-Request, welcher dieses Thema adressiert.

Meinen Artikel „Kanboard im Container…“ habe ich entsprechend angepasst, so dass auch dort die Volumen-Namen zum Einhängen verwendet werden und nicht die Volume-Pfade.

Alte Erkenntnis bestätigt

Dieses Beispiel zeigt wieder einmal sehr deutlich, wie wichtig eine funktionierende Datensicherung ist. Denn sie ist die zwingende Voraussetzung, um im Fehlerfall Daten auch wiederherstellen zu können. Daher kann ich nur jedem raten, ein entsprechendes Datensicherungs- und Wiederherstellungs-Konzept zu implementieren, bevor man Daten in eine Anwendung tut, die einem am Herzen liegen oder von denen die Zukunft des Unternehmens abhängt.

Zum Stöbern führe ich im Folgenden einige Artikel aus diesem Blog auf, welche sich mit dem Thema Backup befassen:

2 Gedanken zu „Mit Dokumentation zum Datenverlust

  1. ralfe

    Müsste das System nicht in der Lage sein anhand der Pfade auf den Namen zu schliessen? Wäre es dann nicht sinvoll eine Verbesserung vorzuschlagen, die in der Lage ist bei Verwendung von Pfaden auf den korrekten Namen zu schliessen? Oder gar in der Lage ist darauf hinzuweisen, dass die Arbeit mit pfaden zwar funktioniert, aber nachteile haben könnte. (beim Start des Pod)

    Antworten
    1. Jörg Kastning Beitragsautor

      Hi,

      zu Frage 1: Ja das hätte ich auch angenommen, dass dem so ist.

      zu Frage 2: Im GitHub Issue #7862 wird erwähnt, dass bei benannten Volumes deren Name zu verwenden sei und nicht der Pfad. Daher erschien mir eine Anfrage in dieser Richtung wenig Erfolg zu haben. Das macht die Verwendung der Pfade in der Dokumentation von Red Hat in meinen Augen um so schlimmer, weswegen ich hier um Änderung gebeten habe.

      zu Frage 3: Ich selbst halte die Verwendung des Pfades nicht für intuitiv. Warum gebe ich dem Kind einen Namen, wenn ich es anschließend über eine langen Pfad nutze? Wenn ich nicht durch die Dokumentation darauf gebracht worden wäre, hätte ich dieses Konstrukt vermutlich nie verwendet. Die Bitte einen eine entsprechende Warnung in die Dokumentation aufzunehmen ist ebenfalls Gegenstand meiner Meldung an Red Hat.

      Gruß,
      Jörg

      Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.