Paperless-ngx Backups: Mehr als nur Dateien kopieren

Uncategorized

Paperless-ngx: On-Premise-Backups solide absichern – mehr als nur Dateien kopieren

Die Euphorie nach der erfolgreichen Einführung von Paperless-ngx als zentralen Dokumentenhub ist verständlich. Endlich Ordnung in der Vertragsflut, der Rechnungsflut, dem täglichen Papierkrieg. Doch im Hintergrund lauert eine oft unterschätzte Gefahr: die Verwundbarkeit dieser nun so wertvollen Daten. Ein simples Kopieren der Verzeichnisse reicht bei Weitem nicht aus, um Ihr digitales Gedächtnis wirklich zu schützen. Wie Sie Backups für Ihre On-Premise-Installation von Paperless-ngx so gestalten, dass sie im Ernstfall auch halten, was sie versprechen, darum geht es hier. Ohne Hype, mit handfesten Empfehlungen.

Warum „einfach kopieren“ in die Irre führt

Paperless-ngx ist kein statischer Dateihaufen, sondern ein komplexes System aus mehreren, eng verwobenen Komponenten. Das vergessen viele Admins im ersten Eifer. Stellen Sie es sich vor wie eine Bibliothek: Nicht nur die Bücher (die PDFs, Scans, Office-Dokumente) sind wichtig, sondern auch der elektronische Katalog (die Datenbank), der genau weiß, welches Buch wo steht, wer es ausgeliehen hat, welche Schlagworte es trägt, und sogar die Regalanordnung selbst (die Verzeichnisstruktur, Konfigurationen).

  • Die Datenbank (meist PostgreSQL): Das Herzstück. Hier liegen alle Metadaten (Titel, Korrespondent, Dokumenttyp, Tags, Datum, Kommentare), die Zuordnung welches Dokument zu welchem Eintrag gehört, Benutzerkonten, Berechtigungen, Konsumbefehle, E-Mail-Regeln – kurz: die gesamte Intelligenz des Systems.
  • Das Medienverzeichnis (`MEDIA_ROOT`): Hier lagern die Originaldokumente selbst – also Ihre PDFs, JPGs, DOCX-Dateien usw. Paperless-ngx organisiert diese in einer Unterverzeichnisstruktur (üblicherweise nach Jahr/Monat/Tag oder einer UUID-basierten Struktur).
  • Das Konfigurationsverzeichnis (oft `PAPERLESS_CONFIG_DIR`): Enthält die lebenswichtige `config.env` oder `.env` Datei mit Datenbankzugangsdaten, Geheimnissen (SECRET_KEY!), Pfadangaben, Verhaltenseinstellungen. Dazu kommen oft benutzerdefinierte Klassifikationsmodelle, benutzerdefinierte OCR-Sprachpakete oder Skripte.
  • Die Indizes (meist Apache Tika/Solr oder Whoosh): Für die schnelle Volltextsuche erstellt Paperless-ngx Indizes. Diese sind regenerierbar, aber ihr Verlust bedeutet eine langwierige Neuindizierung aller Dokumente, was bei großen Archiven Stunden oder Tage dauern kann.

Das fatale Szenario: Sie kopieren nur das Medienverzeichnis. Nach einem Servercrash stellen Sie diese Dateien wieder her. Aber ohne die dazugehörige Datenbank ist es nur ein Haufen unzusammenhängender Dateien – nutzlos. Die Metadaten, die Suche, die Organisation: weg. Ein Backup, das nur Teile rettet, ist im Grunde kein Backup.

Die Eckpfeiler eines robusten Backup-Konzepts

