Web-Archiv Teil 5: Wallabag-Backup und Versionsupdates

Wie bei jeder Software und Datenbank empfiehlt es sich natürlich, regelmässige Backups der Daten anzufertigen. Bei Docker-Containern kann man dies prinzipiell auf zwei Arten machen: Erstens, indem man einen Order des Host-Systems in den Container einbindet — alle geschriebenen Daten landen also quasi direkt im Host-Dateibaum und können von da mittels rsync oder anderweitig weg gesichert werden.
Zweitens, indem man die entsprechenden Daten regelmäßig aus dem Container heraus und in sein Filesystem kopiert. Welchen Weg man wählt, ist prinzipiell egal – das Wichtige ist, daran zu denken, überhaupt Backups zu machen. Ich habe mich hier für die 2. Variante entschieden, da inbesondere der Asset-Ordner, der Artikelbilder zwischenspeichert, sehr kleinteilig ist und Hunderte oder Tausende Dateien enthalten kann. Die möchte ich nicht alle dauernd offen in meinem System herum liegen haben.

Bei Wallabag gibt es tollerweise eigentlich nur zwei Sachen, die man sichern muss: Erstens die SQLite-Datenbank und zweitens der eben erwähnte Asset-Ordner mit den Artikelbildern. Sieht das eigene Datenbank-Setup anders aus, muss man diesen Teil natürlich anpassen.
Zur Sicherung der Wallabag-Daten habe ich folgendes Bash-Script geschrieben:

# Datenbank aus dem Container kopieren
docker cp wallabag:/var/www/wallabag/data/db/wallabag.sqlite /volume1/dein/backup/order/auf/dem/nas/
# ... und die Datei auf aktuelles Datum umbenennen
mv /volume1/dein/backup/order/auf/dem/nas/wallabag.sqlite /volume1/dein/backup/order/auf/dem/nas/"$(date +"%Y-%m-%d")"-wallabag-db-backup.sqlite
# Dann den kompletten Asset-Ordner raus kopieren
docker cp wallabag:/var/www/wallabag/web/assets/images /volume1/dein/backup/order/auf/dem/nas/images
# Diesen Order der Handlichkeit wegen zippen
7z a -r -tzip /volume1/dein/backup/order/auf/dem/nas/wallabag-images.zip /volume1/dein/backup/order/auf/dem/nas/images
# Die Ordnerkopie löschen
rm -rf /volume1/docker/wallabag/images
# Und das ZIP ebenfalls entsprechend umbenennen
mv /volume1/docker/wallabag/wallabag-images.zip /volume1/dein/backup/order/auf/dem/nas/wallabag/"$(date +"%Y-%m-%d")"-wallabag-images.zip
# Danach den Cache leeren und den Container neu starten
sudo docker exec -i -t wallabag php /var/www/wallabag/bin/console cache:clear -e=prod
docker restart wallabag

Dieses Script habe ich als wallaback.sh gespeichert und lasse es per Synology-Cron einmal wöchentlich nachts laufen.
Die Frequenz kann man natürlich auf die eigenen Bedürfnisse anpassen.
Sollte der Container crashen oder das NAS-Setup den Bach heruntergehen, kann man somit die Daten sehr schnell wieder zurück spielen. Dieses Verhalten sollte man unbedingt dann, wenn alles funktioniert, testen, denn jedes Backup, das man nicht erfolgreich wiederherstellen kann, ist nutzlos. Hierzu bietet sich gleich folgendes Szenario eines Versionsupdates an, das man auch durchspielen kann, wenn gar kein solches ansteht1:

Versionsupdates für Software, die in einem Docker-Container läuft, sind immer so eine Sache, aber glücklicherweise gestaltet sich die Wallabag-Aktualisierung einfach. Das hier beschriebene Vorgehen hat bei mir von Version 4.3.5 auf 4.3.7 einwandfrei und ohne Datenverlust funktioniert.

Zunächst fertigt man ein frisches Backup wie oben beschrieben an.
Danach stoppt man den Container. Wallabag ist nun erst einmal still gelegt. Dann läd man sich aus der Docker-Registry die neuste Version des Wallabag-Images, indem man nach Wallabag sucht und den latest Tag herunterlädt. Man sollte vorher die Versionsnummer im Docker-Hub überprüfen.

Ist das neue Image einsatzbereit, klickt man beim gestoppten Wallabag-Container auf „Action“ und „Clear“ und löscht somit alle Nutzdaten im Container. Anschließend wird der Container neu gestartet. Es wird die neueste Software-Version installiert, dies kann etwas dauern. Sieht man die gewohnte Login-Maske, hat alles geklappt und man kann sich dem Restore widmen.

Nun kopiert man die Datenbank wieder in den Container hinein:
docker cp /volume1/dein/backup/order/auf/dem/nas/wallabag/YYYY-MM-DD-wallabag-db-backup.sqlite wallabag:/var/www/wallabag/data/db/wallabag.sqlite

Die Assets muss man erst auf dem NAS entpacken und dann rein schieben, da im Container kein 7z zum Extrahieren bereit steht 2. Dies tut man am besten in ein normalerweise nicht genutztes Verzeichnis (bspw das root-Homeverzeichnis), da ansonsten unter Umständen versteckte Synology-Ordner mit angelegt werden:

root@NAS:~# 7z x /volume1/dein/backup/order/auf/dem/nas/wallabag/YYYY-MM-DD-wallabag-images.zip

Diese kopiert man dann an Ort und Stelle zurück:
docker cp images wallabag:/var/www/wallabag/web/assets/

Anschließend nicht vergessen, den Ordner vom NAS zu löschen:
rm -rf images/

Zum Schluss leeren wir nochmals den Cache und starten den Container neu:

docker exec -i -t wallabag php /var/www/wallabag/bin/console cache:clear -e=prod
docker restart wallabag

Hat man die Datenbank und die Assets im eigenen Dateisystem liegen und die Ordner entsprechend eingebunden, kann man sich dies sparen und muss nach einem Versionsupdate nichts weiter tun. Das beschriebene Vorgehen gilt für Updates, die keine Datenbank-Migration beinhalten. Für diesen Fall gibt es auf der Hilfe-Seite eine Anleitung.

Achtung: Nach dem Versionsupdate schlugen alle Versuche, irgendwelche Artikel von heise.de hinzuzufügen, fehl (egal ob hinter der Paywall oder nicht) – Fehlermeldung Entry reloaded but content fetching failed. Nach stundenlanger Suche und Herumprobieren bin ich dann auf die Lösung gekommen: Die Zugangsdaten müssen im Site credentials management nochmals neu eingetragen werden. Warum, kann ich nicht sagen, jedenfalls funktioniert es dann wieder.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

  1. Man installiert dann also wieder die gleiche Version, um den Restore-Prozess zu testen. Idealerweise macht man dies mit ein paar Test-Links bevor man alles importiert.
  2. Ja, kann man natürlich installieren, indem man sich als root in den Container hinein verbindet und es per apt-get install installiert. Aber ich bin faul und möchte die Container möglichst wenig verändern, weil alle diese Sachen bei einem weiteren Update wieder fällig werden.

Schreibe einen Kommentar

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