Backups der Web-Dienste

Diese Seite beschreibt, was bei den Web-Diensten gesichert wird, wo die Grenzen der LV-weisen Sicherung liegen und wie eine Ad-hoc-Sicherung von Hand läuft, bevor an einem Dienst geschraubt wird.

Die Mechanik von Dirvish selbst — Bank, Vaults, Branches, Expire, Recovery — steht in BackupSystem. Hier steht nur, was dienstspezifisch ist. Siehe auch WebDienste.

Hosts

Host	Rolle
backer	Dirvish-Server. Alle dirvish-Aufrufe werden hier abgesetzt, als root.
laubfrosch	Web-Host. NGINX, Docker-Container der Web-Dienste, Webroots unter /var/www/.
janus	Datenbank-Server. MariaDB nativ, nicht im Container.

Vaults und ihre Grenzen

Die Web-Dienste sind so aufgebaut, dass App-Code und Datenmasse in getrennten LVs liegen. Der Rsync bleibt mit xdev innerhalb eines Dateisystems; damit ist der Umfang eines Vaults durch die LV-Grenze definiert und nicht durch eine Exclude-Liste, die mit jedem Update erodiert.

Vault	Dienst	Zustand außerhalb des LV
www-cloudservice	Nextcloud (inkl. Passman)	Datenbank cloudservice auf janus
www-usvn	USVN / Subversion
www-trac	Trac
www-octoprint	OctoPrint
www-iobroker	ioBroker
janus-local	lokale Daten auf janus, u.a. die SQL-Dumps

Die rechte Spalte ist die eigentliche Fallgrube. Ein Vault ist genau so viel wert, wie die Antwort auf die Frage „welcher Zustand dieses Dienstes liegt nicht in diesem LV?" vollständig ist. Das betrifft Datenbanken auf anderen Hosts, Redis- oder !SQLite-Stände, und — weil xdev ja gerade nicht über Dateisystemgrenzen geht — jeden weiteren Mount innerhalb des Baums, etwa ein Docker-Volume unterhalb des Webroots.

Prüfung pro Dienst, einmalig und nach jedem Umbau:

# auf laubfrosch: hängt innerhalb des Webroots noch etwas eigenes?
findmnt -R /var/www/<dienst>

Taucht dort ein Mount auf, der in keinem Vault steht, ist er unsichtbar für das Backup.

Nextcloud und Passman im Detail

Warum Dump und config.php nur als Paar taugen

Passman verschlüsselt die ohnehin schon clientseitig verschlüsselten Credentials auf dem Server ein zweites Mal. Der dafür verwendete Schlüssel wird aus passwordsalt und secret aus der config.php abgeleitet. Daraus folgt:

• Ein Datenbank-Dump ohne die zugehörige config.php ist für die Passman-Daten wertlos — auch dann, wenn alle Benutzer ihr Vault-Passwort noch wissen.
• passwordsalt, secret und instanceid sind aus keinem Backup rekonstruierbar. Gehen sie verloren, sind sie weg.
• Beim Rollback eines fehlgeschlagenen Versionsupgrades müssen Dump und config.php vom selben Zeitpunkt stammen. In der config.php steht die version, die zum Schemastand der Datenbank passen muss; eine neue config.php auf einer alten Datenbank führt beim Start direkt in den Upgrade- oder Fehlerzustand.

Die config.php liegt auf laubfrosch unter:

/var/www/cloudservice.vpn21.net/htdocs/virgin/config/config.php

Sie liegt damit innerhalb des Webroots und wird vom Vault www-cloudservice erfasst — sofern config/ nicht als eigenes Docker-Volume gemountet ist. Das ist mit dem findmnt oben zu verifizieren und ist der wichtigste Einzelpunkt dieser Seite.

Was aus dem Backup grundsätzlich nicht wiederkommt

Der Vault-Key eines Passman-Vaults verlässt den Client nie. Es gibt keine Admin-Funktion, fremde Vaults zu sichern oder zu exportieren; die aktuelle Passman-Version registriert genau ein occ-Kommando, und das ist ein Wartungs-Check für Sharing-ACLs. Die Sicherung erfasst also die Daten aller Benutzer, aber lesbar macht sie nur der jeweilige Benutzer mit seinem Vault-Passwort.

Konsequenz für den Betrieb: Jeder Benutzer muss sein Vault-Passwort außerhalb von Nextcloud hinterlegt haben. Wer eine Nextcloud-unabhängig lesbare Kopie will, muss sie selbst ziehen — im Vault unter den Einstellungen als JSON-Export (vollständiger als CSV, da Custom Fields erhalten bleiben) und anschließend verschlüsselt ablegen. Zentral anstoßen lässt sich das nicht.

Sicherheitliche Kehrseite

Sobald SQL-Dump und passwordsalt/secret beide unverschlüsselt im Dirvish-Baum liegen, ist dieses Dateisystem der direkte Weg zur serverseitigen Entschlüsselungsschicht aller Passman-Daten. Dirvish verschlüsselt nichts, und die Hardlink-Historie bedeutet, dass das für alle Images gilt. Das ist eine bewusste Entscheidung wert, keine Nebenwirkung.

Ad-hoc-Sicherung vor einem Eingriff