Ein belastbares Backup für Paperless-ngx fußt auf mehreren Prinzipien, die über die reine Datensicherung hinausgehen:

  1. Vollständigkeit: Alle kritischen Komponenten (Datenbank, Medien, Konfig, Indizes optional) müssen erfasst werden, und zwar in einem konsistenten Zustand.
  2. Konsistenz: Die Sicherung von Datenbank und Medienverzeichnis sollte möglichst zeitnah zueinander erfolgen, um Inkonsistenzen zu vermeiden (z.B., dass in der DB ein Dokument referenziert wird, das im Medienverzeichnis noch nicht oder nicht mehr existiert).
  3. Regelmäßigkeit: Festgelegte, automatisierte Backup-Zyklen (täglich, stündlich – abhängig vom Dokumentenaufkommen und der Toleranz für Datenverlust).
  4. Isolation & Sicherheit: Backups müssen physisch und logisch vom Produktivsystem getrennt und vor unbefugtem Zugriff (Verschlüsselung!) sowie physikalischen Gefahren (Brand, Wasser) geschützt sein.
  5. Testbarkeit: Ein Backup, das nicht regelmäßig durch eine komplette Wiederherstellung getestet wird, ist wertlos. Nur der Test zeigt, ob das Verfahren funktioniert und die Daten intakt sind.
  6. Dokumentation: Klare Anweisungen zur Wiederherstellung – wer macht was, wann, mit welchen Kommandos? Diese Anleitung muss außerhalb des betroffenen Systems verfügbar sein.

Ein Wort zur 3-2-1-Regel: Drei Kopien der Daten, auf zwei verschiedenen Medien, eine davon außer Haus. Das sollte das Minimum sein, auch für Paperless-ngx. Eine Kopie auf dem lokalen Server (schneller Zugriff), eine auf einem anderen internen System/NAS, eine in einer sicheren Cloud oder auf einem Wechselmedium an einem externen Standort.

Praktische Umsetzung: Methoden für den Admin-Alltag

Wie packt man es nun technisch an? Hier die gängigsten und robustesten Methoden:

1. Der Klassiker: pg_dump und rsync (oder tar/gzip)

Diese Methode setzt auf bewährte Unix-Tools und bietet maximale Transparenz und Kontrolle.

  • Datenbank-Sicherung mit `pg_dump`: 
    pg_dump -U paperless -d paperless -F c -b -v -f /pfad/zum/backup/paperless_db_$(date +%Y%m%d_%H%M%S).dump

    Erklärung: `-F c` für das flexible „Custom“-Format, `-b` für Blobs (wichtig!), `-v` für Verbose-Ausgabe. Das Datum im Dateinamen hilft bei der Versionierung. Wichtig: Der Nutzer (`-U paperless`) braucht entsprechende Rechte. Diese Dumps sind relativ klein und komprimiert.

  • Medienverzeichnis sichern: 
    rsync -av --delete /pfad/zum/paperless/media/ /pfad/zum/backup/media/

    Oder für eine einzelne archivierte Momentaufnahme:

    tar -czvf /pfad/zum/backup/media_$(date +%Y%m%d_%H%M%S).tar.gz /pfad/zum/paperless/media

    `rsync` ist effizient für inkrementelle Backups, `tar` erzeugt ein portables Archiv. `–delete` bei rsync löscht im Ziel gelöschte Dateien (Vorsicht!).

  • Konfiguration und wichtige Extras: 
    tar -czvf /pfad/zum/backup/config_$(date +%Y%m%d_%H%M%S).tar.gz \
    /pfad/zum/paperless/config \
    /pfad/zum/paperless/export \
    /pfad/zum/paperless/consume \
    /opt/paperless/ocr_models # Falls benutzerdefinierte Modelle existieren
  • Automatisierung: Per `cron`-Job. Beispiel für eine nächtliche Sicherung um 2 Uhr:

    0 2 * * * /usr/bin/pg_dump -U paperless -d paperless -F c -b -f /backup/db/paperless_db_$(date +\%Y\%m\%d).dump
