paperless ngx unter docker auf Synology - Erste Erfahrungen

[Frank73]

Hallo,

beim deployen/starten von redis erhalte ich im Log folgende Warnungen (Ausschnitt):

1:C 08 Mar 2024 20:51:52.511 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
1:C 08 Mar 2024 20:51:52.511 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 08 Mar 2024 20:51:52.511 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 08 Mar 2024 20:51:52.511 * monotonic clock: POSIX clock_gettime
1:M 08 Mar 2024 20:51:52.512 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1:M 08 Mar 2024 20:51:52.512 * Server initialized
1:M 08 Mar 2024 20:51:52.512 * Ready to accept connections tcp
1:M 08 Mar 2024 22:05:04.391 * 1 changes in 3600 seconds. Saving...
1:M 08 Mar 2024 22:05:04.391 * Background saving started by pid 21
21:C 08 Mar 2024 22:05:04.828 * DB saved on disk
21:C 08 Mar 2024 22:05:04.829 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB
1:M 08 Mar 2024 22:05:04.892 * Background saving terminated with success

Ist das irgendwas wo ich manuell eingreifen muss hast du auch diese Hinweise @the other

Danke vorab und ein schönes Wochenende

 

[Frank73]

Heute mal die ersten 200 Dokumente von ecodDMS nach paperless übertragen.

Wir hatten alle Dokumente nochmals mit dem OCR-Parameter "redo" nach paperless einlesen lassen und die Geschwindigkeit ist im Vergleich zu ecoDMS der Wahnsinn. Alle Dokumente wurden innerhalb von 20 Minuten komplett und ohne Fehler durch OCR verarbeitet. Auch die abschließende Bearbeitung des Titels und die Anpassung der Tags, Dokumententypen geht ratz fatz von der Hand.

Erstes Fazit: Paperless macht fun. Hätte ich nie gedacht, dass Ablage Spass machen kann

 

[Frank73]

Paperless arbeitet aktuell ohne Fehler, weshalb ich an dieser Stelle mal den aktuell funktionierenden Ablauf kurz darstellen möchte:

Stack von paperless-ngx:

networks:
   br_paperless:
      external: true
      
services:

  webserver:
    container_name: paperless
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    networks:
      - br_paperless
    restart: unless-stopped
    ports:
      - "8010:8000"
    volumes:
      - /volume1/paperless/data:/usr/src/paperless/data
      - /volume1/paperless/media:/usr/src/paperless/media
      - /volume1/paperless/export:/usr/src/paperless/export
      - /volume1/Daten/Unterordner_1/Unterordner_2/papaperless_Inbox:/usr/src/paperless/consume
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBHOST: paperless_db #entweder Service oder den Containername verwenden
      PAPERLESS_DBUSER: user
      PAPERLESS_DBPASS: passwort
      PAPERLESS_TIME_ZONE: Europe/Berlin
      USERMAP_UID: 1028
      USERMAP_GID: 65536
      PAPERLESS_FILENAME_FORMAT_REMOVE_NONE: true #Löscht ein evtl. "none" im Speicherpfad und ersetzt es durch "_"
      PAPERLESS_OCR_MODE: redo
      PAPERLESS_EMAIL_TASK_CRON: 10 16 * * * #Ausführung E-Mail-Abruf jeden Tag um 16:10 Uhr
      PAPERLESS_TRAIN_TASK_CRON: 5 6 * * * #Ausführung Trainee jeden Tag um 06:05 Uhr
      PAPERLESS_ADMIN_USER: adminuser
      PAPERLESS_ADMIN_PASSWORD: adminpasswort
      PAPERLESS_OCR_LANGUAGES: eng deu
      PAPERLESS_OCR_LANGUAGE: deu
      PAPERLESS_URL: https://paperless.example.com

Da ich das mit dem Backup im Stack nicht hinbekommen habe, löse ich das über eine Aufgabe, welche tgl. läuft und ein Script aufruft:

Aufgabe (benutzerdefiniertes Script):

/volume1/paperless/Scripte/dump.sh

Das Script sieht dann so aus:

#!/bin/sh 
Anz_dump="+7"

docker exec paperless_db sh -c  "pg_dumpall -U User > /backup/backup_\`date +%Y%m%d"_"%H_%M_%S\`.sql
find /backup/backup*.sql -type f -mtime $Anz_dump -delete"

Wichtig ist hier, dass im Stack von PostgrSQL auch der "backup"-Ordner gemountet wird.
Da ich des Programmierens nicht so mächtig bin, wäre ich um Verbesserungen dankbar.

@the other:
Zum Testen habe mal 6 dump-Dateien in dem Verzeichnis erstellt und dann mit dem Teil-Code zur "Datenrotation" aus deinem Stack

ls -t /dump/dump*.psql|head -n 3;ls /dump/dump*.psql)|sort|uniq -u|xargs rm -- {}

so nach und nach mal ausgeführt (immer bis zur nächsten pipe). Ergebnis war, dass er mit dem kompletten Code alle dump-Dateien gelöscht hat. Da ich nicht der Programmiertyp bin, kann ich da was falsch gemacht haben, aber vielleicht könntest du das auch mal testen.

Natürlich habe ich jetzt auch noch ein Anliegen
Alles was mit paperless zu tun hat liegt auf einem separeten Share. Diese komplette Ordnerstruktur würde ich gerne auf einen anderen Share (gleiches NAS) kopieren, auf welchem div. HB-Jobs wöchenlich laufen.
Ja, ich könnte einen separaten HB-Job auf diesen paperless-Share anlegen, jedoch würde ich das gerne so lösen wollen.

Vorstellung wäre, dass das Script (so wie Erstellung meines dumps) über den Aufgabenplaner wöchentlich vor dem HB-Job läuft.
Es geht mir nur darum, die Ordner/Dateien 1:1 zu kopieren sodass diese nach einem Crash wieder als restore verwendet werden können.
Jetzt gibt es ja div. Möglichkeiten so etwas durchzuführen. Im www fiel ich über die Anwendungen "tar", "rsync" "cp". Jedes scheint aber für unterschiedliche Zwecke seine Daseinsberechtigung zu haben.

Da ich bei diesem Vorhaben auch etwas lernen möchte, wäre es im 1. Schritt hiflreich von euch zu erfahren, was ihr da nehmen würdet und auf welche Besonderheiten ich achten müsste.
Dann könnte ich mich mal an die Erstellung des Scripts dranwagen

Danke euch vorab mal und ein schönes Wochenende,

 

[blurrrr]

Nimmste rsync (macht HB übrigens auch), da musste nicht jedes mal "alles" kopieren (wie bei z.B. cp). Alternativ HB (1:1-Kopie), oder... glaub "sharesync" oder so hiess das (wäre dann via Synology Drive). Alternativ dazu "kann" man natürlich hingehen und den gesamten Ordner packen und dann die einzelne Datei kopieren. Die erste Variante hat den Vorteil, dass die Daten direkt einsehbar im Share liegen, bei der zweiten Variante liegt halt nur das gepackte Archiv im Share.

 

[frosch2]

Nimmste rsync

Das würde ich auch empfehlen.

 

[Frank73]

Danke für eure Empfehlungen. Habe mal mit meinen bescheidenen Kenntnissen ein Bash-Script erstellt, mit welchem ich die Daten so sichern werden. Erste Tests liefen auch erfolgreich.

#!/bin/sh

#Version: 10.03.2024
#Datensicherung Share "paperless" auf auf den Share "Daten"
#ausser die in der Variable "ausschluss" hinterlegten Ordner/Dateien
#Aktuell nur die PostgreSQL-DB, da diese über einen tgl. Dump im
#backup-Verzeichnis gesichert wird; wird über dieses Job allerdings
#mitgesichert!

backup_source="/volume1/docker/paperless/"
backup_target="/volume1/vm_daten/test"
ausschluss="/volume1/vm_daten/test/ausschluss.txt"
protokoll="/volume1/vm_daten/test/protokoll.log"
protokoll_err="/volume1/vm_daten/test/protokoll_err.log"
akt_date=$(date +%d.%m.%Y)
akt_time=$(date +%H:%M:%S)

