Paperless in Proxmox-LXC während Update abgeraucht - was nun?

[MJAS]

Hallo zusammen,

ich hab ein Problem.
Mein Paperless-NGX 2.15.3 läuft in einem LXC-Container unter Proxmox.
Jetzt hatte ich heute 626 Dokumente „konsumieren“ lassen und mich geärgert, dass irgendwie jedes Dokument x-Mal in den Dateiaufgaben unter „Fehlgeschlagen“ gelandet sind (cannot consume, file not found), obwohl sie in Paperless aufrufbar waren.
In meinem Ärger hab ich gesehen, dass unten stand, dass eine neue Version 2.16.1 verfügbar ist.

Also, Update gestartet, dann aber den Rechner laufen und stehen lassen müssen.
Das läuft in meinem Fall über das Proxmox Helper-Script.

Jetzt heut abend dann wieder an den Rechner gekommen und das Drama nahm seinen Lauf.
Das Update hatte mit einer Fehlermeldung abgebrochen.
Ich dachte zuerst, dass es wegen zu geringen Plattenplatzes war, aber das war ein Fehler.

Mein letztes Backup ist von Sonntag, 18.05.2025.
Ich hatte mit Paperless erst vor ca. 2 Wochen angefangen.
Darin hab ich 208 Dokumente enthalten.

Jetzt kommt der nächste Fehler: ich hab das Backup zurück gespielt und vom fehlerhaften Stand kein zusätzliches Backup gemacht.

Mit den 626 heute verarbeiteten Dokumenten hatte ich 871 Dokumente.
Mit dem eingespielten Backup hab ich also 208 Dokumente, mit den 626 weiteren komm ich auf 834.
Fehlen mir 37 Dokumente.

Jetzt ist es aber so, dass mein Media-Verzeichnis auf meiner Synology liegen, also mit 871 Dokumenten, die ich aber durch das zurück gespielte Backup nicht aufrufen kann, weil das Backup sie ja noch nicht kennt.

Was kann ich jetzt machen?
Bräuchte bitte nen rettenden konstruktiven Denkanstoss!

Herzlichen Dank schonmal im voraus,
Gruß
Martin

[olethomsen]

Moin ! Zunächst würde ich mal alle Dokumente aus dem Media Ordner kopieren und an einem sicheren Ort aufbewahren. Damit hast Du alle Dokumente schon mal „safe“.
Der Stand der Paperless Datenbanl passt ja ohnehin nicht mehr zu allen Dokumenten und von daher würde ich das Paperless löschen und neuaufsetzen. Danach die gesicherten Dokumente in den Consume Ordner kopieren und Paperless alles neu einlesen lassen. Nachteil ist dass Du ggf. manuell Korrespondenten, Speicherpfad, etc. anpassen musst. Das kannst Du durch geschicktes „nach und nach“ -Verarbeiten der gesicherten Dokumente, z.B. von denen Du weisst, sie sind von immer demselben Korrespondenten oder so etwas abkürzen.
Das geht eigentlich in Anbetracht der „Katastrophe“ nochj recht schnell, es sind eigentlich nicht wirklich viele Dokumente.
Was ich dann aber sichersetellen würde, ist, dass Dein Paperless LXC den Media Ordner von Deiner Synology nicht „verliert“.
Das hast Du nicht genau erklärt, wie Du diese Filesysteme mountest.
Ich habe einen ähnlichen Aufbau zu Hause am Laufen und lasse eine VM mit Paperless (Linux + Docker) laufen und mounte ein Filesystem aus einer TrueNAS Maschine per „autofs“ → nicht fix gemountet per /etcfstab !
Autofs reconnected sich immer wieder neu, wenn es mal zu einer Netzwerkunterbrechung kommt.
Auf diese Weise funktioniert es sehr stabil.
Wenn Du hierfür mehr wissen möchtest, stelle ich gerne meine Config Files zur Verfügung. Vielleicht interesiert es auch andere hier oder es hat sogar noch jemand Verbesserungsvorschläge.
Ich sage nur schon mal vorraus, man braucht schon relativ fundiertes Wissen um das so zu machen.
Ich hoffe, Dir schon mal eine gedankliche bzw. konstruktive Richtung gegeben zu haben.
Viele Grüße, Ole,

[MJAS]

Danke @olethomsen !
Werd ich so machen.

Wäre ja eigentlich nen Feature-Request wert, dann man die komplette Konfig (Korrespondenten, Tags, Speicherpfade etc.) sichern und wiederherstellen könnte.
Auch eine Repair-Funktion wäre eigentlich super für genau solche Fälle.
Die im Admin vorhandenen Gesundheits-Checks hatten irgendwie die Hoffnung in die Richtung geweckt - ist aber nicht so.

Ich hab in meiner Konfiguration die Verzeichnisse „consume“ und „media“ auf meiner Synology liegen.
Die beiden Verzeichnisse werden in Proxmox einfach über die fstab gemountet.
Als System in meinen LXC-Containern verwende ich Debian 12.
Erzähl mal mehr über Deine Konfig bei autofs, ich find die Idee auf jeden Fall sehr interessant, was Du bisher geschrieben hattest.

Danke und Gruß
Martin

[olethomsen]

Moin !