0 2 * * * /usr/bin/rsync -av --delete /opt/paperless/media/ /backup/media/
0 2 * * * /usr/bin/tar -czf /backup/config/config_$(date +\%Y\%m\%d).tar.gz /opt/paperless/config /opt/paperless/export

    Wichtig: Passwörter für die DB sollten sicher (z.B. in `.pgpass` Datei mit korrekten Rechten 0600) hinterlegt sein, um keine Klartextpasswörter im Skript zu haben!

Vorteile: Einfach, transparent, ressourcenschonend, gut kontrollierbar. Direkter Zugriff auf einzelne Dateien möglich (besonders bei rsync).
Nachteile: Konsistenz zwischen DB-Dump und Medienverzeichnis ist nicht atomar (d.h., zwischen den beiden Schritten können Änderungen passieren). Für sehr große Medienverzeichnisse kann das `tar`-Kommando lange dauern und viel temporären Speicher brauchen. Manuelle Verwaltung der Backup-Retention (alte Backups löschen).

2. Dateisystem-Snapshots (LVM, ZFS, Btrfs)

Wenn Ihr Server auf Logical Volume Management (LVM), ZFS oder Btrfs läuft, bieten sich Snapshots an. Ein Snapshot friert den Zustand eines Dateisystems zu einem exakten Zeitpunkt ein – atomar und sehr schnell.

  • Voraussetzung: Datenbank, Medienverzeichnis und Konfiguration sollten idealerweise auf eigenen logical volumes (LVM) oder Datasets (ZFS/Btrfs) liegen, die gesnapshotet werden können.
  • Ablauf:
    1. Datenbank in einen konsistenten Zustand bringen (optional, aber empfohlen). Bei PostgreSQL kann man vor dem Snapshot `pg_start_backup()` (deprecated in neueren Versionen) oder besser: den Datenbank-Server kurz pausieren (`pg_ctl pause`) oder einen exklusiven `pg_dump` starten, der einen konsistenten Zustand garantiert. Oder man verlässt sich auf das Copy-on-Write der Snapshots und die Fähigkeit von PG, aus einem unscharfen Snapshot zu recoveren (Point-in-Time-Recovery PITR vorausgesetzt).
    2. Snapshot des Volumes/Datasets erstellen (z.B. `lvcreate –snapshot –name papersnap –size 1G /dev/vg_data/lv_paperless` bei LVM).
    3. Datenbankoperationen wieder fortsetzen (`pg_ctl resume` oder `pg_stop_backup()`).
    4. Den Snapshot mounten und daraus das eigentliche Backup (z.B. mit `rsync` oder `tar`) auf ein anderes Ziel durchführen. Alternativ: Den Snapshot direkt als Sicherung verwenden (etwa bei ZFS send/receive zu einem Backup-Server).
    5. Snapshot nach erfolgreichem Backup löschen.

Vorteile: Nahezu sofortige Erstellung, garantiert konsistenter Zustand *aller* Dateien zum Snapshot-Zeitpunkt (atomar), sehr geringer Performance-Overhead während der Erstellung.
Nachteile: Benötigt spezifische Dateisysteme/Volume-Manager, Setup ist etwas komplexer. Snapshots selbst sind keine echten Backups (liegen meist auf demselben physikalischen Storage), müssen also noch woandershin gesichert werden. Verbrauchen je nach Änderungsrate Speicherplatz.

3. Container-spezifische Methoden (Docker)

Paperless-ngx läuft häufig in Docker-Containern. Das ändert die Backup-Strategie leicht.

  • Volumes identifizieren: Wo liegen die persistierten Daten? 
    docker volume ls
docker inspect paperlessngx_app_1  # Schauen nach "Mounts"

    Typischerweise gibt es Volumes für `data` (Medien), `pgdata` (Datenbank), `consume`, `export`, ggf. `config`.

  • Backup innerhalb des Containers: Ähnlich wie bei einer nativen Installation, aber Befehle laufen *im* Container. Beispiel für DB-Dump: 
    docker exec paperlessngx_db_1 pg_dump -U paperless -d paperless -F c -b -f /tmp/backup.dump
