Paperless-ngx Backup-Script

Tommes · December 18, 2025 at 7:47 PM

Hi!

Ich habe die Filebase um ein weiteres Shell-Skript erweitert…

File

Paperless-ngx Backup-Script

Export und anschließende Sicherung von Datenbankinhalten, Metadaten, Benutzerprofilen, Einstellungen usw. von Paperless-ngx

Tommes

May 5, 2026 at 5:35 PM

…und möchte euch hier eine Plattform zur Diskussion anbieten.

Tommes · December 20, 2025 at 8:05 AM

Hi!

Nach Rücksprache mit Mike0185 und Willi kopiere ich den bisherigen Kommentarverlauf aus der Filebase hierher, da er Bereich „Kommentare” eher dafür gedacht ist, Feedback zu sammeln, und nicht, um Support zu leisten.

Quote from Rennie61

Funktioniert leider nicht. Als Ausgabe kommt lediglich:
---------------------------------------------------------------------------------------------------------
Paperless-ngx Datensicherungsprotokoll vom 19.12.2025 um 10:25:14 Uhr
- Datensicherungsziel: /volume1/docker/backups/paperlessngxbackup
---------------------------------------------------------------------------------------------------------
Die integrierte Exportfunktion von Paperless-ngx wird ausgeführt....
read /volume1/docker: is a directory
root@DXP4800PLUS:/volume1/docker#

Display More

Quote from Tommes

Welchen Pfad hast du denn für paperless_dir eingesetzt?
Hast du in deinem Paperless Verzeichnis ein Unterverzeichnis mit dem Namen export?

Quote from Rennie61

Unterverzeichnis export ist vorhanden. Der Pfad für paperless_dir lautet: paperless_dir="/volume1/docker/paperlessngx

Ich habe versucht, die von dir beschriebene Fehlermeldung bei mir irgendwie zu provozieren, jedoch ohne Erfolg. Daher bin ich im Moment etwas ratlos. Es muss aber irgendwie mit dem Aufruf bzw. der Ausführung des document_exporter zusammenhängen, da das Skript an dieser Stelle abbricht. Vielleicht versuchst du einmal, den Befehl direkt auf der Kommandozeile auszuführen, um zu schauen, ob es dann funktioniert. Prüfe vor der Ausführung bitte, ob der Pfad zur YAML-Datei /volume1/docker/paperlessngx/docker-compose.yaml sowie der Servicename von Paperless-ngx webserver deinen Gegebenheiten entsprechen, ansonsten pass diese bitte an. Du kannst den Aufruf auf 2 Arten durchführen.

Wenn du dich auf der Kommandozeile nicht im Paperless-ngx Verzeichnis befindest

Code

sudo docker compose -f "/volume1/docker/paperlessngx/docker-compose.yaml" exec -T "webserver" document_exporter ../export -d

Wenn du dich auf der Kommandozeile im Paperless-ngx Verzeichnis befindest

Code

sudo docker compose exec -T "webserver" document_exporter ../export -d

Bestenfalls probierst du beide Befehle aus, evtl. auch einmal mit und ohne das Flag -d am Ende der Zeile.

BTW: Hast du Paperless-ngx über die UGOS-Pro Docker App eingerichtet, oder über Portainer?

Renni61 · December 20, 2025 at 3:41 PM

Hallo Tommes,

ich habe Paperless über Portainer eingerichtet. Insofern existiert weder eine separate "docker-compose.yaml", noch ein ".env-file".

