{"id":2728,"date":"2021-01-18T08:00:00","date_gmt":"2021-01-18T07:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=2728"},"modified":"2021-11-09T12:57:01","modified_gmt":"2021-11-09T10:57:01","slug":"mit-dokumentation-zum-datenverlust","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/mit-dokumentation-zum-datenverlust\/","title":{"rendered":"Mit Dokumentation zum Datenverlust"},"content":{"rendered":"\n

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

Die etwas ungl\u00fcckliche Verkettung von Umst\u00e4nden, welche zum Datenverlust f\u00fchrten, m\u00f6chte ich in diesem Artikel festhalten, so dass euch diese Erfahrung erspart bleiben kann.<\/p>\n\n\n\n

Die Vorgeschichte<\/h2>\n\n\n\n

Da Container zustandslose Gebilde sind, nutze ich podman volumes<\/em>, um die anfallenden Daten persistent zu speichern.<\/p>\n\n\n\n

Als Einsteiger in die Thematik habe ich mich an der offiziellen Container-Dokumentation von Red Hat<\/a> entlang gehangelt und bin den Anweisungen in Kapitel 3.4. Sharing files between two containers<\/s> (die Dokumentation wurde \u00fcberarbeitet; das Kapitel existiert so nicht mehr) gefolgt. Dort wird beschrieben, wie man den Volume-Pfad einer Variablen zuweist, welche sp\u00e4ter verwendet wird, um das Volume \u00fcber den Pfad in den Container einzuh\u00e4ngen.<\/p>\n\n\n\n

Da ich es nicht besser wusste, bin ich der Anleitung Schritt-f\u00fcr-Schritt gefolgt. Dies f\u00fchrte zu einer funktionierenden Konfiguration, in der meine Daten persistent gespeichert wurden.<\/p>\n\n\n\n

Kommando ‚podman volume prune‘ und die Daten waren weg<\/h2>\n\n\n\n

Am Ende meiner Spielerei wollte ich das Spielfeld bereinigen. Dabei bin ich auf das Kommando podman volume prune<\/code> gesto\u00dfen, welches laut podman-volume-prune(1) alle Volumens entfernt, die sich nicht<\/strong> in Verwendung befinden. Dies klang nach genau dem Befehl, nach dem ich gesucht habe.<\/p>\n\n\n\n

TL;DR:<\/strong> Nach der Ausf\u00fchrung des Kommandos waren meine Volumes weg. Auch jene, die aktiv in laufenden Container-Instanzen eingeh\u00e4ngt waren.<\/p>\n\n\n\n

Die Analyse<\/h2>\n\n\n\n

Nach ein paar Tests und einer Internetrecherche stand die Ursache f\u00fcr das Verhalten fest. Diese ist im GitHub Issue #7862<\/a> dokumentiert und besagt, dass podman volume prune<\/code> in Verwendung befindliche Volumes l\u00f6scht, wenn diese \u00fcber ihren Pfad und nicht \u00fcber ihren Namen eingeh\u00e4ngt 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\u00e4rung f\u00fcr den Datenverlust gefunden.<\/p>\n\n\n\n

Die Folge<\/h2>\n\n\n\n

In Folge meiner Erfahrungen habe ich zwei Anfragen zur Produktverbesserung (englisch: Request For Enhancement oder kurz RFE) gestellt:<\/p>\n\n\n\n

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

    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\u00fcssen.<\/p>\n\n\n\n

    Als Ziel wird die Ver\u00f6ffentlichung von RHEL 8.4 anvisiert. Dieses Release sollte im Mai bzw. Juni 2021 erscheinen. Ich bin gespannt. Ich w\u00fcrde mich \u00fcber eine fr\u00fchere Aktualisierung der Dokumentation freuen. Update 2021-01-25:<\/em> Bereits am 20. Januar wurde eine neue Version der Dokumentation ver\u00f6ffentlicht. 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.<\/p>\n\n\n\n

    Die zweite Anfrage richtet sich an das Upstream-Projekt. Sie beinhaltet den Vorschlag, podman volume prune<\/code> (um eine Option) zu erweitern, so dass die Liste der zu l\u00f6schenden Volumes angezeigt wird, bevor man die Entfernung best\u00e4tigt. Stand 17.01.2021 existiert bereits ein Pull-Request, welcher dieses Thema adressiert.<\/p>\n\n\n\n

    Meinen Artikel „Kanboard im Container\u2026<\/a>“ habe ich entsprechend angepasst, so dass auch dort die Volumen-Namen zum Einh\u00e4ngen verwendet werden und nicht die Volume-Pfade.<\/p>\n\n\n\n

    Alte Erkenntnis best\u00e4tigt<\/h2>\n\n\n\n

    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\u00f6nnen. 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\u00e4ngt.<\/p>\n\n\n\n

    Zum St\u00f6bern f\u00fchre ich im Folgenden einige Artikel aus diesem Blog auf, welche sich mit dem Thema Backup befassen:<\/p>\n\n\n\n