docker cp paperlessngx_db_1:/tmp/backup.dump /host/pfad/backup.dump

    Für Medienverzeichnis: Entweder direkt das Volume sichern (s.u.) oder `docker exec` mit `tar`/`rsync`.

  • Backup der Volumes von außen: Docker-Volumes liegen normalerweise unter `/var/lib/docker/volumes/`, aber direkt zugreifen ist nicht empfohlen. Besser:
    • Stoppen Sie die betroffenen Container kurz (besonders wichtig für die DB-Konsistenz!).
    • Mounten Sie das Volume temporär auf den Host oder in einen Hilfscontainer.
    • Sichern Sie die Daten vom gemounteten Pfad (z.B. mit `tar` oder `rsync`).
    • Starten Sie die Container wieder.
    • Oder: Nutzen Sie Tools wie `docker run –rm -v paperlessngx_pgdata:/source -v /host/backup:/backup alpine tar czf /backup/pgdata.tar.gz -C /source .`
  • Docker-Compose speichern: Vergessen Sie nicht Ihr `docker-compose.yml` und eventuelle `.env`-Dateien mit den Konfigurationen zu sichern! Sie sind Teil der Infrastruktur-Definition.

Vorteile: Integriert sich in Docker-Workflows.
Nachteile: Etwas umständlicherer Zugriff auf die Daten, Konsistenzsicherung erfordert ggf. Container-Stopp. Komplexität durch Container-Layer.

4. Dedizierte Backup-Tools (BorgBackup, Restic, Duplicity)

Diese Tools sind speziell für effiziente, sichere und versionsverwaltete Backups gemacht. Sie bieten Deduplizierung, Kompression, Verschlüsselung und einfache Retention-Policies out-of-the-box.

  • Prinzip: Sie sichern die *Dateien* (Medienverzeichnis, Konfig, eventuell exportierte DB-Dumps) in ein dediziertes Backup-Repository. Die Datenbank sollte weiterhin separat mit `pg_dump` gesichert und das Ergebnis dann vom Tool mit erfasst werden.
  • Beispiel BorgBackup: 
    # Repository initialisieren (einmalig)
borg init --encryption=repokey /pfad/zum/repo

# Backup-Job (z.B. täglich)
# Schritt 1: DB Dump erstellen
pg_dump -U paperless -d paperless -F c -b -f /tmp/paperless_latest.dump
# Schritt 2: Alles sichern (DB-Dump, Medien, Config)
borg create --stats --progress /pfad/zum/repo::paperless-{now} \
    /tmp/paperless_latest.dump \
    /pfad/zum/paperless/media \
    /pfad/zum/paperless/config \
    /pfad/zum/paperless/export
# Schritt 3: Temporären DB-Dump löschen
rm /tmp/paperless_latest.dump

# Retention (z.B. 7 tägliche, 4 wöchentliche, 12 monatliche Backups behalten)
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12 /pfad/zum/repo
  • Vorteile: Sehr platzsparend durch Deduplizierung, starke Verschlüsselung, effiziente Inkremental-Backups, einfache Retention-Verwaltung, Prüfung der Backup-Integrität möglich.
    Nachteile: Lernkurve für das Tool, Backup-Repository muss separat verwaltet werden. Direkter Zugriff auf eine einzelne Datei im Backup ist etwas umständlicher als bei einem einfachen Dateikopier.

Der Elefant im Raum: Konsistenz zwischen Datenbank und Dateien

Die größte Herausforderung bei allen Methoden ist es, einen Zustand zu sichern, bei dem die Referenzen in der Datenbank genau auf die Dateien im Medienverzeichnis passen. Ein Dokument, das in der DB existiert, dessen Datei aber nicht (mehr) im Backup des Medienverzeichnisses liegt, ist ein Ärgernis. Umgekehrt ist eine Datei ohne DB-Eintrag bloß nutzloser Ballast.