Nachfolgend die Konfiguration aus dem Portainer-Editor: (die sicherheitsrelevanten Einträge habe ich jeweils durch das #-Zeichen ersetzt)

Code

services:
    broker:
        container_name: paperlessngx-redis
        image: redis:8
        volumes:
            - /volume1/docker/paperlessngx/redis:/data     
        restart: unless-stopped
        user: "###:##"                                     
        sysctls:
            - net.core.somaxconn=511
        cap_add:
            - SYS_RESOURCE
        deploy:
            resources:
                limits:
                    memory: 256M
        healthcheck:
            test: ["CMD", "redis-cli", "ping"]
            interval: 30s
            timeout: 5s
            retries: 3
        labels:
            - com.centurylinklabs.watchtower.enable=false

    db:
        container_name: paperlessngx-db
        image: postgres:17
        restart: unless-stopped
        volumes:
            - /volume1/docker/paperlessngx/db:/var/lib/postgresql/data
        environment:
            POSTGRES_DB: paperless
            POSTGRES_USER: paperless
            POSTGRES_PASSWORD: ##############################
        deploy:
            resources:
                limits:
                    memory: 512M
        healthcheck:
            test: ["CMD", "pg_isready", "-U", "paperless"]
            interval: 30s
            timeout: 5s
            retries: 3
        logging:
            driver: "json-file"
            options:
                max-size: "10m"
                max-file: "5"
        labels:
            - com.centurylinklabs.watchtower.enable=false

    webserver:
        container_name: paperlessngx
        image: ghcr.io/paperless-ngx/paperless-ngx:2.15.3
        ports:
            - 8010:8000
        restart: unless-stopped
        depends_on:
            - db
            - broker
        healthcheck:
            test: ["CMD", "curl", "-f", "http://localhost:8000"]
            interval: 30s
            timeout: 10s
            retries: 5
        volumes:
            - /volume1/docker/paperlessngx/data:/usr/src/paperless/data       
            - /volume1/docker/paperlessngx/media:/usr/src/paperless/media
            - /volume1/docker/paperlessngx/export:/usr/src/paperless/export
            - /volume1/docker/paperlessngx/consume:/usr/src/paperless/consume
        environment:
            PAPERLESS_REDIS: redis://broker:6379
            PAPERLESS_DBHOST: db
            PAPERLESS_DBPASS: ##############################
            PUID: ###
            PGID: ##
            USERMAP_UID: ###
            USERMAP_GID: ##
            PAPERLESS_OCR_LANGUAGES: eng deu
            PAPERLESS_SECRET_KEY: #######...
            PAPERLESS_CSRF_TRUSTED_ORIGINS:http://###.###.#.###
            PAPERLESS_TIME_ZONE: Europe/Berlin
            PAPERLESS_OCR_LANGUAGE: deu+eng
            PAPERLESS_FILENAME_FORMAT: "{{ created_year }}/{{ correspondent }}/{{ title }}"
            PAPERLESS_TIKA_ENABLED: 1
            PAPERLESS_TIKA_GOTENBERG_ENDPOINT: http://gotenberg:3000/
            PAPERLESS_TIKA_ENDPOINT: http://tika:9998
            PAPERLESS_WORKER_TIMEOUT: 4000
            PAPERLESS_URL: "http://###.###.#.###"
        deploy:
            resources:
                limits:
                    memory: 2048M
        logging:
            driver: "json-file"
            options:
                max-size: "10m"
                max-file: "5"
        labels:
            - com.centurylinklabs.watchtower.enable=false

    db-backup:
        container_name: paperlessngx-db-backup
        image: postgres:17
        volumes:
            - /volume1/docker/paperlessngx/db-backup:/dump         
            - /etc/localtime:/etc/localtime:ro
        environment:
            PGHOST: db
            PGDATABASE: paperless
            PGUSER: paperless
            PGPASSWORD: ##############################
            BACKUP_NUM_KEEP: 10
            BACKUP_FREQUENCY: 60m
        entrypoint: |
            bash -c 'bash -s <<EOF
            trap "break;exit" SIGHUP SIGINT SIGTERM
            sleep 2m
            while /bin/true; do
              pg_dump -Fc > /dump/dump_\`date +%d-%m-%Y"_"%H_%M_%S\`.psql
              (ls -t /dump/dump*.psql|head -n $$BACKUP_NUM_KEEP;ls /dump/dump*.psql)|sort|uniq -u|xargs rm -- {}
              sleep $$BACKUP_FREQUENCY
            done
            EOF'
        deploy:
            resources:
                limits:
                    memory: 256M
        labels:
            - com.centurylinklabs.watchtower.enable=false

    gotenberg:
        container_name: paperlessngx-gotenberg
        image: gotenberg/gotenberg:8
        restart: unless-stopped
        environment:
            CHROMIUM_DISABLE_ROUTES: 1
        command:
            - "gotenberg"
            - "--chromium-disable-javascript=true"
            - "--chromium-allow-list=file:///tmp/.*"
        deploy:
            resources:
                limits:
                    memory: 512M
        healthcheck:
            test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
            interval: 30s
            timeout: 5s
            retries: 3
        labels:
            - com.centurylinklabs.watchtower.enable=false        

    tika:
        container_name: paperlessngx-tika
        image: apache/tika:2.9.2.1
        restart: unless-stopped
        deploy:
            resources:
                limits:
                    memory: 512M
        labels:
            - com.centurylinklabs.watchtower.enable=false

Display More

Tommes · December 20, 2025 at 5:36 PM

Ja. Okay. Mein Fehler. Ich bin in meinem Skript zunächst davon ausgegangen, das Paperless-ngx über die UGOS Pro Docker App eingerichtet wurde. In dem Fall wird nämlich eine docker-compose.yaml im Hauptverzeichnis von Paperless-ngx angelegt.

Portainer speichert die YAML-Datei bzw. den Stack irgendwo intern unter - so meine ich mich zu erinnern - irgendeiner ID. Somit kann mein Skript zunächst einmal nicht funktionieren, versuche die Tage aber eine Lösung zu erarbeiten. Vermutlich wird das am Ende so aussehen, das ich innerhalb des Skripts zunächst in das entsprechende Paperless-ngx Verzeichnis Wechsel um im Anschluss daran den document_exporter auszuführen. Daher würde ich dich bitten, mir etwas Zeit zu geben um das grade zu ziehen, in der Hoffnung, das du das bei dir nochmal testen würdest. Das wäre toll.

Was bei dir aber definitiv funktionieren sollte ist dieser Befehl…

Code

sudo docker compose exec -T "webserver" document_exporter ../export

… wo ich dich bereits gebeten hatte, diesen mal zu testen. Dazu wechselst du auf der Kommandozeile mit cd /volume1/docker/paperlessngx in dein Paperless-ngx Verzeichnis und führst den Befehl aus.

Ich meld mich, sobald ich ich etwas vorzuweisen habe.

Renni61 · December 20, 2025 at 9:09 PM

Mach Dir keinen Stress! Alles okay!

Code

sudo docker compose exec -T "webserver" document_exporter ../export

funktioniert nicht.

Code

docker exec paperlessngx document_exporter ../export

funktioniert!

Tommes · December 21, 2025 at 9:47 AM

Moin!

Ich habe folgende Änderungen vorgenommen und eine neue Version auf GitHub bereitgestellt

File

Paperless-ngx Backup-Script

Export und anschließende Sicherung von Datenbankinhalten, Metadaten, Benutzerprofilen, Einstellungen usw. von Paperless-ngx

Tommes

May 5, 2026 at 5:35 PM

Version 1.0-100 vom 21.12.2025

Die Variablen username, groupname, paperless_service und postgresql_service wurden entfernt.
Die Variablen für optionale, benutzerspezifische Angaben wurden angepasst.
Um im Nachgang die Verzeichnis- und Dateirechte im Datensicherungsziel anzupassen, wurde die Ermittlung von Benutzer und Gruppe automatisiert.
Um sicherzustellen, dass die Befehle document_exporter und pg_dump innerhalb des Paperless-ngx-Verzeichnis ausgeführt werden, wurde ein automatischer Verzeichniswechsel implementiert.
Die Syntax der Befehle document_exporter und pg_dump wurden angepasst.

Ich hoffe, das das Skript bei dir jetzt funktioniert Renni61 und wünsche dir weiterhin viel Spaß damit.

Tommes

Renni61 · December 21, 2025 at 1:30 PM

Hallo Tommes,

das Script funktioniert jetzt einwandfrei.

PERFEKT! KLASSE!

Vielen lieben DANK für Deine Arbeit und den SUPER-SUPPORT!

VG

Jörg

Brumbus · December 31, 2025 at 8:32 PM

Hallo Tommes,

also ich kann an dieser Stelle nur den Hut ziehen! - das hast Du richtig geil gemacht.

Ich habe das Script nach der Entfernung meines alten Scriptes (was länger gedauert hat, als das neue einzubauen :-D) direkt auf die Platte gezogen. - der Testlauf ist sauber durchgelaufen (Mein Backup-Ziel ist eine externe Festplatte, die an die Ugreen angeflanscht ist).

Wenn ich denn dieses Szenario hätte: NAS ist abgeraucht, und Paperless ist frisch installiert und ich möchte meine Daten von der USB-Platte zurückholen, würde ich wie folgt vorgehen wollen:

Daten bereitstellen: Ich Kopiere den Inhalt des Ordners export von meiner USB-Platte in den export-Ordner der neuen Paperless-Installation auf dem NAS.
Und führe dann diese Befehle aus:
cd /volume1/docker/paperless-ngx
sudo docker compose exec webserver document_importer ../export

Und wenn ich jetzt keinen Denkfehler gemacht habe, müsste es doch dann wieder alles hübsch sein, oder?

Beste Grüße aus Hamburg und einen Guten Rutsch!

Stefan

Tommes · January 1, 2026 at 8:49 AM

Vielen Dank für deine lobenden Worte 🤗

Quote from Brumbus

Und wenn ich jetzt keinen Denkfehler gemacht habe, müsste es doch dann wieder alles hübsch sein, oder?

Theoretisch ja. Praktisch habe ich noch nie einen Import über den document_importer ausgeführt. Einzig den Inhalt der PostgreSQL-Datenbank habe ich beim Update von PostgreSQL 17 auf 18 gesichert und zurückgespielt, so wie ich es hier beschrieben habe. Die Dokumente blieben bei diesem Update unberührt.

Wenn ich irgendwann einmal Lust und Zeit habe, werde ich das Worst-Case-Szenario durchspielen, um zu sehen, ob alles so funktioniert, wie man es sich vorstellt. Momentan steht mir aber nicht der Sinn danach.

mscbs · January 2, 2026 at 11:13 AM

Super Arbeit, Tommes.

Nur als Hinweis: wenn man die Paperless-Instanz über den document_importer wiederherstellt (habe ich bereits mehrfach gemacht, wenn die Instanz umgezogen ist), dann ist es wichtig, dass die neue Instanz leer ist, also noch keine Benutzer angelegt sind usw. Mit der Import-Funktion wird wirklich alles so wiederhergestellt, wie es vorher war.

Wäre es noch möglich, eine Versionierung mit einzubauen, also dass man z.B. als Variable angibt, wie lange man die Backups vorhalten möchte und den Export-Ordner noch zu packen (.zip oder .tgz)?

Moment sichere ich persönlich den Export-Ordner täglich per Script mit restic auf die Hetzner Storagebox, da habe ich 7 tägliche, 4 wöchentliche, 12 monatliche und 5 jährliche Versionen eingerichtet. Restic verschlüsselt ja automatisch, so dass meine Dateien nicht lesbar auf der Storagebox liegen, falls sich mal jemand Zugriff auf die Storagebox verschafft.

Wobei ich zugeben muss, dass mein Paperless auf einem Raspberry 5 läuft, lediglich die Backups gehen auf das NAS und parallel in die Storagebox. Da aber auf der Ugreen restic bereits vorhanden ist, kann man das auch auf der Ugreen per restic sichern.

Tommes · January 2, 2026 at 12:04 PM

Interessanter Hinweis, das mit dem document_importer und dem Benutzer. Das muss ich mir gleich mal irgendwo hin schreiben.

Was die Versionierung angeht, so lässt sich das sicherlich ins Skript einbinden. Ich habe das aber bewusst weggelassen, da ich nach einem Supergau i.d.R. den aktuellsten Stand wiederherstellen möchte. Außerdem sicher ich sowieso immer alles versioniert mit Sync & Backup oder aber mit meinem rsync-Skript jarss, auf ein weiteres Remote-NAS.

Ich würde, wenn überhaupt, über das Skript das komplette Backupset von Paperless-ngx, am Ende der Sicherung in eine gepackte Datei, benannt nach Datum und Uhrzeit der Sicherung erstellen, da bei einem Restore alles zusammenpassen muss, sollte man eben dem document_importer auch noch den Datenbank Dump zurückspielen wollen.

Ich denk mal drüber nach, ob ich sowas noch einbauen möchte. Selber nutzen würde ich es wohl nicht. Aber gut…

Tommes · January 2, 2026 at 9:07 PM

Ich habe folgende Änderungen vorgenommen und eine neue Version auf GitHub bereitgestellt

File

Paperless-ngx Backup-Script

Export und anschließende Sicherung von Datenbankinhalten, Metadaten, Benutzerprofilen, Einstellungen usw. von Paperless-ngx

Tommes

May 5, 2026 at 5:35 PM

Version 1.0-200 vom 02.01.2026

Im Abschnitt "Verbindliche, benutzerspezifische Angaben" des Skriptes, wurde die Variable version_history hinzugefügt.
Im Abschnitt "Optionale, benutzerspezifische Angaben" des Skriptes, wurde die Variable tarfolder hinzugefügt.
Nachdem alle Sicherungen durchgeführt wurden, wird bei Bedarf eine gepackte .tgz-Archivdatei, benannt nach dem aktuellen Datum und der Uhrzeit im Unterverzeichnis tarfolder des Datensicherungsziels abgelegt.
Ältere Archivdateien bzw. Versionsstände werden aus dem Unterverzeichnis gelöscht, sobald eine angegebene Zeit in Tagen version_history überschritten wurde.

Ich hoffe, du kannst damit etwas anfangen mscbs und genügt deinen Anforderungen.

Weitere Info

Die im Abschnitt "Verbindliche, benutzerspezifische Angaben" des Skriptes, neu hinzugekommen Variable version_history enthält als Wert standardmäßig eine 0. In diesem Fall wird weder ein weiteres Unterverzeichnis, noch eine gepackte .tgz-Archivdatei erstellt. Wird ein numerischer Wert größer 0 angegeben, wird eine gepackte .tgz-Archivdatei, benannt nach dem aktuellen Datum und der Uhrzeit, im Unterverzeichnis des Datensicherungsziels abgelegt. (Standardmäßig lautet das Unterverzeichnis /history)

Anschließend wird überprüft, ob es Archivdateien gibt, die älter als der oben angegebene Wert in Tagen sind. Ist das der Fall, werden sie gelöscht.

Hinweis

Ich habe das bei mir zwar bereits ausgiebig getestet, aber je mehr Leute das gegenchecken, um so besser. Daher ist konstruktives Feedback auf jeden Fall erwünscht.

Bis dahin wünsche euch weiterhin viel Spaß mit dem Skript.

mscbs · January 3, 2026 at 5:37 PM

Danke dir für deine Bemühungen. Ich teste das ganze mal aus.

Tommes · April 18, 2026 at 6:17 PM

Tach auch!

Ich hatte mal wieder zu viel Zeit und zu viele Ideen, weshalb ich das Paperless-ngx-Backup-Skript nochmal komplett umgebaut und neu ausgerichtet habe. Ich hoffe, das euch das Ergebnis gefällt. Hier die Änderungen…

Version 1.0-400 vom 18.04.2026

Das Skript wurde komplett überarbeitet.
Alle verbindlichen, benutzerspezifischen Angaben bzw. Variablen müssen daher neu festgelegt werden.
Alle optionalen, benutzerspezifische Angaben bzw. Variablen wurden vollständig entfernt.
Docker-Container werden primär über ihren Servicenamen identifiziert und angesprochen, alternativ über den Containernamen oder die Container-ID.
Welche Docker-Befehle verwendet werden, hängt davon ab, wie ein Docker-Container identifiziert wurde.
- Bei Angabe des Servicenamens wird [ docker compose exec -T ] verwendet.
- Bei Angabe des Containernamen bzw. der Container-ID wird [ docker exec -T ] verwendet.
- Werden sowohl Servicename als auch Containername bzw. Container-ID angegeben, wird der Servicename und damit [ docker compose exec -T ] bevorzugt verwendet.
- Der Benutzer kann somit den zu verwendenden Docker-Befehl beeinflussen, indem er entweder den Servicenamen oder den Containernamen bzw. die Container-ID angibt.
- Damit TTY-Fehler in automatisierten, nicht-interaktiven Aufrufen verhindert werden, wurde den Docker-Befehlen das -T Flag hinzugefügt.
Dem Paperless-Export-Aufruf wurde das Flag -b hinzugefügt, um alle Dateien aus dem Exportverzeichnis zu löschen, die in Paperless-ngx nicht mehr vorhanden sind.
Dem Paperless-Export-Aufruf wurde das Flag -p hinzugefügt, um die exportierten Dateien in die entsprechenden Unterordner /archive, /originals und /thumbnails einzusortieren.
Dem Paperless-Export-Aufruf wurde das Flag -z hinzugefügt, um die exportieren Dateien in einer ZIP-Datei nach der Syntax export-YYYY-MM-DD.zip zu archivieren.
Das Skript durchsucht das Wurzelverzeichnis des Docker-Projekt-Verzeichnisses von Paperless-ngx nach allen Dateien mit den Endungen .yaml und .env und sichert sie.
Wird eine Datensicherung mit Versionsständen verwendet, werden im Datensicherungsziel Versionsordner im Format "YYYY-MM-DDTHH-MM-SS" angelegt.
Versionsordner werden nach Ablauf einer vom Benutzer festgelegten Zeit in Tagen automatisch aus dem Datensicherungsziel gelöscht.
Das Datensicherungsprotokoll wird immer im eigentlichen Wurzelverzeichnis des Datensicherungsziels abgelegt und bei jedem neuen Durchlauf überschrieben.
Weitere Stilverbesserungen und Codeoptimierungen vorgenommen.

File

Paperless-ngx Backup-Script

Export und anschließende Sicherung von Datenbankinhalten, Metadaten, Benutzerprofilen, Einstellungen usw. von Paperless-ngx

Tommes

May 5, 2026 at 5:35 PM

Hinweis

Ich habe das bei mir zwar bereits ausgiebig getestet, aber je mehr Leute das gegenchecken, um so besser. Daher ist konstruktives Feedback auf jeden Fall erwünscht.

Bis dahin wünsche euch weiterhin viel Spaß mit dem Skript.

HauptStrasseEins · April 20, 2026 at 4:10 AM

reciht es nicht aus, einfach den Docker Ordner auf ein anderes NAS zu syncen? Das doch ne sehr gute Koppie. Und bei größeren Updates, amch ich aus dem Ordner vorher noch ein Zip, bevor ich update, das bewahre ich auch erstmal auf. Welchen Vorteil hat für mich solch ein Script? (Wertschätzend gefragt)

Tommes · April 20, 2026 at 7:54 AM

Im Netz finden sich in der Tat unterschiedliche Meinungen und Aussagen zu diesem Thema, denen jeweils Vor- und Nachteile zugeordnet sind. Meine persönliche Empfehlung wäre daher - und genauso praktiziere ich es auch - eine Kombination aus allen Möglichkeiten. Einerseits die reine Sicherung des gesamten Paperless-ngx-Ordners mit z.B. Sync & Backup oder jarss und andererseits die Erstellung eines Datenbank-Dumps in Kombination mit dem von Paperless-ngx bereitgestellten document_exporter sowie der Sicherung der YAML- und ggf. ENV-Datei, so wie ich es in meinem Skript anbiete.

Am Ende geht es halt um nichts Geringeres als um persönlichen Daten, die niemand gerne verlieren möchte. Daher nutze ich alle Möglichkeiten, um einen Datenverlust zu verhindern und um den Aufwand für die Wiederherstellung so gering wie möglich zu halten.

BTW: Meine eigentliche Intention für die Überarbeitung dieses Skripts in der aktuellen Version 1.0-400 war, ein allgemeingültiges Skript zu erstellen, das sich gut auf andere Docker-Projekte übertragen lässt. Ich nutze dieses Skript beispielsweise auch in Kombination mit Sync & Backup bzw. jarss für meine Joplin-Server-Instanz. Dabei habe ich lediglich den Codebereich zur Ausführung des document_exporters herausgenommen.

FredvomJupiter · April 20, 2026 at 9:44 AM

Quote from HauptStrasseEins

reciht es nicht aus, einfach den Docker Ordner auf ein anderes NAS zu syncen? Das doch ne sehr gute Koppie. Und bei größeren Updates, amch ich aus dem Ordner vorher noch ein Zip, bevor ich update, das bewahre ich auch erstmal auf. Welchen Vorteil hat für mich solch ein Script? (Wertschätzend gefragt)

Das ist prinzipiell eine gute Einstellung um deine Daten / Instanz zu sichern.

Ich persönlich mache folgendes mit meinem Docker Verzeichnis.

Täglicher Snap um 5:00 Uhr, Anzahl 8, danach wird entsorgt. Die belegen aktuell 130 GB, aber den Preis zahle ich gerne.

Jeden Montag 01:00 Uhr werden alles Container per CronMaster gestoppt, 01:30 ist großen Sicherung zur heimischen BackupNAS und zu einer externen NAS, um 04:00 Uhr werden alle Container wieder per CronMaster gestartet.

Speziell Paperless, meine „Originals“ habe ich per Stack ausgelagert auf einen anderen Ordner „Tresor“, diese gehen also selbst bei einen Crash seitens Paperless niemals verloren. Die sind natürlich auch auf die schnelle „Menschenlesbar“, weil ich mit Speicherpfaden Mandant/Jahr/Monat arbeite.

buchling · April 23, 2026 at 8:47 AM

Quote from HauptStrasseEins

reciht es nicht aus, einfach den Docker Ordner auf ein anderes NAS zu syncen?

Den Ordner vollständig zu kopieren, ist sicher gut und im worst case hast du dadurch alle Dokumente im direkten Zugriff. Mit einer geeigneten Ordnerstruktur in der Ablage schon sehr viel Wert.

Die wichtige Frage ist wie bei jeder Form des Backups, ob du den Restore auch erfolgreich getestet hast. Ganz am Anfang habe ich mit diesem Vorgehen Schwierigkeiten gehabt und Paperless-NGX hat den vorhanden Ordner nicht erkannt sondern mit einer Neueinrichtung begonnen. Das war nicht schlimm, weil ich zu dem Zeitpunkt nur wenige Dokumente hatte. Aber ich verlasse mich auf diesen Prozess daher nicht mehr und mache regelmäßig den Export aus Paperless. Den kann ich jederzeit wieder importieren.

Aus meiner Sicht daher eine klare Empfehlung für ein solches Script.

Interceptor · May 4, 2026 at 12:19 PM

Hi,

ich bin gerade dabei mein neues NAS einzurichten und dabei auf deine tollen Skripte hier im Forum gestoßen. Ich betreibe ebenfalls Paperless via Portainer und hab festgestellt, dass sich in der aktuellen Version (1.0-400) leider der Fehler aus Beitrag #5 wieder eingeschlichen hat. Es betrifft beide Stellen für Dokumente-Export und Datenbank-Export.

Tommes · May 4, 2026 at 12:27 PM

Hi!

Ich habe in dem überarbeiteten Skript die Möglichkeit geschaffen, wahlweise mit docker compose exec -T oder mit docker exec -T zu arbeiten. Theoretisch sollte bei dir letzteres funktionieren. Lies dir hierzu nochmal den nachfolgenden Abschnitt aus den Releasnotes durch und schau, ob dir das weiterhilft.

Quote

Docker-Container werden primär über ihren Servicenamen identifiziert und angesprochen, alternativ über den Containernamen oder die Container-ID.
Welche Docker-Befehle verwendet werden, hängt davon ab, wie ein Docker-Container identifiziert wurde.
Bei Angabe des Servicenamens wird [ docker compose exec -T ] verwendet.
Bei Angabe des Containernamen bzw. der Container-ID wird [ docker exec -T ] verwendet.
Werden sowohl Servicename als auch Containername bzw. Container-ID angegeben, wird der Servicename und damit [ docker compose exec -T ] bevorzugt verwendet.
Der Benutzer kann somit den zu verwendenden Docker-Befehl beeinflussen, indem er entweder den Servicenamen oder den Containernamen bzw. die Container-ID angibt.

Paperless-ngx Backup-Script

Paperless-ngx Backup-Script

Paperless-ngx Backup-Script

Version 1.0-100 vom 21.12.2025

Paperless-ngx Backup-Script

Version 1.0-200 vom 02.01.2026

Weitere Info

Hinweis

Paperless-ngx Backup-Script

Participate now!

Tags