echo "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> $protokoll_err
echo "Datum der Sicherung: " $akt_date " / " $akt_time >> $protokoll_err

echo "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> $protokoll
echo "Datum der Sicherung: " $akt_date " / " $akt_time >> $protokoll

rsync -av --exclude-from="$ausschluss" ${backup_source} ${backup_target} >> $protokoll 2>> $protokoll_err

Sollten Fehler im Script sein, oder ihr Verbesserungsvorschläge haben, als her damit; werde dann versuchen es einzubauen.

Bei meinen Tests ist mir was aufgefallen, was ich mir nicht erklären kann:
Ausführung des Scrpits mittels SSH mit meinen Admin-User. Sicherung aller Dateien erfolgreich, da entweder über den User oder die Gruppe Zugriffsrechte bestehen (ausser der Ordner PostgreSQL, der wird aber ausgeschlossen). Anmeldung mit root über sudo -i; rsync erkennt, dass nichts zu sichern ist, läuft ohne Fehler durch --> Passt. Jetzt wieder die Sicherung mit Admin-User angestossen, dann erscheint im Error-Log:

rsync: failed to set permissions on "/volume1/vm_daten/test/pg_backup/backup_09-03-2024_23_00_06.psql": Operation not permitted (1)

Die Rechte der Ordner / Dateien sind aber unverändert. Was hat der User root gemacht, damit der Admin-User keine Rechte mehr hat?
Und mit welchem User würdet ihr das Script ausführen. Bei Ausführung mit root habe ich keine Rechte die logs zu lesen

OT:
Sollte ich diesen Post in einem separaten Thread posten? Hat ja originär nichts mit paperless zu tun.

 

[frosch2]

Ruf mal rsync mit der Option "--no-perms" als Admin-User auf.

 

[the other]

Moinsen @Frank73,
sorry, war das Wochenende AFK...daher erst heute alles gesehen und bisher nur oberflächlich (weil Lohnarbeit ansteht).

Ist das irgendwas wo ich manuell eingreifen muss hast du auch diese Hinweise @the other

Nein, ich habe es eben kurz ausprobiert, Container gestoppt, neu gestartete > keine Logeinträge dazu außer, dass es erfolgreich gestartet wurde.

 

[Frank73]

Hallo,

bzgl. Speicherhinweises im redis-log habe ich mich (fast die ganze Nacht ) mal im www schlau gemacht. Immer mit dem Ergebnis, dass eine Variable auf dem Host-System angepasst werden muss (hier) und der Container privilegiert ausgeführt werden muss. Dies würde ich gerne vermeiden wollen.
Wie ist das bei dir administriert, oder hast du noch einen Tipp für mich?

P.S. Mein NAS ist eine DS1621+ mit 20GB Hauptspeicher, daran sollte es eigentlich nicht scheitern.

 

[Frank73]

Hallo @frosch2

Ruf mal rsync mit der Option "--no-perms" als Admin-User auf.

Danke für den Hinweis. --> Werde ich mal testen. Meine Ergebnisse werde ich in einem separaten Thread mitteilen.

 

[the other]

Moinsen,
da habe ich ehrlicherweise auch keine Ahnung zu bzgl privilegiertem Container und extra Variablenanpassung...

 

[Confluencer]

bzgl. Speicherhinweises im redis-log habe ich mich (fast die ganze Nacht ) mal im www schlau gemacht. Immer mit dem Ergebnis, dass eine Variable auf dem Host-System angepasst werden muss (hier) und der Container privilegiert ausgeführt werden muss. Dies würde ich gerne vermeiden wollen.

Ein privilegierter Container sollte man in der Tat meiden, er ist so schwach isoliert, dass es de-facto unmöglich ist zu verhindern, dass jemand mit Ahnung aus einem solchen ausbrechen kann.

Dann besser den Wert auf dem Host konfigurieren.

Als root Benutzer (bspw. nach sudo -i):

# Konfiguration erweitern
echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
# Konfiguration laden, wird ab nächsten Boot automatisch mitberücksichtigt.
sysctl -p