Strategien zur Minimierung des Risikos:

  • Enger zeitlicher Zusammenhang: Sicherung von DB und Medien so kurz nacheinander wie möglich automatisieren (innerhalb weniger Sekunden/Minuten).
  • Datenbank-Dump als Ausgangspunkt: Bei Methoden, die das Medienverzeichnis direkt sichern (rsync, tar, Filesystem-Snapshot), zuerst den DB-Dump erstellen. Warum? Die Datenbank enthält den „aktuelleren“ Zustand. Ein Dokument, das *nach* dem DB-Dump aber *vor* der Medien-Sicherung gelöscht wird, existiert noch im DB-Dump, aber nicht mehr im Medien-Backup -> Inkonsistenz. Ein Dokument, das *nach* dem DB-Dump *erstellt* wird, existiert im Medien-Backup, aber nicht in der DB -> weniger schlimm (es ist eh nicht referenziert, kann als „verwaist“ ignoriert oder später neu importiert werden). Das Risiko von „fehlenden Dateien“ (schlimmer) ist also geringer, wenn die DB vor den Dateien gesichert wird.
  • Kurzes Stoppen der Paperless-Dienste: Die radikalste, aber sicherste Methode: Paperless-ngx (insbesondere den Consumer und Web-Server) während des Backups kurz stoppen. Verhindert, dass während der Sicherung neue Dokumente hinzukommen oder bestehende modifiziert/gelöscht werden. Macht das System aber kurzzeitig unverfügbar. Oft nur für nächtliche Backups praktikabel.
  • Filesystem-Snapshots: Wie oben beschrieben, bieten sie die beste Garantie für einen atomar konsistenten Zustand *aller* Dateien (inkl. DB-Dateien) zu einem exakten Zeitpunkt – wenn sie korrekt eingesetzt werden (DB ggf. pausieren oder auf PITR setzen).
  • Paperless-ngx eigene Export-Funktion (mit Einschränkungen): Der „Verwalten -> Wartung -> Dokumente exportieren“-Dialog erstellt ein ZIP-Archiv mit allen Dokumenten und einer `manifest.json`, die die Metadaten enthält. Das ist ein konsistenter Snapshot. ABER: Für große Archive extrem langsam und ressourcenintensiv (komprimiert alles neu), unterbricht die Nutzung, und die Wiederherstellung daraus ist nicht der Standardweg (man müsste theoretisch neu importieren). Eher als Notfalloption oder für kleine Archive geeignet, nicht als primäres Backup.

Ein praktischer Kompromiss: Täglicher Vollbackup nachts (ggf. mit kurzem Dienstestopp oder Filesystem-Snapshot) plus häufige (stündliche) inkrementelle Sicherungen der Datenbank (`pg_dump`). Die Mediendateien ändern sich nach ihrer Erstellung und OCR normalerweise nicht mehr, daher reicht hier eine tägliche Sicherung oft aus. Die Datenbank (Metadaten, Tags, Korrespondentenänderungen) ändert sich häufiger.

Sicherheit der Backups: Verschlüsselung und Zugriff

Ein Backup, das unverschlüsselt auf einer Netzwerkfreigabe liegt, ist ein gefundenes Fressen für Angreifer oder neugierige Blicke. Paperless-ngx speichert potenziell hochsensible Daten (Verträge, Personalunterlagen, Finanzen).

  • Verschlüsselung im Ruhezustand (At-Rest):
    • Backup-Tools: Nutzen Sie Tools mit integrierter Verschlüsselung (BorgBackup, Restic, Duplicity). Konfigurieren Sie ein starkes Passwort.
    • Manuelle Methoden: Verschlüsseln Sie Backups vor der Übertragung oder Speicherung. GnuPG (GPG) ist hierfür Standard: 
      # Verschlüsseln eines Backups