Anzuwenden vor jedem Versionsupgrade und vor jedem Eingriff an einem Dienst. Die Images laufen in der normalen Rotation des Vaults mit; wer einen Pre-Upgrade-Stand länger halten will, muss ihn vor dem Verfallen auslagern.

Nextcloud (www-cloudservice)

Drei Hosts, der Reihe nach. Die Reihenfolge ist nicht beliebig: Erst stillstellen, dann dumpen, dann einsammeln.

1. Auf laubfrosch — Instanz stillstellen, damit Dump und Dateistand zueinander passen. Der trap sorgt dafür, dass ein Abbruch die Cloud nicht im Wartungsmodus stehen lässt:

   cd /var/www/cloudservice.vpn21.net
   ./enter-nextcloud-fpm-docker-container.sh
   ./occ maintenance:mode --on
   

2. Auf janus — Dump ziehen, in dasselbe Verzeichnis, das der pre-client des Vaults janus-local benutzt:

   # als root, sonst keine Schreibrechte in /var/lib
   mysqldump --single-transaction --quick --default-character-set=utf8mb4 \
     -u root -p cloudservice | gzip > /var/lib/cloudservice-$(date +%F-%H%M).sql.gz
   

   --single-transaction liefert bei reinem InnoDB einen konsistenten Snapshot ohne Sperren. --default-character-set=utf8mb4 ist zwingend, sonst schreddert der Dump die 4-Byte-Zeichen — die Instanz läuft mit utf8mb4 / utf8mb4_bin.
3. Auf laubfrosch — Wartungsmodus wieder aus:

   cd /var/www/cloudservice.vpn21.net
   ./enter-nextcloud-fpm-docker-container.sh
   ./occ maintenance:mode --off
   

4. Auf backer — beide Hälften einsammeln, als root. Der Code-/Config-Stand und der Dump liegen in verschiedenen Vaults und müssen deshalb beide gezogen werden:

   dirvish --vault www-cloudservice
   dirvish --vault janus-local
   

5. Gegenprobe auf backer, bevor der Eingriff beginnt:

   dirvish-locate www-cloudservice config/config.php | tail
   

   Zu sehen sein muss das soeben erzeugte Image. Erst dann ist der Rollback-Stand vollständig: Dump, config.php und App-Code vom selben Zeitpunkt.

Übrige Dienste

Gleiches Muster, verkürzt. Für Dienste ohne Zustand außerhalb des LV bleibt nur der letzte Schritt:

# auf backer, als root
dirvish --vault www-usvn        # bzw. www-trac, www-octoprint, www-iobroker

Hat der Dienst Zustand außerhalb seines LV (Spalte in der Vault-Tabelle oben), gehören davor dieselben Schritte wie bei Nextcloud: Dienst stillstellen oder in einen konsistenten Zustand bringen, Zustand in eine Datei schreiben, die in einem Vault liegt, dann erst dirvish. Beim Ausfüllen der Tabelle ist je Dienst zu klären:

• Läuft eine Datenbank außerhalb des LV, und wohin wird sie gedumpt?
• Hält der Dienst Zustand im RAM, der beim harten Stop verloren geht (ioBroker, OctoPrint)?
• Liegt eine SQLite-Datei im LV, die während des Rsync beschrieben werden kann?

Safe-Auszug der unersetzlichen Schlüssel

Weil passwordsalt, secret und instanceid unersetzlich sind, existieren sie zusätzlich auf Papier. Das Script [attachment:nc-secrets-sheet.sh] erzeugt den Auszug als Klartext-Blatt und als QR-Code.

Ablage des Scripts: als Anhang an dieser Seite sowie auf laubfrosch unter /var/www/cloudservice.vpn21.net.

Aufruf auf laubfrosch:

cd /var/www/cloudservice.vpn21.net
./nc-secrets-sheet.sh htdocs/virgin/config/config.php cloudservice.vpn21.net

Erzeugt werden nc-secrets-<datum>.txt und nc-secrets-<datum>.png. Der QR-Code enthält exakt dieselben key=value-Zeilen wie das Blatt, nicht die Prosa drumherum, mit Fehlerkorrektur auf Stufe H.

Eigenschaften, auf die beim Umgang zu achten ist:

• Fehlt einer der drei Einträge in der config.php oder ändert sich deren Schreibweise, bricht das Script ab, statt ein unvollständiges Blatt zu erzeugen.
• umask 077 steht im Script, die Dateien entstehen also nicht kurzzeitig mit offenen Rechten. Trotzdem gehören sie nicht in das Dirvish-Revier und sind nach dem Druck zu löschen — der vorgesehene Weg ist Papier und Safe.
• Das Blatt gehört nicht ins Passman-Vault und nicht ins Wiki: Ohne diese Werte lässt sich das Vault nicht öffnen, in dem sie dann lägen. Ins Wiki gehört das Script, nicht seine Ausgabe.
• Die Werte ändern sich im Normalbetrieb nicht, auch nicht über Versionsupgrades hinweg. Der Ausdruck altert also nicht und muss nur bei einem Neuaufsetzen der Instanz erneuert werden. Datum und Instanzname stehen auf dem Blatt, damit er in Jahren noch zuzuordnen ist.