Wobei ich es ehrlich gesagt ziemlich merkwürdig finde, dass man Arbeitsspeicher auch bei Hosts Übercommiten soll, die nicht unter Arbeitsspeicher Knappheit leiden...

 

[Frank73]

Ich habe die letzten Tage das Protokoll von redis überprüft. Die ganzen Background-Speicherungen wurden alle erfolreich und ohne Fehler/Hinweise durchgeführt.
Auch dieser Hinweis lässt mich "hoffen", dass es keine Speicherprobleme geben wird (zumindes in absehbarer Zeit)

Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB

Notfalls werde ich das "übercommitten" aktivieren.

 

[the other]

Moinsen,
schön, dass es jetzt funktioniert.
Bzgl deiner Warn-Meldungen im Post #21: ich denke, ein Warnung ist ja nicht gleich ein Fehler (Error)...vermutlich (reine Vermutung meinerseits!!) ist das einfach eine standardmäßige Warnung, dass etwas passieren KÖNNTE, FALLS nicht genug Speicher zur Verfügung stehen würde. Bei deinen 20 GB sollte das idT kein Ding sein.
Und auch in der Meldung steht ja zum Ende:
"Background saving terminated with success"
Na, dann viel Vergnügen mit paperless...ich bin auch immer noch sehr happy damit (erst gestern die per Post (OLDSCHOOL!!) zugestellte Schornsteinfegerrechnung auf den scanner gelegt, BAM!...archiviert. Nice.

 

[Frank73]

Hallo,
nach einer Woche Migration von unseren Dokumenten, soeben noch die letzten Tests über Mail erfolgreich durchgeführt.
Anbei mal unsere aktuelle Statistik:

Wovon ich absolut begeistert bin ist die "Lernfähigkeit" dieser Anwendung. Wir haben 8 Mailanhänge einlesen lassen und bei 7 davon hat alles gepasst (Korrespondent, Dokumententyp, Speicherpfad und sogar die Tags) --> Wahnsinn!!

 

[the other]

Moinsen,
so: nach ein paar Wochen mit dem automatisierten Backup (und dem dump der Datenbank) kann ich sagen, dass es funktioniert, wie im script gewünscht.
Jede Woche wird ein Datenbank dump angelegt. Damit sollte dann eigentlich alles ausreichend gesichert sein...
*und paperless ngx selber funktioniert auch weiter wie gewünscht.

 

[blurrrr]

Das "sollte" ... "sollte" man vllt auch mal testen

 

[the other]

Moinsen,

Das stimmt allerdings...wurde es. Gestern. Hat soweit auch funktioniert...
Aber (Spass kurz beiseite): der Hinweis ist absolut richtig und wichtig...backups nicht nur machen sondern auch prüfen, ob die wieder einspielbar sind (und den eigentlichen Zustand wirklich wieder herstellen können).

 

[Frank73]

Hab gestern mal den "Notfall" auf der Testumgebung durchgespielt (auf dem Echtsystem warte ich lieber auf den "Ernstfall" ).
Sowohl 1:1-Rücksicherung über HB hat funktioniert, als auch das Einspielen über den "Dokumenten-Importer" von paperless-ngx.

Habe mich in Nachgang und nach endlosen nächtlichen Tests dazu entschlossen, den separaten Share über HB zu sichern und nicht wie erst geplant den ganzen Schmodder per rsync auf einen anderen Share (gleiches NAS) zu sichern. Hier hatte ich mehr Probleme beim Rücksichern (vor allem mit den Berechtigungen) als ich dachte. --> Warum soll man das Rad neu erfinden, wenn es schon da ist.
Einzig was ich über Scripts automatisch im wöchentlichen Rhythmus mache ist der Datenbank-Dump und den Exporter von paperless.

Zusammenfassung meiner schlaflosen Nächte:
rsync hat mir zwar viel Kopfzerbrechen bereitet, der Lerneffekt (auch ein bisschen zu scripten) hat allerdings -mäßig viel Spaß gemacht und ganz wichtig ....
.... paperless brummt zuverlässig vor sich hin