gpg --symmetric --cipher-algo AES256 --output /backup/media_encrypted.gpg /backup/media.tar.gz
# Entschlüsseln
gpg --decrypt --output media.tar.gz /backup/media_encrypted.gpg

      Oder verschlüsselte Container mit `veracrypt` oder `cryptsetup` (LUKS) erstellen und dort die Backups ablegen.

    • Verschlüsselte Ziele: Sichern Sie direkt auf eine verschlüsselte Festplatte oder eine verschlüsselte Cloud-Speicherung (die Verschlüsselung sollte clientseitig erfolgen, nicht nur serverseitig beim Provider!).
  • Sichere Übertragung: Nutzen Sie immer verschlüsselte Protokolle (SSH/SCP/SFTP, Rsync over SSH, HTTPS) für die Übertragung der Backups auf externe Ziele. Niemals FTP oder unverschlüsseltes SMB/CIFS für sensible Backups!
  • Zugriffskontrolle: Beschränken Sie den Zugriff auf die Backup-Dateien und -Verzeichnisse streng (Unix-Dateiberechtigungen: nur Backup-User und root). Protokollieren Sie Zugriffe wenn möglich. Die `config.env` mit dem `SECRET_KEY` und DB-Passwörtern ist besonders kritisch!

Die Königsdisziplin: Der Wiederherstellungstest

All die schönen Backups sind Makulatur, wenn die Wiederherstellung im Ernstfall scheitert. Das ist keine theoretische Gefahr. Gründe sind vielfältig: Fehler im Backup-Skript, unentdeckte Datenkorruption auf dem Primärsystem, die ins Backup übernommen wurde, falsche Berechtigungen nach der Wiederherstellung, geänderte Umgebungsvariablen, vergessene Abhängigkeiten.

So testen Sie ernsthaft:

  1. Regelmäßigkeit: Mindestens quartalsweise, besser monatlich. Nach größeren Paperless-Updates oder Änderungen an der Backup-Strategie sofort.
  2. Isolierte Umgebung: Nutzen Sie einen separaten Server oder eine virtuelle Maschine. Niemals auf dem laufenden Produktivsystem testen!
  3. Vollständiger Ablauf:
    • Frische Basis-Installation: OS, Docker (wenn nötig), PostgreSQL, Redis, Tesseract, alle Abhängigkeiten wie bei der Produktivumgebung.
    • Wiederherstellung der Konfiguration (`config.env`, Volume-Mounts bei Docker, etc.). Achtung: Alte `SECRET_KEY` verwenden, sonst sind gespeicherte Sitzungen/Benutzer-Tokens ungültig! DB-Passwörter müssen mit denen in der wiederhergestellten `config.env` übereinstimmen.
    • Wiederherstellung der Datenbank aus dem Dump: 
      # Alte DB löschen (frisch installierte Umgebung)
dropdb -U paperless paperless
# Neue DB erstellen
createdb -U paperless paperless
# Dump einspielen
pg_restore -U paperless -d paperless -v /pfad/zum/dump.dump
    • Wiederherstellung des Medienverzeichnisses: Einfach das gesicherte Verzeichnis (via rsync/tar/Borg) an den Zielort kopieren. Auf korrekte Pfade in der Konfiguration (`PAPERLESS_MEDIA_ROOT`) achten!
    • Wiederherstellung der Konfiguration/Exporte/Consume-Verzeichnisse analog.
    • Paperless-ngx Dienste starten.
  4. Validierung:
    • Anmeldung im Webinterface: Funktioniert sie?
    • Dokumentenzahl prüfen: Stimmt sie mit der erwarteten Anzahl überein?
    • Stichproben: Einige Dokumente verschiedener Typen öffnen. Ist der Inhalt (PDF) da? Stimmen die Metadaten (Korrespondent, Typ, Tags, Datum)?
    • Volltextsuche testen: Findet ein eindeutiger Begriff aus einem bekannten Dokument?
    • Neuer Import testen: Kann ein Dokument per „Verbrauchen“ erfolgreich importiert und indiziert werden?
    • Logs prüfen: Gibt es Fehlermeldungen beim Start oder bei den Tests (z.B. fehlende Dateien, OCR-Fehler)?
  5. Dokumentation des Tests: Halten Sie fest, wann getestet wurde, welche Backup-Datei verwendet wurde, welche Schritte durchgeführt wurden, wer es durchgeführt hat und was das Ergebnis war (inkl. etwaiger Probleme).

