{"id":2705,"date":"2021-01-06T08:00:00","date_gmt":"2021-01-06T07:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=2705"},"modified":"2020-12-31T13:58:38","modified_gmt":"2020-12-31T12:58:38","slug":"backup-und-restore-im-kanboard-container-land","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/backup-und-restore-im-kanboard-container-land\/","title":{"rendered":"Backup und Restore im Kanboard-Container-Land"},"content":{"rendered":"\n

In „Kanboard im Container<\/a>“ habe ich einen Pod ins Leben gerufen, welcher die Anwendung Kanboard und eine dazugeh\u00f6rige Postgresql-Datenbank mittels Container bereitstellt. Backup und Restore zu konfigurieren und zu testen, habe ich letztes Wochenende nicht mehr geschafft. Dies hole ich in diesem Artikel nach.<\/p>\n\n\n\n

Da die Container selbst zustandslos sind, interessieren mich nur die persistent gespeicherten Daten, welche au\u00dferhalb der Container im Dateisystem des Hosts gespeichert werden.<\/p>\n\n\n\n

Umgebung<\/h2>\n\n\n\n

Auf einer virtuellen Maschine mit dem Gastbetriebssystem RHEL 8 l\u00e4uft ein podman<\/code>-Pod namens kanboardpod<\/em>. Dieser Pod beinhaltet neben dem Infrastruktur-Container, einen Kanboard-Container namens kanboard<\/em> und einen Postgresql-Container namens pgsql_db<\/em>.<\/p>\n\n\n\n

Die persistenten Daten des Kanboard-Containers werden in den Volumes kanboard_data<\/em> und kanboard_plugins<\/em> gespeichert. Die Datenbank-Dateien der Postgresql-DB liegen im Volume pgsql_data<\/em>.<\/p>\n\n\n\n

Die Namen des Pods und der Container sind hilfreich, da die Container dar\u00fcber referenziert werden k\u00f6nnen. So muss man nicht mit den sperrigen IDs hantieren.<\/p>\n\n\n\n

Backup<\/h2>\n\n\n\n

Kein Restore ohne Backup! Kein Backup, kein Mitleid!<\/strong><\/p>\n\n\n\n

Ich habe im Folgenden beschriebe Ans\u00e4tze f\u00fcr ein Backup. Wenn ihr noch weitere habt, freue ich mich \u00fcber eure Eingaben.<\/p>\n\n\n\n

Ansatz 1: Backup auf Dateiebene — verworfen<\/h3>\n\n\n\n

Dieser Ansatz liegt nahe und ist einfach umzusetzen.<\/p>\n\n\n\n

  1. Container stoppen<\/li>
  2. Verzeichnisse im Dateisystem sichern<\/li>
  3. Container wieder starten<\/li><\/ol>\n\n\n\n

    F\u00fcr meinen konkreten Anwendungsfall w\u00e4re dies auch ausreichend. Einen Dienst f\u00fcr die Dauer einer Datensicherung komplett stoppen zu m\u00fcssen, ist jedoch nicht ideal. Daher schaue ich nach weiteren M\u00f6glichkeiten.<\/p>\n\n\n\n

    Ansatz 2: DB-Dump und Datei-Backup — Praktikabel aber m\u00f6glicherweise inkonsistent.<\/h3>\n\n\n\n

    Bei diesem Ansatz bleibt die Anwendung w\u00e4hrend der Datensicherung verf\u00fcgbar. W\u00e4hrend das Volume kanboard_data<\/em> auf Dateiebene mittels tar<\/code> gesichert wird, wird die Datenbank mittels pg_dump<\/code> aus dem Container heraus gesichert. Das Backup-Skript sieht wie folgt aus:<\/p>\n\n\n\n

    #!\/bin\/bash\nkanboard_data=$(podman volume inspect kanboard_data --format {{.Mountpoint}})\nkanboard_plugins=$(podman volume inspect kanboard_plugins --format {{.Mountpoint}})\ntar czf kanboardfiles.tgz $kanboard_data $kanboard_plugins\npodman exec -t pgsql_db \/usr\/bin\/pg_dump kanboard | gzip > ~\/kanboard.sql.gz<\/code><\/pre>\n\n\n\n
    Hinweis:<\/strong> Obiger Code-Schnipsel stammt aus der Kategorie Schnell-und-Schmutzig und sollte nicht<\/strong> in produktiven Umgebungen verwendet werden.<\/p>\n\n\n\n
    Der DB-Dump wird dabei direkt aus dem Container in mein Home-Verzeichnis geschrieben. Am Ende habe ich zwei unabh\u00e4ngige Dateien, die nun au\u00dferhalb der Container-Umgebung liegen. Da diese jedoch immer noch auf dem gleichen Host liegen, handelt es sich um kein richtiges Backup. Doch ist es nun nicht mehr schwer, sie auf ein anderes, entferntes Medium zu \u00fcbertragen.<\/p>\n\n\n\n
    Der gr\u00f6\u00dfte Nachteil dieses Ansatzes besteht darin, dass die Konsistenz der Sicherung nicht garantiert ist. Die Datenbank enth\u00e4lt Referenzen in das Dateisystem. Referenzen in der Datenbank und Inhalt des gesicherten Dateisystems m\u00fcssen nicht in jedem Fall zueinander passen, da w\u00e4hrend der Sicherung weiter in der Anwendung gearbeitet werden kann.<\/p>\n\n\n\n
    Nun kann man nat\u00fcrlich vor der Sicherung den Container kanboard<\/em> stoppen und anschlie\u00dfend wieder starten. Damit erh\u00e4lt man eine konsistente Sicherung zu dem Preis, dass die Anwendung tempor\u00e4r nicht verf\u00fcgbar ist. Damit unterscheidet sich der Ansatz gegen\u00fcber Ansatz 1 nur noch darin, dass der Container pgsql_db<\/em> online bleibt und man die DB mit pg_dump<\/code> sichert, statt eine Sicherung auf Dateisystemebene zu machen.<\/p>\n\n\n\n
    Sch\u00f6n ist das nicht, doch mache ich es meiner Umgebung genau so.<\/p>\n\n\n\n
    Ansatz 3: Backup auf Basis eines konsistenten Dateisystem-Snapshots<\/h3>\n\n\n\n
    Dies ist in meinen Augen der vern\u00fcnftigste Ansatz.<\/p>\n\n\n\n
    Die persistenten Daten der Container liegen in einem Dateisystem. Unterst\u00fctzt dieses Dateisystem Snapshots<\/a>, k\u00f6nnen diese genutzt werden, um die Dateisysteminhalte zum Zeitpunkt des Snapshots auf das Backup-Medium zu \u00fcbertragen und den Snapshot anschlie\u00dfend wieder zu entfernen. Anwendung und Datenbank k\u00f6nnen bei diesem Verfahren w\u00e4hrend der Sicherung weiterlaufen.<\/p>\n\n\n\n
    Das so erstellte Datenbank-Backup befindet sich allerdings in einem Zustand, als w\u00e4re die Datenbank unsauber beendet worden. Nach einem Restore werden demnach die WAL-Logs ben\u00f6tigt (siehe PostgreSQL 9.6.20 Documentation: 25.2. File System Level Backup<\/a>).<\/p>\n\n\n\n
    Ich habe mich gegen diesen Ansatz entschieden, da mir in meiner Test-Umgebung noch die Erfahrung mit Dateisystem-Snapshots fehlt. Dies werde ich evtl. zu einem sp\u00e4teren Zeitpunkt unter die Lupe nehmen.<\/p>\n\n\n\n
    Restore<\/h2>\n\n\n\n
    Ich habe mich f\u00fcr den Ansatz 2 entschieden. Damit habe ich folgende zwei Dateien:<\/p>\n\n\n\n