Sicherung und Wiederherstellung

Auf dem eigenen Server ist die Sicherung Sache des Betreibers. WorkOffice bringt dafür zwei Skripte mit: eines für die nächtliche Sicherung, eines zum Zurückspielen.

Was zu sichern ist

Ort	Inhalt
Volume `postgres_data`	alle Betriebe, Kunden, Rechnungen, Zahlungen, Protokoll
Volume `ablage`	Eingangsbelege, archivierte Rechnungs-PDFs, Mahnungen, DATEV-Exporte, Lexware-Archiv
`.env`	die Geheimnisse, vor allem `JWT_SECRET`, `GEHEIMNIS_SCHLUESSEL`, `WEBHOOK_PRIVATE_KEY` (und `LICENSE_KEY`, falls dort eingetragen)
`/etc/caddy/Caddyfile`	der Reverse Proxy

Eine Datenbanksicherung allein ist nicht vollständig. Belegbilder und archivierte PDFs liegen in der Dateiablage, nicht in der Datenbank. Und ohne die alte .env sind nach dem Zurückspielen die Anmeldungen und die verschlüsselt gespeicherten Geheimnisse der Betriebe nicht mehr zu gebrauchen.

Schlüssel, Kennung und letzte Bestätigung der Lizenz liegen in der Datenbank. lizenz/public.pem sichert das Skript nicht; sie lässt sich jederzeit neu abrufen – auf einem neuen Server mit dem Befehl unter Lizenz.

Die nächtliche Sicherung einrichten

Einmal, als root:

cp /opt/workoffice-pro/scripts/sicherung-server.sh /usr/local/bin/workoffice-sicherung
chmod 700 /usr/local/bin/workoffice-sicherung
echo '45 2 * * * root /usr/local/bin/workoffice-sicherung >> /var/log/workoffice-sicherung.log 2>&1' \
  > /etc/cron.d/workoffice-sicherung

Das Skript läuft dann jede Nacht um 2:45 Uhr. Läuft WorkTime Pro auf demselben Server, sichert dessen Skript um 2:30 – die beiden teilen sich so nicht gleichzeitig die Platte.

Was das Skript tut

Datenbank mit pg_dump als Eigentümer workoffice – der Anwendungsbenutzer sähe wegen der Mandantentrennung nur einen Teil der Zeilen.
Dateiablage als tar.gz, über einen kurzlebigen Hilfscontainer mit dem Volume nur zum Lesen. Das klappt auch, wenn die API gerade nicht läuft.
.env und Caddyfile kopieren.
Prüfen: Lässt sich die Datenbanksicherung lesen, ist das Archiv unbeschädigt? Eine Sicherung, die sich nicht lesen lässt, ist keine.
Aufräumen: Die Sicherungen liegen unter /var/backups/workoffice/<Datum>/, ältere als 14 Tage werden gelöscht.
Zweitkopie, wenn eingerichtet (unten).

Nach jedem Lauf – auch nach einem abgebrochenen – schreibt das Skript seinen Stand nach /var/lib/workoffice/stand/sicherung.json: Zeit, Erfolg, Dauer, Größe, Zweitkopie, ohne Geheimnisse. Bricht es ab, steht dort, bei welchem Schritt.

Ein zweiter Speicher

Eine Sicherung auf derselben Platte hilft nicht, wenn die Platte stirbt. In die .env:

SICHERUNG_ZIEL=benutzer@speicher.example.de:workoffice

Das schiebt den Ordner /var/backups/workoffice/ per rsync über SSH auf einen anderen Speicher, etwa eine Storage Box; der Zugang muss ohne Passwortabfrage gehen (SSH-Schlüssel). Wer lieber eine Datei hochlädt, trägt stattdessen einen beliebigen Befehl ein, in dem {} für das Archiv der Nacht steht:

SICHERUNG_HOCHLADEN=<Upload-Befehl mit {}>

Scheitert die Zweitkopie, ist die Sicherung auf dem Server trotzdem vollständig; der Stand meldet „Zweitkopie fehlgeschlagen“.

Sicherung ist nicht Aufbewahrung. Die nächtliche Sicherung schützt vor Ausfällen. Die Aufbewahrung nach GoBD – Rechnungen acht, Bücher zehn Jahre – leistet die Anwendung selbst: Festgeschriebene Belege sind unveränderbar. Trotzdem gehört einmal im Jahr eine Sicherung dauerhaft auf einen zweiten Speicher.

Zurückspielen

Fall	Befehl
Stand von gestern zurückholen	`scripts/wiederherstellen-server.sh /var/backups/workoffice/<Datum>`
neuer Server nach einem Ausfall	einrichten wie unter Einrichten (mit fertigen Abbildern samt `lizenz/public.pem`), starten, dann `scripts/wiederherstellen-server.sh <Sicherung> --mit-env`, DNS umstellen

Statt eines Ordners geht auch das Archiv aus der Zweitkopie (.tar.gz). Das Skript

prüft zuerst, ob sich die Sicherung lesen lässt – eine kaputte rührt den aktuellen Stand nicht an;
fragt nach und will WIEDERHERSTELLEN getippt haben, denn alles, was nach der Sicherung geschrieben wurde, ist danach weg;
sichert vorher den aktuellen Stand nach vor-wiederherstellung-… – ein Griff zur falschen Sicherung ist so nicht endgültig;
hält Oberfläche und API an, legt die Datenbank neu an, spielt Datenbank und Ablage zurück und startet wieder.

Mit --mit-env spielt es auch .env und Caddyfile zurück und gleicht das Datenbank-Passwort an. Rechte, Richtlinien und den Anwendungsbenutzer zieht der Start der API von selbst nach. Danach anmelden und eine Rechnung öffnen.

Die Lizenz läuft nach dem Zurückspielen weiter, denn die Kennung der Installation steckt in der Datenbank.