Nur wenn dieser Test durchgängig grün ist, können Sie sich halbwegs sicher fühlen. Ein interessanter Nebeneffekt: Sie haben automatisch ein aktuelles Disaster-Recovery-Szenario dokumentiert und geprobt.

Integration in den Betrieb: Automatisierung, Monitoring, Retention

Backups dürfen keine manuelle Aufgabe sein und müssen überwacht werden.

  • Automatisierung: Cron-Jobs, Systemd-Timer oder Aufgabenplanung sind Ihr Freund. Skripte sollten sauber loggen (z.B. mit `logger` oder in eigene Dateien).
  • Monitoring:
    • Prüfen, ob Backup-Jobs erfolgreich laufen: Exit-Code des Skripts überwachen (z.B. mit Nagios, Icinga, Zabbix, Prometheus + Alertmanager, oder einfachen `cron`-E-Mails bei Fehlern).
    • Prüfen, ob Backups *tatsächlich* erstellt werden: Prüfsummen der Backup-Dateien, Größenänderungen, „frische“ Zeitstempel. Tools wie `check_mk` oder selbstgeschriebene Skripte können das.
    • Speicherplatz am Backup-Ziel überwachen! Volle Platten sind eine häufige Ursache für fehlgeschlagene Backups.
  • Retention (Aufbewahrungsfristen): Legen Sie fest, wie lange Backups aufbewahrt werden. Das hängt ab von:
    • Gesetzlichen oder internen Compliance-Vorgaben (z.B. Aufbewahrungspflicht für Geschäftsbriefe: 6-10 Jahre).
    • Platzverfügbarkeit.
    • Risikoabschätzung (Wie weit will/muss ich im Ernstfall zurück?).

    Typische Schemata: Tägliche Backups 7 Tage, wöchentliche Backups 4 Wochen, monatliche Backups 12 Monate, jährliche Backups X Jahre. Automatisieren Sie das Löschen alter Backups (z.B. mit `find -mtime +30 -delete`, oder den Prune-Funktionen von Borg/Restic).

Cloud-Backups als Alternative? Eine kritische Betrachtung

Die naheliegende Frage: Warum nicht einfach alles in die Cloud schieben? Angebote wie Backblaze B2, Wasabi, AWS S3 Glacier sind kostengünstig. Paperless-ngx selbst bietet rudimentäre S3-Kompatibilität für das Medienverzeichnis an. Aber:

  • Datenbank bleibt kritisch: Auch bei Cloud-Speicherung für Medien muss die PostgreSQL-Datenbank separat und konsistent gesichert werden. Ein reines Media-Backup in die Cloud löst das Kernproblem nicht.
  • Konsistenz-Herausforderung: Die synchrone Sicherstellung, dass ein Cloud-Backup der Medien exakt zum Zeitpunkt des DB-Dumps passt, ist technisch anspruchsvoller als bei lokalen Backups (Latenzen, Übertragungsdauer).
  • Wiederherstellungsgeschwindigkeit: Das Herunterladen großer Medienarchive aus der Cloud kann bei einem kompletten Crash sehr lange dauern (Tage?), während lokale Backups oder Snapshots Minuten brauchen. Für RTO-Ziele (Recovery Time Objective) oft nicht akzeptabel.
  • Kostenkontrolle: Egress-Kosten (Datenabruf) können bei einer großen Wiederherstellung unerwartet hoch ausfallen. Glacier-Tiering bedeutet lange Vorlaufzeiten für die Datenverfügbarkeit.
  • Sicherheit & Compliance: Wer hat Zugriff? Wo liegen die Daten physisch? Erfüllt der Provider die nötigen Zertifizierungen (ISO 27001, BSI C5, etc.)? Ist die Verschlüsselung clientseitig (unbedingt erforderlich!)?

