Warum ein normales Backup für Paperless-ngx nicht reicht

Warum Kopieren allein nicht reicht

Ein einfaches Dateibackup kann bei Paperless-ngx unvollständig sein, wenn es im laufenden Betrieb Datenbankdateien, temporäre OCR-Dateien oder halbfertige Importzustände erwischt. Das Problem ist nicht der einzelne PDF-Scan, sondern die Verbindung aus Dokument, Datenbankeintrag, Metadaten und Volltext.

Deshalb wird das Backup nicht als einzelner Kopiervorgang verstanden, sondern als Betriebsprozess. Es muss klären, was gesichert wird, in welchem Zustand die Datenbank ist, wohin die Sicherung geht und ob eine Wiederherstellung wirklich funktioniert.

Säule 1: Document Exporter

Paperless-ngx bringt einen eigenen document_exporter mit. Die offizielle Dokumentation beschreibt ihn als Werkzeug, um Daten aus Paperless in einen Ordner zu exportieren, etwa für Backup oder Migration. Damit entsteht eine lesbare, Paperless-nahe Sicherungsebene.

cd /opt/paperless
docker compose exec -T webserver document_exporter ../export

Der Exporter ist keine Entschuldigung, auf das normale Backup zu verzichten. Er ist die zusätzliche Lebensversicherung: Wenn die aktive Instanz oder die Datenbank beschädigt wäre, bleibt ein strukturierter Export als Migrations- und Kontrollbestand erhalten.

Säule 2: konsistenter Datenbank-Snapshot

Viele allgemeine Paperless-ngx-Anleitungen verwenden PostgreSQL und sichern die Datenbank mit pg_dump. Das ist richtig, wenn die eigene Installation PostgreSQL nutzt. Meine dokumentierte Umgebung arbeitet jedoch mit SQLite im WAL-Modus. Deshalb gehört hier kein PostgreSQL-Dump ins Betriebskonzept, sondern ein konsistenter SQLite-Snapshot.

sqlite3 db.sqlite3 ".backup db_consistent.sqlite3"

Dieser Snapshot wird anstelle einer live kopierten Datenbankdatei gesichert. WAL- und SHM-Dateien werden nicht als führender Wiederherstellungsbestand betrachtet; sie entstehen nach dem Restore wieder neu.

Säule 3: BorgBackup und Offsite-Kopie

Die dritte Ebene ist die eigentliche Sicherungslogik außerhalb der Paperless-Anwendung. In meinem Aufbau werden Konfiguration und Datenbasis gesichert:

/opt/paperless
/Daten/paperless-data

BorgBackup eignet sich hier gut, weil es versionierte, platzsparende und prüfbare Sicherungen ermöglicht. Wichtig ist aber nicht der Name des Werkzeugs, sondern das Prinzip: Es braucht mindestens eine Kopie außerhalb des Servers, idealerweise auf NAS, externem Datenträger oder verschlüsseltem Offsite-Ziel.

• lokale Betriebsdaten auf dem Server
• versioniertes Backup auf separatem Speicher
• zusätzliche Offsite-Kopie für Brand, Diebstahl oder Hardwaredefekt

Restore-Test als Pflicht

Der wichtigste Teil eines Backups ist nicht der erfolgreiche Lauf des Backup-Skripts, sondern der erfolgreiche Restore. Nach einer Wiederherstellung müssen mindestens vier Dinge geprüft werden:

• Container starten sauber.
• Dokumente lassen sich öffnen und herunterladen.
• Suche und Metadaten funktionieren.
• Ein Testdokument kann importiert werden.

Erst dann ist das Backup mehr als ein gutes Gefühl. Es ist ein belastbarer Schutz für das Dokumentenarchiv.

Zurück zur Paperless-Betriebsumgebung

Das richtige Backup für Paperless-ngx kombiniert mehrere Ebenen: Exporter für Lesbarkeit und Migration, konsistente Datenbank-Sicherung für den Systemzustand, BorgBackup für Versionierung und eine Offsite-Kopie für echte Ausfallszenarien.