Betrieb & Dokumentation › Backup & Wiederherstellung
Backup & Wiederherstellung
BetriebUnklar✓ Geprüft am Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)Die Werkstattdaten liegen in einer Datei-basierten SQLite-Datenbank unter einem festen Ordner (DATA_DIR). Ein Runbook beschreibt Restic+S3-Backups mit 4-Stunden-Wiederherstellungsziel, aber die dafür nötigen Umgebungsvariablen sind nirgends im Projekt (.env.example) als vorhanden dokumentiert.
Bild folgt
Die Werkstattdaten liegen in einer Datei-Datenbank, die per Docker-Volume auf dem Server abgelegt wird. Ein Runbook beschreibt ein Sicherungsverfahren gegen einen externen Objektspeicher mit einem Wiederherstellungsziel von vier Stunden, dazu einen vierteljährlichen Übungslauf. Die dafür nötigen Zugangswerte fehlen in der Vorlage für die Server-Einstellungen — ob eine automatische, regelmäßige Sicherung tatsächlich läuft, lässt sich aus dem Projekt allein nicht belegen, nur die Anleitung dafür existiert nachweislich.
- Nach einem Serverausfall oder einer beschädigten Datenbank → das Wiederherstellungs-Runbook Schritt für Schritt befolgen, zuerst die verfügbaren Sicherungspunkte auflisten, bevor etwas ersetzt wird.
- Unklar, ob überhaupt eine aktuelle Sicherung existiert → das lässt sich nur mit Zugriff auf den Server prüfen, nicht aus dem Projektcode allein.
- Ob automatisierte Backups tatsaechlich laufen (Cron/Systemd-Timer auf dem Server) konnte im Rahmen dieses Datenaxis nicht geprueft werden — das gehoert zur ops-Achse.
- docs/RESTORE.md
- .env.example
- docker-compose.yml
| werkzeug | restic gegen S3-kompatiblen Object Storage (Hetzner nbg1), Env-Variablen BACKUP_S3_*, RESTIC_REPOSITORY, RESTIC_PASSWORD |
|---|---|
| rto | 4 Stunden laut Runbook |
| besonderheit | Runbook nennt 'Disaster Recovery Drill (Quartalsweise)' als Anwendungsfall — ob dieser Drill tatsaechlich vierteljaehrlich stattfindet, ist nicht im Code/Dateisystem belegbar, nur behauptet |
| datenordner | DATA_DIR (Hausregel 4), im Container /app/.data, gemountetes Volume |
| luecke | kein Beleg gefunden, dass automatisierte Backups tatsächlich laufen (kein Cron-Eintrag unter den 19 Cron-Routen mit erkennbarem Backup-Namen geprüft, kein MEM-Eintrag über einen tatsaechlichen Restore-Test) |
Beleg: docs/RESTORE.md vorhanden und detailliert (restic + S3-kompatibler Object Storage, RTO-Ziel 4h) — ob die Sicherung selbst automatisiert laeuft und regelmaessig getestet wird, ist aus dem Runbook allein nicht zu belegen
Tiefer fragen
Kontext aus dem KFZ-Bozo-Handbuch
Knoten: ops-backup (Betrieb · Betrieb & Dokumentation · unklar · geprüft Sat Sep 05 2026 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) @ 0f0406a1)
Kurz: Die Werkstattdaten liegen in einer Datei-basierten SQLite-Datenbank unter einem festen Ordner (DATA_DIR). Ein Runbook beschreibt Restic+S3-Backups mit 4-Stunden-Wiederherstellungsziel, aber die dafür nötigen Umgebungsvariablen sind nirgends im Projekt (.env.example) als vorhanden dokumentiert.
Lies zuerst (Lesebereich, nicht der ganze Baum):
docs/RESTORE.md
.env.example
docker-compose.yml
Hängt zusammen mit:
ops-deploy (docs/hetzner-migration-runbook.md) · data-auftrag (lib/db/jobs.ts) · data-belege (lib/db/schema.ts) · ops-env (.env.example)
Offene Fragen der Seite:
Ob automatisierte Backups tatsaechlich laufen (Cron/Systemd-Timer auf dem Server) konnte im Rahmen dieses Datenaxis nicht geprueft werden — das gehoert zur ops-Achse.
Hausregel 2: Vault-Daten sind für diese Session unsichtbar; Quellpfade auf Vault-Code sind keine Freigabe.
Frage: {{DEINE FRAGE}}
Antworte nur mit Belegen: nenne Datei und Zeile für jede Aussage.
Wenn die Quellen die Frage nicht beantworten, sag das und nenne, was du zusätzlich lesen müsstest.
Weicht die Seite vom Code ab, schlage den Seiten-Patch vor (wiki/seiten/betrieb-doku/ops-backup.md).