Fazit: Die Cloud kann eine hervorragende Komponente für das „außer Haus“-Backup im 3-2-1-Schema sein, besonders für die längerfristige Archivierung. Als alleiniges oder primäres Backup-Ziel für die schnelle Wiederherstellung einer On-Premise-Paperless-ngx-Instanz ist sie jedoch oft nicht die erste Wahl. Ein hybrides Modell (lokale schnelle Backups + Cloud für Langzeit/Offsite) ist meist ideal. Tools wie Restic oder BorgBackup unterstützen S3-kompatible Backends hervorragend.

Checkliste für Ihr Paperless-ngx Backup

Abschließend eine kompakte Checkliste zur Überprüfung oder Einrichtung:

  • [ ] Komponenten identifiziert: DB (PostgreSQL), Medienverzeichnis (`MEDIA_ROOT`), Konfiguration (`config.env`, benutzerdef. OCR-Modelle), Export/Consume-Verzeichnisse?
  • [ ] Backup-Methode gewählt: pg_dump + rsync/tar, Filesystem-Snapshots, Container-Methode, Dediziertes Tool (Borg etc.)?
  • [ ] Konsistenz gesichert: Wie wird sichergestellt, dass DB-Dump und Medienverzeichnis zusammenpassen? (Reihenfolge, ggf. Snapshot/Pausieren)?
  • [ ] Automatisierung: Cron-Job / Systemd-Timer eingerichtet?
  • [ ] Sicherheit: Backups verschlüsselt (At-Rest)? Sichere Übertragung (SSH/HTTPS)? Strenge Zugriffskontrollen?
  • [ ] 3-2-1 Regel: Mind. 3 Kopien, 2 Medien, 1 extern? (Lokal, NAS/anderer Server, Cloud/Ext. Festplatte)
  • [ ] Monitoring: Erfolg der Jobs wird überwacht? Backup-Dateien werden auf „Frische“ geprüft? Speicherplatz am Ziel wird überwacht?
  • [ ] Retention: Automatisierte Löschung alter Backups eingerichtet? (z.B. `find`, `borg prune`)
  • [ ] Wiederherstellung dokumentiert & getestet: Klare Anleitung vorhanden? Regelmäßiger Test (mind. quartalsweise) auf isoliertem System durchgeführt und dokumentiert? Letzter Test erfolgreich?
  • [ ] Konfiguration gesichert: `docker-compose.yml`, `.env`/`config.env`, Systemd-Servicefiles, Cron-Job-Definitionen?

Schlussgedanke: Backups sind kein Kostenfaktor, sondern eine Versicherung

Die Einführung von Paperless-ngx ist eine Investition in Effizienz und Übersicht. Die Investition in solide Backups ist eine Investition in die langfristige Sicherheit dieser wertvollen betrieblichen Erinnerung. Der Aufwand erscheint manchmal lästig, die Kosten für Storage spürbar. Doch verglichen mit dem finanziellen und operativen Schaden eines kompletten Dokumentenverlusts – sei es durch Hardwareversagen, menschliches Versagen, Softwarefehler oder Cyberangriffe – sind sie verschwindend gering. Es ist wie mit einer Feuerversicherung: Man hofft, sie nie zu brauchen, aber wenn es brennt, ist man unendlich froh, sie zu haben. Fangen Sie nicht nach dem Daten-GAU an, Ihre Backup-Strategie zu überdenken. Tun Sie es jetzt. Ihr zukünftiges Ich wird es Ihnen danken.