Kommentiere den oder die Pfade der Synology mal aus in der /etc/fstab.
Du musst dann autofs per apt installieren.
In meiner docker-compose.yml für Paperless habe ich dies für meine Volumes stehen (links der Pfad auf Deinem Host:rechts der des Docker-Containers):
volumes:
- /home/paperless/paperless-ngx/data:/usr/src/paperless/data:bind
- /Volumes/paperless/media:/usr/src/paperless/media:bind
- /Volumes/paperless/export:/usr/src/paperless/export:bind
- /home/paperless/paperless-ngx/consume:/usr/src/paperless/consume:bind
- /home/paperless/paperless-ngx/scripts:/usr/src/paperless/scripts:bind
env_file: docker-compose.env

/home/paperless … ist der Ort meines Docker Containers wo die Postgres DB auch läuft und den Stand aller Dokumente und Eigenschaften speicht, also lokal, bei Dir der LXC.

Deine /etc/auto.master sollte so aussehen, wichtig ist, das „+dir:/etc/auto.master.d“ ohne # davor !
#
# Sample auto.master file
# This is a ‚master‘ automounter map and it has the following format:
# mount-point [map-type[,format]:]map [options]
# For details of the format look at auto.master(5).
#
#/misc /etc/auto.misc
#
# NOTE: mounts done from a hosts map will be mounted with the
# „nosuid“ and „nodev“ options unless the „suid“ and „dev“
# options are explicitly given.
#
#/net -hosts
#
# Include /etc/auto.master.d/*.autofs
# The included files must conform to the format of this file.
#
+dir:/etc/auto.master.d
#
# Include central master map if it can be found using
# nsswitch sources.
#
v# Note that if there are entries for /net or /misc (as
# above) in the included master map any keys that are the
# same will not be seen as the first read key seen takes
# precedence.
#
+auto.master

In dem Ordner „/etc/auto.master.d“ legst Du zwei Files ab:

paperless:/etc/auto.master.d # cat auto.cifs.dms
# CIFS-Share im Linux einhaengen
/Volumes/paperless/media -fstype=cifs,credentials=/root/.cred.cifs.dms,file_mode=0666,dir_mode=0777,uid=1001,gid=100 ://server/public/DMS/media
/Volumes/paperless/export -fstype=cifs,credentials=/root/.cred.cifs.dms,file_mode=0666,dir_mode=0777,uid=1001,gid=100 ://server/public/DMS/export

paperless:/etc/auto.master.d # cat dms.cifs.autofs
# CIFS mount des Share
/- /etc/auto.master.d/auto.cifs.dms --ghost --timeout=0

Das /- veranlasst den Automounter das /die Verzeichnis(se) anzulegen und den oder die Pfade aus der auto.cifs.dms dorthin zu mounten.

Den Timeoutwert habe ich auf 0 gestellt, damit nicht umountet wird um Bandbreite zu sparen, kannst Du aber einstellen wie Du möchtest.
Der Automounter moutet die Netzwerkshare unter allen Umständen immer wieder, sobald ein Zugriff auf das Filesystem erfolgt. Sollte also Dein NAS mal rebooten musst Du nicht danach im LXC die Files neu mounten oder weil sie „stall“ sind aufwändig per umount -fl und anschließendem neu mounten wieder einhängen, sondern autofs sorgt automatisch dafür.

Ein Tipp noch, autofs kann sehr nervig sein, falls man einen Tippfehler irgendwo hat, dann gibt es blöde Fehlermeldungen, aber es loht sich am Ende.

Die Pfade kannst Du natürlich benennen wie Du möchtest.
Ich persönlich habe mir den automounter für Netzwerkpfade komplett angewöhnt, ich möchte das nicht mehr anders.
Ich hoffe, es bringt Dich weiter, viel Erfolg und happy restoring !
Viele Grüße, Ole

[Stefan]

@MJAS

Wäre ja eigentlich nen Feature-Request wert, dann man die komplette Konfig (Korrespondenten, Tags, Speicherpfade etc.) sichern und wiederherstellen könnte.

Das gibt es bereits Nennt sich document_exporter. Auch wenn der Name suggeriert, er würde nur die Dokumente exportieren, macht er im Grunde ein json aus der Datenbank und exportiert auch die Dokumente noch mit.
Der einzige Grund, warum der document_exporter nicht die Standard-Backup-Lösung in der Masterclass geworden ist, ist die Tatsache, dass er das Backup abbricht, sofern es Inkonsistenzen mit den Media-Files gibt (z.B. ein verschobenes File => kompletter Abbruch).

[Thomas241]

@Stefan

Der einzige Grund, warum der document_exporter nicht die Standard-Backup-Lösung in der Masterclass geworden ist, ist die Tatsache, dass er das Backup abbricht, sofern es Inkonsistenzen mit den Media-Files gibt (z.B. ein verschobenes File => kompletter Abbruch).

Der Exporter ist wenn überhaupt nur eine Notlösung, da er die komplette DB in einer JSON Datei speichert, dies kann neben der Dateigröße schon allein wegen des Encodings nicht reparierbare Probleme erzeugen.

[olethomsen]

Moin !
Ergänzend dazu fällt mir gerade ein, meine Freigaben für das Archiv habe ich so berechtigt, dass nur Paperless drauf lesen UND schreiben kann. Normale Benutzer können auf das Archiv nur lesend zugreifen. Dadurch wird das versehentliche verschieben oder löschen von Dateien im Archiv, die dann mit dem Datenbankstand nicht mehr übereinstimmen, verhindert.
Bei TrueNAS kann man ACLs setzen, das macht die Sache einfach(er). Paperless hat einen eigenen technischen Benutzer für seine Zugriffe. Das noch mal zur Anregung dazu …
VG, Ole