Paperless-ngx Paperless-ngx – DMS via Docker auf dem NAS

[Monacum]

Da ist trotzdem irgendwo bei mir noch der Wurm drin… Und selbst über das Protokoll finde ich aktuell noch nicht heraus, was.

Ports und Parameter alleine reichen nicht aus, wenn man eine neue Redis- und eine neue PostgreSQL-Instanz einrichtet (warum auch immer, ist nicht zwingend nötig), dann ist so wie ich das verstehe auch eine andere Benennung der Dependencies notwendig:

depends_on:
      - db
      - broker

muss dann werden zu

depends_on:
      - db2
      - broker2

in der zweiten yml.

Und nicht vergessen: In irgendeiner env muss noch PAPERLESS_COOKIE_PREFIX auftauchen mit einer Bezeichnung, damit die beiden Instanzen unterschiedliche Cookies setzen.

Ich habe da aber auch null Druck, dass jetzt zwingend umsetzen zu müssen. Im Zweifelsfalle kommt irgendwann der Support für mehrere Benutzer mit einem Update und bis dahin kann ich warten und nutze für andere Sachen synOCR.

 

[Verdi-Fan]

Dann gehöre ich vermutlich zu den wenigen Nasen, die das wirklich bräuchten und nicht hinbekommen. Erlaubt mir einen letzten Beitrag, um das ggf. zu beschleunigen oder jemanden dazu zu motivieren. Hintergrund: Ich habe wenig Ambitionen, mir für eine zweite Instanz extra ein zweites NAS zu kaufen.
Derjenige, der hier eine Anleitung liefert, mit der ich (und dann damit natürlich auch die wenigen anderen, die es u.U. interessiert) eine zweite oder dritte Paperless-NGX installieren kann (wie gesagt, eine Instanz läuft natürlich schon bei mir) kann entscheiden, ob ich dem Boardbetreiber oder alternativ einer wohltätigen Organisation (z.B. Tafeln e.V. usw.) seiner Wahl 50€ unter dem Stichwort Synology-Forum überweise. Dann bin ich happy und andere haben auch etwas davon. Überweisungsträger mit dem besagten Stichwort würde ich natürlich vorlegen ... Ich hoffe, das ist jetzt nicht zu unmoralisch.
Grüße
VF

 

[plang.pl]

Die zweite Instanz in einem VDSM zu betreiben, ginge auch. Da muss man nicht auf die andere Instanz des realen NAS achten

 

[Monacum]

@Verdi-Fan So wie ich mich kenne versuche ich das immer mal wieder und werde eine Lösung auch posten (so wie andere hier auch), wenn ich mal eine finde, aber ich kann Dir nicht versprechen, dass das zeitnah der Fall sein wird.

 

[kamikazeromeo]

Ich nutze auch seit kurzem paperless-ngx und finde es toill, das es eine mobile App dazu gibt, die keine Werbung hat. Habe vorher einige andere Scan-Apps getestet, entweder kosten die Geld oder können nicht auch externe Server speichern.
Bei mir wird das Backup per zfs-snapshot gemacht, ruck zuck ist der ganze Dockerordner (als Dataset) mit allen Containern gesichert, ohne das ich was anhalten muss. Dann kann man das in aller Ruhe hin kopieren, wo man möchte.
Übersicht über die Container hab ich mit Portainer und erstellen nur per docker-compose.yml, damit man die später auch bequem ändern oder verschieben kann. Auf goneuland.de gibt es tolle Anleitungen für Traefik, Portainer, Watchtower usw.

 

[Monacum]

Paperless-ngx v1.13.0​

Repository: paperless-ngx/paperless-ngx · Tag: v1.13.0 · Commit: 6c658a6 · Released by: github-actions[bot]

paperless-ngx 1.13.0​

Features​

• Feature: allow disable warn on close saved view with changes @shamoon (#2681)
• Feature: Add option to enable response compression @stumpylog (#2621)
• Feature: split documents on ASN barcode @muued (#2554)

Bug Fixes​

• Fix: Ignore path filtering didn't handle sub directories @stumpylog (#2674)
• Bugfix: Generation of secret key hangs during install script @stumpylog (#2657)
• Fix: Remove files produced by barcode splitting when completed @stumpylog (#2648)
• Fix: add missing storage path placeholders @shamoon (#2651)
• Fix long dropdown contents break document detail column view @shamoon (#2638)
• Fix: tags dropdown should stay closed when removing @shamoon (#2625)
• Bugfix: Configure scheduled tasks to expire after some time @stumpylog (#2614)
• Bugfix: Limit management list pagination maxSize to 5 @Kaaybi (#2618)
• Fix: Don't crash on bad ASNs during indexing @stumpylog (#2586)
• Fix: Prevent mktime OverflowError except in even more rare caes @stumpylog (#2574)
• Bugfix: Whoosh relative date queries weren't handling timezones @stumpylog (#2566)
• Fix importing files with non-ascii names @Kexogg (#2555)

Documentation​

• Chore: update recommended Gotenberg to 7.8, docs note possible utf8mb4 incompatibility @shamoon (#2608)
• [Documentation] Add v1.12.2 changelog @github-actions (#2553)

Maintenance​

• Chore: Faster Docker image cleanup @stumpylog (#2687)
• Chore: Remove duplicated static folder @stumpylog (#2561)
• Chore: Switch test coverage to Codecov @stumpylog (#2582)
• Bump docker/build-push-action from 3 to 4 @dependabot (#2576)
• Chore: Run tests which require convert in the CI @stumpylog (#2570)
• Chore: Remove Docker image extra Python installs @stumpylog (#2562)

Dependencies​

• Chore: batch update frontend packages 01.23 @dependabot (#2577)
• Bump docker/build-push-action from 3 to 4 @dependabot (#2576)

 

[Adama]

Watchtower hat 1.13.0 bereits heute Morgen schon installiert und bis jetzt konnte ich keine Auffälligkeiten feststellen.

Hab vorhin auch ein Dokument eingelesen, hat er wie gewohnt korrekt gemacht...

 

[chuck86]

@EDvonSchleck

Danke für deine ausführliche Hilfe! Ich habe mich an deinem Post orientiert und versucht ein backup meiner paperless Instanz zu erstellen.

Ich habe die docker-compose configuration verwendet um paperless in portainer zu installieren.

Testweise habe ich 3 Dokumente hochgeladen, dann das backup gemacht, danach habe ich 1 Datei gelöscht. Eine Wiederherstellung war mir leider nicht möglich. Die Datei fehlt.

myusername@ubuntu-tn:~$ sudo docker exec paperless-db-1 pg_dumpall -U paperless > /home/myusername/scriptest/pg_dumpall.dump
myusername@ubuntu-tn:~$ sudo rclone copy /var/lib/docker/volumes/paperless_media/ /mnt/remote/paperless-media
2023/02/19 14:12:28 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
myusername@ubuntu-tn:~$ sudo rclone copy /var/lib/docker/volumes/paperless_data/ /mnt/remote/paperless-data
2023/02/19 14:12:36 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
myusername@ubuntu-tn:~$ sudo rclone copy /mnt/remote/paperless-media/ /var/lib/docker/volumes/paperless_media/
[sudo] password for myusername:
2023/02/19 14:27:46 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
myusername@ubuntu-tn:~$ sudo rclone copy /mnt/remote/paperless-data/ /var/lib/docker/volumes/paperless_data/
2023/02/19 14:27:50 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
2023/02/19 14:27:50 NOTICE: _data/celerybeat-schedule.db: Removing partially written file on error: can't copy - source file is being updated (mod time changed from 2023-02-19 14:10:00.0462416 +0100 CET to 2023-02-19 14:27:50.8609268 +0100 CET)
2023/02/19 14:27:50 ERROR : _data/celerybeat-schedule.db: Failed to copy: can't copy - source file is being updated (mod time changed from 2023-02-19 14:10:00.0462416 +0100 CET to 2023-02-19 14:27:50.8609268 +0100 CET)
2023/02/19 14:27:50 ERROR : Attempt 1/3 failed with 1 errors and: can't copy - source file is being updated (mod time changed from 2023-02-19 14:10:00.0462416 +0100 CET to 2023-02-19 14:27:50.8609268 +0100 CET)
2023/02/19 14:27:50 ERROR : Attempt 2/3 succeeded
myusername@ubuntu-tn:~$ sudo rclone copy /mnt/remote/paperless-data/ /var/lib/docker/volumes/paperless_data/
2023/02/19 14:28:15 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
myusername@ubuntu-tn:~$ sudo docker exec -i paperless-db-1 psql -U paperless < /home/myusername/scriptest/pg_dumpall.dump

Anmerkungen ohne

-i

wurde die Datenbank nicht aktualisiert (geprüft, indem ich ein neues Backup gezogen habe und die Größe verglichen habe).

bash -c

hat immer gesagt file not found or directory unknown.
Warum speicher ich den dump nicht auch auf dem remote pfad? Da habe ich, warum auch immer, keine Berechtigung aus dem

 sudo docker exec

Befehl heraus, aber ich kann die Datei nachträglich ja verschieben.
Ich habe ebenfalls geprüft ob die Datei unter media existiert in /var/lib/docker/volumes/paperless_media/, tut sie.

Hättest du da ggf. eine Idee was ich falsch mache?

LG und schönen Sonntag noch!

 

[EDvonSchleck]

Liegt den ein *.dump-File in den Backupordner?

Die Befehle kannst du in den Aufgabenplaner direkt eingeben und regelmäßig ausführen, natürlich als "root". Lediglich den Containernamen musst du anpassen.

 

[chuck86]

Hallo,

danke für die schnelle Antwort!

Das ist ja das Kuriose. Ich habe ein paar Dokumente eingepflegt, das dump file ist dann 90kb groß.
Dann lösche ich ein Dokument und versuche auf den Ursprungszustand zurück zu kommen. Also geschaut, wie groß ist ein Dump der aktuellen Situation: 89 kb.
Dann das Back-up wieder hergestellt und nochmal geguckt in welcher Größenordnung ich nun das Backup vom Server zurück bekomme: 90 kb. Und dort ist das fehlende Dokument auch vermerkt.

Also im Prinzip scheint die DB aktualisiert, die Data und Media Ordner sind ebenfalls wiederhergestellt, aber irgendwo scheint paperless diese Informationen nicht übereinander zu bekommen.

Ich habe mich in der Zwischenzeit aber auch mit der document_exporter Funktion beschäftigt. Das lässt sich auch per crontab ausführen. Das hat auf Anhieb funktioniert.
Lediglich Schreiberechte aus dem Container heraus auf meinem remote Pfad zu erhalten war unmöglich. Aber eine zusätzliche Zeile

CP -r

bringt mich als cronjob nicht um

Es würde mich hier die Lösung natürlich aus reiner Neugier interessieren, aber da ich wahrscheinlich bei der exporter Lösung bleibe, wäre das jetzt nicht mehr kriegsentscheidend (mir ist klar, dass hier alle nur in ihrer Freizeit aktiv sind).

 

[EDvonSchleck]

Ich glaube, du verwechselst da etwas. Der Dump ist nur für die Datenbank und nicht für die lokalen Files. Beides muss gesichert werden! Ob der Dump funktioniert hat, kannst du sehen, wenn du eine neue leere Datenbank benutzt.

Für die Daten kannst du entweder den Ordner mit z.B. Hyperbackup sichern oder den Exporter in Paperless nutzen. Wenn du die Datenbank als File haben willst, nimm einfach SQLite und gut. Dann liegt alles in den Ordnern.

Der Exporter ist eher dafür gedacht, auf eine anderes DSM zu wechseln.

 

[chuck86]

Ich teste später Mal ob ich den dump auf einer anderen, leeren VM in der korrekten Version importieren kann.
Das heißt aber, dass ich in der laufenden Installation nicht auf den Dump wiederherstellen kann?
In meinem ersten Post siehst du, dass ich _media und _data ebenfalls kopiert und auch wiederhergestellt habe. Da ist ja einmal der komplette Prozess abgebildet. Ich habe mich auf die Datenbank in meiner Antwort spezialisiert, weil auf jeden Fall unter Media alles wieder da war, aber paperless das eben in der webui nicht aktualisiert hat.
Nach meinem Verständnis hätte das reichen sollen. redisdata habe ich tatsächlich nicht kopiert, eventuell liegt hier auch der Fehler?

A redis message broker: This is a really lightweight service that is responsible for getting the tasks from the webserver and the consumer to the task scheduler. These run in a different process (maybe even on different machines!), and therefore, this is necessary.

Las sich für mich nämlich erst nicht so, als wäre das für das Backup zwingend erforderlich.

Dh. du würdest davon abraten den exporter als Backup zu nehmen? Im Prinzip würde ich das Backup eigentlich nur dafür brauchen, falls Mal mit der VM etwas ist oder ich aus der VM umziehe. Wenn man alles dann getagged und sortiert hat und vll auch die ASN Funktion genutzt hat, ist man eben schon ziemlich an ein DMS gebunden.
Der Output vom exporter wäre über die snapshots von truenas versioniert, auch wenn ich diese Funktion wahrscheinlich nicht benötigen würde.

Danke schoneinmal für die Hilfe!

 

[Monacum]

Da geht es nicht, um das abraten, sondern darum, dass die mit den Exporter exportierten Dokumente alleine nicht reichen, sondern du eben auch die Datenbank noch einmal exportieren musst. Oder, das ist auch möglich, du sicherst den kompletten Ordner vom Docker-Container.

Die Sicherung der Datenbank ist vor allem für den Fall, dass die Version von PostgreSQL einem Sprung macht und es zu Inkompatibilitäten kommt. Mit den Dokumenten musst du dann ja nichts machen, da geht es dann nur darum, einen aktuellen Dump einzuspielen, damit die Datenbank wieder verfügbar ist.

Ich habe mich auf die Datenbank in meiner Antwort spezialisiert, weil auf jeden Fall unter Media alles wieder da war, aber paperless das eben in der webui nicht aktualisiert hat.

Das kann schon gut sein, weil halt die Verknüpfungen in der Datenbank fehlen. Wie gesagt, das ist ein Zusammenspiel zwischen der Datenbank und dem Ablageort der Dokumente, wenn eines nicht verfügbar ist, kein Paperless auch nichts damit anfangen.

 

[chuck86]

Da geht es nicht, um das abraten, sondern darum, dass die mit den Exporter exportierten Dokumente alleine nicht reichen, sondern du eben auch die Datenbank noch einmal exportieren musst. Oder, das ist auch möglich, du sicherst den kompletten Ordner vom Docker-Container.

Wobei da ja auch ein, ich meine json, file bei liegt was die Tags etc. beinhaltet. Ich werde die Tage mal ein paar VMs aufsetzen und den import via document_importer sowie die hier gezeigte Backup und Import Routine testen.
Die Sicherung vom Docker-Container hat eben den Nachteil, dass ich dafür den Container beenden muss. Da paperless allerdings nur lokal und nicht nachts genutzt wird, könnte man das natürlich auch nachts automatisieren. Und wenn man eben schon live ein DB Backup machen kann, versuche ich natürlich erst einmal diese Möglichkeit.

Das kann schon gut sein, weil halt die Verknüpfungen in der Datenbank fehlen. Wie gesagt, das ist ein Zusammenspiel zwischen der Datenbank und dem Ablageort der Dokumente, wenn eines nicht verfügbar ist, kein Paperless auch nichts damit anfangen.

S.o., wahrscheinlich muss ich das noch einmal mit einer frischen Installation testen, es war aber definitiv so dass medien und db die korrekte Version waren. Oder es lag an dem fehlenden backup von anderen Ordnern,

Mein Workflow war wie beschrieben wie folgt. Zunächst definiere ich einmal Z1 als Zustand von dem das Backup erstellt wurde, welches ich wiederherstellen möchte und Z2 als geänderten Zustand, nach dem Backup. Dieser soll dann durch Z1 ersetzt werden:

myusername@ubuntu-tn:~$ sudo docker exec paperless-db-1 pg_dumpall -U paperless > /home/myusername/scriptest/pg_dumpall.dump
myusername@ubuntu-tn:~$ sudo rclone copy /var/lib/docker/volumes/paperless_media/ /mnt/remote/paperless-media
2023/02/19 14:12:28 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
myusername@ubuntu-tn:~$ sudo rclone copy /var/lib/docker/volumes/paperless_data/ /mnt/remote/paperless-data
2023/02/19 14:12:36 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults

Hier sind wir uns erstmal einig, media, data und die Datenbank liegen mir nun als Z1 in einem backup Ordner vor.

Nun ändere den Zustand von Z1 auf Z2. Nicht dargestellt aber unter neuem Namen wird ein neues Backup der DB erstellt, das defintiv von Z1 verschieden ist. Also ist die Datenbank nachdem löschen von einem Dokument anders. Das passt soweit.

myusername@ubuntu-tn:~$ sudo rclone copy /mnt/remote/paperless-media/ /var/lib/docker/volumes/paperless_media/
[sudo] password for myusername:
2023/02/19 14:27:46 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
myusername@ubuntu-tn:~$ sudo rclone copy /mnt/remote/paperless-data/ /var/lib/docker/volumes/paperless_data/
2023/02/19 14:27:50 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
2023/02/19 14:27:50 NOTICE: _data/celerybeat-schedule.db: Removing partially written file on error: can't copy - source file is being updated (mod time changed from 2023-02-19 14:10:00.0462416 +0100 CET to 2023-02-19 14:27:50.8609268 +0100 CET)
2023/02/19 14:27:50 ERROR : _data/celerybeat-schedule.db: Failed to copy: can't copy - source file is being updated (mod time changed from 2023-02-19 14:10:00.0462416 +0100 CET to 2023-02-19 14:27:50.8609268 +0100 CET)
2023/02/19 14:27:50 ERROR : Attempt 1/3 failed with 1 errors and: can't copy - source file is being updated (mod time changed from 2023-02-19 14:10:00.0462416 +0100 CET to 2023-02-19 14:27:50.8609268 +0100 CET)
2023/02/19 14:27:50 ERROR : Attempt 2/3 succeeded
myusername@ubuntu-tn:~$ sudo rclone copy /mnt/remote/paperless-data/ /var/lib/docker/volumes/paperless_data/
2023/02/19 14:28:15 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults

Nun sind die Dateien (auch das fehlende Dokument) wieder in den paperless Ordnern. Das habe ich mit

ls -l

auch nachgeprüft.

myusername@ubuntu-tn:~$ sudo docker exec -i paperless-db-1 psql -U paperless < /home/myusername/scriptest/pg_dumpall.dump

Nun wird die Datenbank wiederhergestellt.
Ich fertige erneut ein Backup an und kann verifizieren, dass das neue Backup nun wieder Z1 und nicht Z2 zeigt. Dennoch habe ich in paperless nachwie vor Z2 vor mir.

Wahrscheinlich müssen wir hier einfach warten, bis ich neue VMs zum Testen aufgesetzt habe. Falls natürlich jemand jetzt noch einen Tipp hat, was dann dabei speziell zu uberprüfen / loggen wäre, um anschließend die Fehlersuche zu vereinfachen, ist das natürlich klasse.

 

[Monacum]

Wobei da ja auch ein, ich meine json, file bei liegt was die Tags etc. beinhaltet.

Völlig richtig, diese Daten werden aber nicht in die Datenbank überführt. Deswegen braucht man an der einen anderen Stelle eben doch den Dump.

Wie gesagt, media ≠ Datenbank. Beide müssen die gleichen Infos beinhalten. Den Dump der Datenbank habe ich bisher einmal gebraucht (danke an die Hilfe von @EDvonSchleck), weil ich PostgreSQL auf v15 geupdatet habe und die Datenbankversion v14 nicht kompatibel war.

Die Sicherung vom Docker-Container hat eben den Nachteil, dass ich dafür den Container beenden muss.

Nein, warum musst du den dafür beenden? Einfach kopieren, z. B. mit Hyper Backup und gut ist.

 

[chuck86]

Nein, warum musst du den dafür beenden? Einfach kopieren, z. B. mit Hyper Backup und gut ist.

Ich meine um zu verhindern, dass während des dumps die DB verändert wird. Bei nur 2 Nutzen hier natürlich überschaubar

Ich bin dem Problem tatsächlich näher gekommen.

ERROR:  database "paperless" already exists
ALTER DATABASE
You are now connected to database "paperless" as user "paperless".

So zieht sich das durch. Google konnte mir verraten, dass es ein Problem ist wenn die Datenbank schon exitiert. Man soll daher "einfach" mit --clean einen dump erstellen, der dann die vorhandene DB dropped.

Weiter als

SET
ERROR:  cannot drop the currently open database
SET
ERROR:  current user cannot be dropped
ERROR:  role "paperless" already exists
ALTER ROLE
SET
SET
SET
SET
SET

komme ich allerdings nicht, auch nicht wenn ich in der .dump händisch

DROP ROLE paperless; zu DROP ROLE paperless WITH (FORCE); ändere (und natürlich an allen anderen Stellen wo das DROP Command steht).

 

[Caramlo]

Du musst mit den Pdfs nicht machen! Somit kannst du dir Punkt 2 und 7 sparen. Lediglich der Postgres-Ordner muss leer sein, damit die Datenbank importiert werden kann. Ansonsten stürzt der Container ab.

Es würde reichen:

1. Postgres-Dump erstellen
2. alle Container anhalten
3. *.yml anpassen
4. Inhalt des Postgres-Ordners bis auf dem Backup-Ordner löschen
5. alle Container starten
6. Postgres-Dump einspielen

Eventuell möchtest du es noch einmal testen.

Da ich mein Container separat aufgesetzt habe, kann ich natürlich in jedem einzelnen arbeiten, ersetzen oder ändern ohne die anderen zu beenden oder Einstellungen vorzunehmen.

Ich habe eine Paperless-ngx Docker Installation über Portainer am Laufen. Funktioniert auch prima, nur schaffe ich das Upgrade von Postgres 14 auf 15 nicht. Ich habe es nach Vorschlag von EDvonSchleck probiert, aber nachdem ich den Dump der 14er Version einlese und danach das Webinterface starte, sind alle Dokumente nicht mehr da. Was mache ich falsch?
Den Backup-Ordner aus dem Postgres-Ordner musste ich löschen und später wieder dort hineinkopieren, ansonsten konnte ich den Prostgres Container nicht installieren.

Bin für jeden Tipp dankbar!

 

[Monacum]

Dump einlesen und Dokumente über den eingebauten Dokumenten-Importer nochmal einlesen.

 

[Caramlo]

Dump einlesen und Dokumente über den eingebauten Dokumenten-Importer nochmal einlesen.

Danke! Habe aber noch ein Brett vorm Kopf.
Muss ich die Dokumente dann vorher noch exportieren oder gibt's da eine Option den vorhandenen Media Ordner noch einmal einzulesen?

 

[Monacum]

Der Exporter exportiert nicht einfach den Media-Ordner als solchen, sondern die Dateien werden in einem eigenen Ordner abgespeichert, alle untereinander ohne Ordnerstruktur mit zwei Konfigurationsdateien im Format json. Über die Importfunktion muss dieser Ordner wieder eingelesen werden, wenn dann die dazu passende Datenbank bzw. der Dump noch vorliegen und importiert werden, funktioniert das dann auch mit einer aktualisierten Version von PostgreSQL. Ich habe das bei mir genauso gemacht, als ich von Version 14 auf 15 gewechselt bin.

Also ja, das musst du vorher machen.