Thomas Kramer

IT-COW | April 2022

Dokumentenmanagement mit Paperless-NGX

By Administrator at April 17, 2022 04:48
Filed Under:

Das Thema Dokumentenmanagement-Software ist privat bislang an mir vorbeigegangen, es bestand aber auch nicht unbedingt die Notwendigkeit dazu eine einzuführen. Es ist aber schon praktisch, alle Dokumente im Sofortzugriff verfügbar zu haben.

 

Wahrscheinlich gibt es auch Apps um Nextcloud um solche Funktionalitäten zu erweitern, aber ich bevorzuge dafür ein separates Programm. Es gibt viel Auswahl an Dokumentenmangement-Software, sowohl im Open Source als auch im kommerziellen Bereich.

 

Auf iSkysoft gibt es eine kleine Übersicht der verfügbaren Open Source-Dokumentenverwaltungen, wobei auch Light- oder Community-Versionen kommerzieller Programme aufgelistet werden. Bei FOSSMINT gibt es auch eine Übersicht von Open-Source DMS. Nach der Feature-Matrix von beispielsweise LogicalDOC gibt es für die Community-Version keine OCR-Texterkennung, darauf muss man aber auch im Open Source-Bereich nicht verzichten.

 

Auch im privaten Bereich gibt es für manche Dokumente gesetzliche Aufbewahrungsfristen. Open Source-Software wird eher selten die gesetzlichen Anforderungen zur Revisionssicherheit erfüllen, daher sollte man die Originale in Papierform weiterhin aufbewahren. Das gilt aber nicht für alle Dokumente, vieles kann man auch direkt entsorgen.

 

Die Auswahl fiel schwer, deswegen habe ich auch in Foren nach Empfehlungen gesucht, beispielsweise im Hardwareluxx. Als Argument zur Auswahl eines bestimmten Programmes wird häufig genannt, dass die eingescannten Dokumente auch außerhalb der Anwendung weiterhin zugreifbar sein sollten. Relevant ist das zum Beispiel wenn es einen Software-Anbieter irgendwann nicht mehr gibt und ein Problem mit der Anwendung auftritt, bei beschädigten Dateien, oder wenn man das Programm wechseln will.

 

Aufgefallen sind mir Paperless-NGX und SeedDMS. Paperless-NGX ist ein Fork von Paperless-NG, nachdem es bei letzterem einen längeren Entwicklungsstillstand gab und der Programmierer nicht mehr erreichbar war. Das Github-Repository war aber auf eine Einzelperson registriert, daher hat man um weitermachen zu können das Projekt geforkt, im Open Source-Bereich ist das anders als im kommerziellen Bereich möglich.

 

Der Docker von Paperless-NG hat über 10 Millionen Pulls, es handelt sich also um eine durchaus verbreitete Software. Der Docker von Paperless-NGX kommt da mit ca. tausend Pulls noch bei weitem nicht heran, aber das kann sich noch ändern. Wichtig ist jedenfalls dass die Entwicklung weitergeht. Über den neuen Fork ist in Caschys Blog, bei Heise Online oder im Deployn Blog berichtet worden.

 

Paperless-NG hatte ich zuerst getestet, bin dann aber gleich auf Paperless-NGX umgestiegen. Den Docker für Paperless-NGX kann man wie folgt aufsetzen:

 

docker run -d --name=paperless-ngx \
-p 8000:8000 \
-e PUID=1000 \
-e PGID=1000 \
-e TZ=Europe/Berlin \
-e PAPERLESS_OCR_IMAGE_DPI=300 \
-e PAPERLESS_OCR_LANGUAGES=deu \
-e PAPERLESS_OCR_LANGUAGE=deu \
-e PAPERLESS_REDIS=redis://localhost:6379 \
-e PAPERLESS_DBHOST=postgres \
-e PAPERLESS_DBNAME=paperless \
-e PAPERLESS_DBUSER=paperless \
-e PAPERLESS_DBPASS=$Password\
-e PAPERLESS_FILENAME_FORMAT='{correspondent}/{created_year}/{title}' \
-v $Path1:/config \
-v $Path2:/data \
--restart always \
lscr.io/linuxserver/paperless-ngx

 

Default-Benutzer und Passwort (von Paperless, nicht der Datenbank) sind anschließend übrigens admin/admin. Eigentlich kann man User/Password auch übergeben, aber bei meinem Test hatte er das neue Passwort dann ignoriert. Das ist aber nicht weiter tragisch, denn über die Oberfläche kann man das Passwort natürlich immer noch ändern.

 

Über PUID und PGID wird die ID des Docker-Users angegeben, das ist eine spezifische Sache der Linuxserver.io-Docker, andere Docker unterstützen das nicht unbedingt. Siehe den Artikel Understanding PUID and PGID. Wenn Ihr euch bei eurem NAS über SSH einloggt könnt Ihr über “id $USER” die IDs eures Benutzers herausfinden und die Angaben oben dann anpassen. 

 

Standardmäßig benutzt Paperless eine eingebaute SQLite-Datenbank, daher sind die _REDIS- und _DB-Parameter optional. Durch meine vorherigen Projekte habe ich aber REDIS und PostgreSQL bereits im Einsatz und fand es sinnvoll sie auch mit Paperless zu benutzen. Für eine YAML-Datei mit Redis und PostgreSQL könnt Ihr im Deployn Blog nachschauen, ich empfehle aber den Beta-Tag bei der Angabe paperless-ngx:beta wegzunehmen.

 

Bezüglich PostgreSQL habe ich natürlich eine neue Datenbank angelegt:

docker exec -it postgres bash

psql -U postgres

CREATE DATABASE paperless;
CREATE USER paperless WITH PASSWORD '$Password';

Und diese Datenbank habe ich dem Docker über Parameter übergeben, siehe oben. Bei den $-Parametern müsst Ihr natürlich Werte einsetzen, die zu eurem System passen.

 

Für erste PostgreSQL-Basics könnt Ihr beispielsweise hier oder hier nachschauen. Die Docker-Parameter von Paperless-NGX orientieren sich an den Parametern der Einstellungsdatei paperless.conf, daher kann man sich an der Dokumentation hier orientieren. Wenn man Einstellungsdateien sucht empfehle ich die Installation von Locate im Docker:

 

docker exec -it paperless-ngx bash

apt update

apt install locate

apt install nano

updatedb

locate paperless.conf

nano /app/paperless/paperless.conf

 

Wenn Watchtower Docker aktualisiert werden natürlich nachinstallierte Programme im Docker wieder zurückgesetzt, das kann man nicht verhindern aber über einen Cronjob die Nachinstallation von Programmen oder andere Änderungen in einzelnen Dockern automatisieren.

 

Interessant ist übrigens auch dass im Container von Paperless-NGX diverse Kommandozeilen-Managementutilities vorhanden sind, um beispielsweise Dokumente zu ex- oder importieren, Dokumente zu retaggen oder Dateinamen der Dokumente zu ändern. Zusammen damit, dass die eingescannten PDF-Dateien auch direkt über das Dateisystem eingesehen werden können, bildet das eine gewisse Offenheit des Systems, die nicht selbstverständlich sein dürfte.

 

Ich habe testweise mal versucht diese Kommandozeilenutilities anzusprechen, das geht außerhalb des Dockers über folgenden Befehl:

docker exec -it paperless-ngx python3 /app/paperless/src/manage.py document_index reindex

 

Relevant war für mich, dass die OCR-Texterkennung speziell für die deutsche Sprache ausgeführt wird, die OCR-Einstellungen von Paperless-NGX sind hier dokumentiert. Die entsprechenden Parameter lauten:

PAPERLESS_OCR_LANGUAGE=deu

PAPERLESS_OCR_LANGUAGES=deu

 

Der Languages-Parameter (Mehrzahl) soll Sprachpakete automatisch nachinstallieren, das funktionierte bei mir im Test allerdings nicht. Beim Start von Paperless-NGX kam dann die Fehlermeldung

paperless The selected ocr language deu is not installed

was man aber nur einsehen konnte, wenn man mit

docker logs paperless-ngx

in die Docker Logs schaute.

 

Laut der Tesseract-Dokumentation von Ubuntuusers lautet das fehlende Paket tesseract-ocr-deu. Damit das deutsche Sprachpaket nach einem Update des Paperless-NGX-Containers durch Watchtower automatisch nachinstalliert wird, habe ich der Crontab des Hosts folgende Zeile hinzugefügt:

 

30 6 * * * docker exec paperless-ngx apt-get update && docker exec paperless-ngx apt-get install tesseract-ocr-deu --yes && docker restart paperless-ngx

 

Ich gehe davon aus dass das mit einem zukünftigen Update behoben wird, aber der Eintrag in der Crontab kann nicht schaden.

 

Da ich REDIS als In-Memory-Datenbank (Cache im RAM) mit Paperless-NGX benutze, wird folgende Warnung im Docker geloggt:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. 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.

 

Das könnte damit zusammenhängen, dass ich zwei Anwendungen mit REDIS benutze. Laut der Diskussion bei Github kann ich das wohl ignorieren. Probleme habe ich keine festgestellt, aber gegebenenfalls überprüfe ich das später noch einmal.

 

Ich finde das Webinterface von Paperless-NGX ansprechend aufgebaut und klar strukturiert, man kann sich schnell einarbeiten. Das Protokoll ist auch direkt über das Webinterface einsehbar, auch hier ein Beleg für die Offenheit des Systems.

 

image

 

Es gibt einen consume-Ordner von Paperless, wo abgelegte Dokumente automatisch ins System aufgenommen werden. Es macht daher Sinn, diesen Ordner über einen Samba-Server im Netzwerk freizugeben. Ein Samba-Server ist schnell aufgesetzt:

 

apt-get install samba
adduser otto (Betriebssystem-User anlegen)
smbpasswd –a otto (Samba-User hinzufügen)

 

Danach dann die Einstellungsdatei von Samba editieren und anpassen:

nano /etc/samba/smb.conf

 

Im Global-Abschnitt sicherheitshalber ändern/hinzufügen:

interfaces = $IP/24 eth0

bind interfaces only = yes

map to guest = never

client min protocol = SMB2
client max protocol = SMB3

hosts allow = XXX.XXX.XXX.

 

Einen neuen Abschnitt hinzufügen:

[paperless]
        path = $PATH_to_paperless
        valid users = otto
        public = no
        guest ok = no
        writable = yes
        browseable = no
        force user = $USER_from_paperless

Und den Samba-Server dann mit

systemctl restart smbd

neu starten. Über das Netzwerk kann man dann über den UNC-Pfad \\$IP\paperless auf Paperless zugreifen. Ihr könnt das Verzeichnis auf einen Laufwerksbuchstaben mappen und dann in eurer Scanner-Software als Speicherziel angeben. Wenn Ihr einen Scanvorgang startet, wird das eingescannte Dokument dann direkt in Paperless-NGX importiert.

 

Die Paperless-Dateien werden auf dem Host mit dem User als Eigentümer abgelegt, den Ihr mit PUID und PGID dem Docker übergeben habt. Entsprechend müsst ihr diesen User namentlich bei force_user angeben, falls der Benutzer von dem abweicht mit dem Ihr auf den Pfad über das Netzwerk zugreifen wollt.

 

Da es um private Dokumente geht, empfehle ich nur euch selbst den Zugriff zu gestatten und den Gastzugriff zu deaktivieren. Außerdem empfehle ich browseable auf no zu setzen, dann muss man den Namen der Freigabe kennen um darauf zugreifen zu können. Hier noch ein paar Samba-Links: Ionos Linux-Praxis The Geed Diary.

 

Bei Problemen kann es nicht schaden in die Logs von Samba zu schauen:

less /var/log/samba/log.smbd

Bei mir gab es da zunächst einen Konflikt mit dem durch einen anderen Docker bereits belegten Port 445, das ich dadurch herausgefunden habe. Wenn man viele Docker benutzt kann man schonmal den Überblick verlieren, aber das lässt sich schnell beheben.

 

Paperless-NGX macht einen guten Eindruck, bis jetzt kann ich die Software weiterempfehlen. Tutorials gibt es vereinzelt auch auf Youtube. Im Synology-Forum gibt es auch einen Thread mit Fragen zu Paperless-NG. Außerdem möchte ich noch erwähnen dass es auch eine Android-App für Paperless gibt, die auch mit Paperless-NGX funktioniert.

 

Im Zusammenhang mit Dokumentenmanagement-Software werden häufiger sogenannte Paginierstempel erwähnt, um Dokumente durchzunummerieren. Solche Stempel haben ein automatisches Zählwerk und sind ab ca. 40 Euro erwerblich. Herr Dr. Joachim Schlosser erzählt auf seinem Blog wie er dabei vorgeht, um sein papierloses Büro zu verwirklichen.

 

Wer ausschließlich auf Software setzt um seine Dokumente zu archivieren, muss sich auch um das Thema Backup kümmern. Eventuell kann man unterstützend dafür auch Syncthing einsetzen, dann hat man Synchronisation und auch Versionierung zur Verfügung, kann also von Dokumenten einen früheren Stand wiederherstellen. Allerdings setzt Syncthing nur für den Transport auf Verschlüsselung und speichert selber unverschlüsselt ab. Teilweise gibt es aber auch Windows-Bordmittel, auf die man setzen kann.

 

Wie ich gesehen habe, ist für viele eine Cloud-Aufbewahrung ihrer Dokumente ein Ausschlusskriterium. Die Verwendung von verschlüsselten Dateicontainern via VeraCrypt z. B. wäre da aber auch möglich. Wenn man übrigens VeraCrypt mit Synchronisationslösungen wie Syncthing benutzt, sollte man die Option

image

deaktivieren und besser eine aktuelle Version von VeraCrypt.fr herunterladen. Meine ältere Version hatte einen Fehler und diese Option in den Einstellungen wurde ignoriert, und damit der Container nicht synchronisiert.

 

Da die Synchronisationslösungen den Zeitstempel von Dateien auslesen um Änderungen zu erkennen, empfehle ich die Option von VeraCrypt zu testen und den Zeitstempel der Containerdatei zu beobachten. Normalerweise wird der Zeitstempel beim Trennen aktualisiert.

 

Im Heise-Forum las ich, dass manche Leute ihre Paperless-Installation mit dem Kommandozeilenprogramm rclone verschlüsselt in einer Cloud abspeichern. Solange die Daten verschlüsselt abgelegt werden, sind sicher auch fremde Server akzeptabel. So sind die Daten auch gegen Einbruch/Diebstahl und Brand geschützt.

 

Ergänzung 21.04.2022: Basierend auf dem Beitrag von dem Deployn-Blog habe ich bei mir auch eine YAML-Datei erstellt, da zu Paperless noch Tika- und Gotenberg-Docker hinzugekommen sind. Das sind optionale Funktionen von Paperless, wenn man sie über separate Docker einbindet kann Paperless auch Office-Dokumente nach PDF konvertieren.

 

Nachfolgend meine YAML-Datei, allerdings müsst Ihr die REDIS- und POSTGRES-Docker ergänzen, da die bei mir über andere YAML-Dateien instanziiert werden. Odere Ihr nehmt die _REDIS und _DB-Parameter heraus, denn das sind eigentlich optionale Parameter von Paperless. Wenn die _DB-Parameter nicht übergeben werden benutzt er eine eingebettete SQLite-Datenbank, ansonsten PostgreSQL.

 

version: "3"
services:
  service.gotenberg:
    container_name: gotenberg
    ports:
      - 3000:3000   
    image: gotenberg/gotenberg
    restart: always
    environment:
      CHROMIUM_DISABLE_ROUTES: 1
    networks:
      - lsio

  service.tika:
    container_name: tika
    ports:
      - 9998:9998   
    image: apache/tika
    restart: always
    networks:
      - lsio
  service.paperless:
    image: lscr.io/linuxserver/paperless-ngx
    container_name: paperless-ngx
    ports:
      - 8000:8000
    environment:
      - PUID=1001
      - PGID=1001
      - PAPERLESS_TIME_ZONE=Europe/Berlin
      - PAPERLESS_OCR_IMAGE_DPI=300
      - PAPERLESS_OCR_LANGUAGES=deu
      - PAPERLESS_OCR_LANGUAGE=deu
      - PAPERLESS_REDIS=redis://localhost:6379
      - PAPERLESS_DBHOST=postgres
      - PAPERLESS_DBNAME=paperless
      - PAPERLESS_DBUSER=paperless
      - PAPERLESS_DBPASS=$PASSWORD
      - PAPERLESS_FILENAME_FORMAT='{correspondent}/{created_year}/{title}'
      - PAPERLESS_TIKA_ENABLED=1
      - PAPERLESS_TIKA_GOTENBERG_ENDPOINT=http://localhost:3000
      - PAPERLESS_TIKA_ENDPOINT=http://localhost:9998
    depends_on:
      - service.gotenberg
      - service.tika    
    volumes:
      - $PATH1:/config
      - $PATH2:/data
    restart: always
    networks:
      - lsio   
networks:
  lsio:
    external: true

 

Nach dem Start mit docker-compose up –d führe ich außerdem folgenden Befehl aus um das deutsche Sprachpaket für Tesseract nachzuinstallieren:

docker exec -it paperless-ngx apt update && docker exec -it paperless-ngx apt install tesseract-ocr-deu && docker restart paperless-ngx

 

Die $-Parameter sollen bei mir Variablen darstellen, diese Werte müsst Ihr bei euch anpassen. Ich empfehle nach dem Start die URLs von Gotenberg und TIKA einmal im Webbrowser aufzurufen, um zu kontrollieren ob sie funktionieren. Viel zu sehen gibt es da nicht, aber kontrollieren kann man. Falls localhost nicht funktioniert könnt Ihr mal die IP-Adresse ausprobieren. Zudem sollte man immer in die Logs der Docker reinschauen.

 

Ich habe leider noch einen großen Nachteil von Paperless-NGX festgestellt: Es gibt zwar so etwas wie eine Benutzerverwaltung, aber grundsätzlich kann jeder Benutzer alle Dokumente in der Datenbank einsehen. Die Benutzerverwaltung verfehlt somit etwas ihren Sinn, für eine Firma könnte das ein Ausschlusskriterium bei der Einführung sein. Ich weiß daher noch nicht ob ich bei Paperless-NGX bleibe, aber immerhin wurde die Weiterentwicklung wieder aufgenommen. Es gibt zu dem Thema übrigens eine Diskussion auf GitHub.

 

Ansonsten hat das Programm gute Ansätze und die Oberfläche ist klar strukturiert. Interessant ist übrigens auch die Fähigkeit von Paperless-NGX, das EMail-Postfach nach Mails mit Anhängen zu durchsuchen und diese automatisch in die Datenbank aufzunehmen.

 

Eventuell schaue ich mir auch noch PaperMerge an, dazu gibt es auch einen Docker. Es gibt da einige Lösungen, es ist schwierig einen Überblick zu bekommen. Bei den kommerziellen Lösungen wäre ich mir nicht sicher ob die Firmen in 10 Jahren noch existieren, bei den teilweise langen gesetzlichen Aufbewahrungsfristen ist Open Source für eine Dokumentenmanagementsoftware schon attraktiv.

 

Ergänzung 22.04.2022: Da es für Paperless-NGX einen Docker gibt, ist es natürlich einfach möglich die Software mehrmals zu hosten (auch auf demselben Server) und dadurch eine echte Datentrennung zwischen den Accounts zu erreichen. Dazu muss man lediglich:

 

1. In PostgreSQL einloggen und mit CREATE DATABASE $NAME; eine zusätzliche Datenbank hinzufügen

2. Auf dem Host zwei zusätzliche Verzeichnisse für den zusätzlichen Docker anlegen

3. Einen zusätzlichen Paperless-Docker in der YAML-Datei anlegen, und diesen auf einen anderen Port legen. Der Parameter PAPERLESS_DBNAME sollte auf die neue Datenbank verweisen. Außerdem sollte der interne Containername von dem anderen Container abweichen.

 

Das ist natürlich keine elegante Lösung, aber einfach machbar. Für einen zwei bis drei Parteien-Haushalt halte ich das für eine noch vertretbare Lösung. Der Ressourcen-Verbrauch von Paperless-NGX und den eingebundenen Hilfscontainern Tika und Gotenberg ist gering. Nachfolgend eine Ausgabe von docker stats:

 

image

 

Auch während des Scanvorgangs blieb Paperless bei mir unter 300 MB RAM-Verbrauch, das ist minimal. Natürlich wird der RAM-Verbrauch mit mehr Dokumenten noch steigen, aber ich kann mir im Moment nicht vorstellen dass das relevant sein wird.

 

Zu Paperless-NG habe ich übrigens auch noch ein deutsches Blog mit Praxistipps gefunden.

 

Im Deployn-Blog gibt es auch einen Tipp, wie man automatisch einen Postgres-Dump über einen Entrypoint im Docker erstellen lässt. Über den Entrypoint wird eine Bash-Prozedur beim Starten des Dockers ausgeführt, die einen Dump erstellt.

 

Die Zeile

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

musste ich bei mir aber durch

(ls -t /dump/dump*.psql|head -n $$BACKUP_NUM_KEEP;ls /dump/dump*.psql)|sort|uniq -u|xargs --no-run-if-empty rm -rf

ersetzen, damit es funktioniert. Andernfalls bekam ich bei mir die Fehlermeldung

image

was man aber nur durch die Docker Logs einsehen konnte.

 

Das Statement wird nach der Erstellung des Dumps ausgeführt und muss man so lesen: Liste alle Dateien mit der Dateiendung .psql aus dem Verzeichnis /dump auf, dieses Verzeichnis wird auf ein Host-Verzeichnis gemappt. Filtere aus dieser Liste die letzten $BACKUP_NUM_KEEP-Zeilen heraus, die behalten werden sollen. Hänge an diese Liste dann nochmal alle Dateien aus dem Verzeichnis an - dadurch sind die Dateien, die behalten werden sollen, anschließend doppelt in der Liste vorhanden. Sortiere dann die Liste und entferne die doppelten Einträge, anschließend die übrig gebliebenen Dateien löschen. Schon interessant gelöst.

 

Die PostgresSQL-Datenbank selber läuft in dem paperless-db-backup-Docker dort nicht, dadurch verbraucht dieser Docker sehr wenig RAM.

 

Auf manchen Seiten sehe ich in YAML-Dockerdateien übrigens Healthchecks, vielleicht baue ich die bei mir auch noch ein. Ein Beispiel:

 

    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000"]
      interval: 30s
      timeout: 10s
      retries: 5

 

Eine Erläuterung findet sich zum Beispiel auf dieser Seite.

 

Außerdem wollte ich noch Mayan EDMS testen, aber nachdem ich gelesen hatte dass nur zwei Entwickler hinter der Lösung stehen, habe ich davon erstmal Abstand genommen. Das ist weniger Manpower als das Paperless-NGX-Projekt derzeit hat.

 

Ergänzung 24.04.2022: Ich habe nun auch ein zweistufiges Backup für meine Paperless-NGX-Instanz eingerichtet. Zuerst werden die Daten mittels des Befehles

rsync -rl /home/$User/paperless_ngx/ /media/$Laufwerk/paperless-ngx --delete

auf eine externes Speichermedium repliziert, wobei mit dem Parameter --delete Dateien automatisch auf dem Backupziel gelöscht werden, die bereits auf dem Quellmedium gelöscht wurden. Gegen versehentlich gelöschte Dateien hilft dieses Backup also nicht, aber dadurch sollte das Zielmedium auch nicht irgendwann unbeabsichtigt volllaufen.

 

Da ich ein externes Speichermedium vom Proxmox-Host an den LXC-Container durchreiche, gab es Probleme mit dem Ändern des Eigentümers von Dateien in dem Ordner. Ich brauche vom Backup aber nur die Dateiinhalte und nicht die Berechtigungen, daher benutze ich –rl als Parameter. Normalerweise reicht ein –a aus.

 

Das zweite Backup geschieht bei mir verschlüsselt über RClone auf meinen Dropbox-Account, dazu benutze ich die Software RClone. RClone unterstützt viele verschiedene Cloud-Systeme, siehe deren Matrix. Bei Jan-Hendrik Ewers Blog gibt es einen Eintrag, der sich speziell auf das Backup von Paperless-NG bezieht. Er benutzt es zusammen mit dem RClone_Jobber-Skript. RClone benutzt ein dialogbasiertes Einrichtungsskript, das ist auf Herrn Ewers Blog gut beschrieben.

 

Die Einrichtung von RClone ist nicht schwer, man richtet zuerst den unverschlüsselten und dann den verschlüsselten Zugang ein. Für den verschlüsselten Zugang legt man ein Verzeichnis mit einem Alias ein, dieser Alias wird dann als Backup-Ziel oder beim Restore benutzt. Bei Linux-Community gibt es auch ein deutschsprachiges Tutorial zu RClone, zusammen mit einer Übersicht der RClone-Befehle. Herr Ewers benutzt zudem das RClone_Jobber-Skript, dort werden die Parameter wie Quelle, Ziel und Filter in einem separaten Skript eingetragen. Das Skript kann man dann natürlich über einen Cronjob automatisiert aufrufen lassen.

 

Man kann das Remote-Verzeichnis aus der Cloud übrigens lokal mounten, das scheitert bei mir aber noch:

image

 

Mir reicht es aber vorerst aus dass ich alle Dateien lokal mit RClone Copy wiederherstellen kann:

image

Passwort und Salt für RClone werden nicht erneut abgefragt, aber sollte man sich natürlich irgendwo notieren.

 

Es gibt da übrigens eine Stelle im RClone-Einrichtungsprozess, bei der man für die Berechtigung einen Webbrowser öffnen muss. Das Skript unterstützt dafür auch Server die headless laufen, also rein terminalbasiert. Dazu braucht man dann aber einen anderen Rechner, wo man RClone und einen Webbrowser installiert hat. Auf Reddit kursiert aber ein Trick, wie man bei headless-Servern ohne zweiten RClone-Rechner die Einrichtung abschließen kann, indem man mit Socat TCP-Sockets umlenkt. Eine interessante Lösung, scheiterte bei mir aber daran dass Socat die Sockets nicht lokal öffnen konnte.

 

Ich habe dann aber RClone unter Windows installiert und so den Einrichtungsprozess von RClone vom headless-Linux-Server abgeschlossen. Im Browser wird dann eine Zeichenkette ausgegeben, die man per Copy and Paste übernehmen muss.

 

RClone gefällt mir gut, endlich wieder einen Nutzen für meinen Dropbox-Account gefunden. Natürlich sichere ich dort alles verschlüsselt, was ich auch direkt überprüfen kann. Übrigens kann man in dem RClone_Jobber-Skript auch eine Monitoring-URL angeben, um sich dann über Healthchecks.io über ausbleibende Conjobs benachrichtigen zu lassen.

 

Ergänzung 25.04.2022: Ich habe mein Backupkonzept nochmal überarbeitet, da ein alleiniges 1:1-Abbild des aktuellen Zustands unbefriedigend ist, zumal Rsync relativ einfach ein inkrementelles Backup über Hardlinks ermöglicht.

 

Außerdem habe ich festgestellt dass bei vielen kleinen Dateien das Cloud-Backup über RClone inakzeptabel langsam ist. Bei meinem DokuWiki mit ~ 1.700 Dateien, die alle zusammen aber weniger als 5 MB groß sind, benötigt er ca. eine halbe Stunde zur Cloud-Sicherung (zu dem Zeitpunkt noch ohne eigenen API-Schlüssel getestet).

 

Daher habe ich das Rsync-Skript von Linuxconfig.org genommen, zudem lasse ich nur den letzten Stand gezippt über die Cloud sichern, da das ZIP-Archivformat keine Hardlinks unterstützt. Das 7Zip-Archivformat soll aber Hardlinks unterstützen, das könnte ich später einmal testen.

 

Für rotierende Backups habe ich z. B. das Skript bei Noah.org gefunden. Einmal gelöschte Daten bleiben bei meiner jetzigen Lösung im ersten Backup ewig erhalten, aber das sollte kein Speicherproblem ergeben. Die Sicherung geschieht bei RClone bereits verschlüsselt, wenn ich übervorsichtig sein will könnte ich auch noch passwortgeschützte Archive erstellen.

 

Bei RClone bin ich mir noch unsicher ob die Cloud-Backups längere Zeit fehlerfrei funktionieren, da sich Programmierschnittstellen von Cloud-Diensten irgendwann ändern können. Wenn man sowas konfiguriert sollte man wahrscheinlich auch für ein automatisches Update von RClone sorgen. Aber eigentlich gilt immer, dass Backups regelmäßig überprüft werden sollten.

 

Ergänzung 27.04.2022: Nach der Aktualisierung von Paperless-NGX auf die heute veröffentlichte Version 1.7.0 kam folgender Fehler auf, der aber nur über die Docker Logs einsehbar war:

django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module: libpq.so.5: cannot open shared object file: No such file or directory

 

Da fehlt wohl ein Python-Modul im Docker, das lässt sich durch folgenden Befehl beheben:

docker exec paperless-ngx apt update ; docker exec paperless-ngx pip install psycopg2-binary && docker restart paperless-ngx

 

Danach startete Paperless-NGX wieder, aber beim Scannen wurde folgende Fehlermeldung in den Docker Logs geloggt:

ImportError: Unable to find zbar shared library

 

Das lässt sich durch folgenden Befehl beheben:

docker exec paperless-ngx apt update ; docker exec paperless-ngx apt-get install libzbar0 --yes && docker restart paperless-ngx

 

Das sollte nicht passieren, wird aber sicher mit dem nächsten Docker-Update behoben. Ein neues Update kurz nach Veröffentlichung zu ziehen, stellt eben immer ein gewisses Risiko dar.

 

Ergänzung 30.04.2022: Das Skript rclone_jobber archiviert die übertragenen Dateien per default selber, also reicht es natürlich aus vom rsync-Skript den jeweils letzten Stand zu übertragen. Damit der Cloud-Speicher nicht so schnell volläuft, habe ich den Parameter move_old_files_to bei mir aber auf nichts gesetzt, denn das lokale Backup reicht mir für die Backup-Historie aus.

 

Die zwei GB Speicher von Dropbox sind für heutige Verhältnisse etwas wenig, auch wenn man berücksichtigt dass das für die kostenlose Version gilt. Googles GDrive bringt kostenlos 15 GB Cloud-Speicher mit und funktioniert ebenfalls problemlos mit RClone.

 

Ich empfehle die Zugänge bei RClone mit selbst generierten API-Zugriffsschlüsseln einzurichten. Das muss man nicht machen, dann verwendet RClone vordefinierte Zugriffsschlüssel, die aber von jeder Installation verwendet werden und daher langsamer sind und angeblich auch schonmal auf ein Quota (Limit) stoßen können. Wie man die API-Schlüssel anlegt um Anwendungen für den eigenen Cloud-Speicher zu authentifizieren, kann man auf der RClone-Webseite einsehen (Google Drive, Dropbox).

 

Wer einen headless-Linuxserver (ohne grafische Oberfläche und damit ohne Webbrowser) benutzt kann bei der RClone-Konfiguration derzeit auf das Problem stoßen, dass der Aufruf des ausgegebenen Browser-Links auf dem Desktop-PC zu einem Error 400: Invalid Request-Fehler führt. Die Google-Entwickler haben die Google Drive OAuth-Authentifizierung geändert, das RClone-Team arbeitet gerade daran dass wieder zum Laufen zu bringen. Quelle im Forum: Link.

 

Ich habe es dann einfacher gefunden, die Konfiguration der Cloud-Speicher mit RClone auf meinem Desktop-PC abzuschließen. Im DOS-Fenster ruft man mit “rclone config” den Einrichtungsassistenten auf. Wenn man die Einstellungen abspeichert, liegt die RClone-Einstellungsdatei anschließend in C:\Users\$USER\AppData\Roaming\rclone und heißt rclone.conf. Diese Datei kann man dann über WinSCP auf den Server in das Verzeichnis /root/.config/rclone kopieren.

 

Das Cloud-Backup kann RClone bereits verschlüsselt übertragen, aber ich habe zusätzlich die ZIP-Archive mit einem Passwort verschlüsseln lassen. Mit zip ist das ja einfach möglich:

zip –P $Password –qr $Archive $Path && echo "success" || echo "failure" > ./logs/zip_mailserver.log

Die Logdatei wird nur erstellt wenn es beim Erstellen des Archivs einen Fehler gab. Der Grund des Fehlers wird dann nicht ausgegeben, aber in der Hinsicht ist zip auch nicht sehr mitteilsam.

 

Außerdem lasse ich das Backup nach Dropbox und GDrive zeitgleich hochladen, dazu erstelle ich zwei Skripte die ich dann so starten lasse:

nohup bash -c "bash backup_data_dropbox.sh >_dropbox.log" </dev/null &>/dev/null &

Quelle: Link.

Ich gebe die Bash-Shell beim Aufruf lieber mit an, als allein auf den Shebang im Skript zu setzen. Dann funktioniert das Skript auch wenn Ausführungsrechte auf die Datei fehlen.

 

Da RClone aber eh schon mit Multithreading arbeitet, scheint das nicht immer eine Verbesserung zu erzielen. Mein Server hat nur vier Kerne, irgendwann sind die auch ausgelastet und die Abarbeitung findet wieder sequentiell statt.

 

Die Versionsnummer des Paperless-NGX-Dockers kann man mit folgendem Befehl auslesen:

docker inspect -f '{{ index .Config.Labels "build_version" }}' paperless-ngx 

 

Ergänzung 09.05.2022: Wenn man eine Bash in einen Docker über den Befehl “docker exec” starten will, muss man den Parameter –it für den interaktiven Modus mit übergeben. Beim automatisierten Aufruf eines konkreteren (nicht-interaktiven) Befehls über einen Cronjob macht die Option dagegen weniger Sinn und verhindert sogar die korrekte Ausführung.

 

Ergänzung 11.06.2022: Wenn man seine Paperless-NGX-Instanz über das Internet verfügbar machen möchte, könnte vielleicht der 2 Faktor-Authentifizierungsserver Authelia interessant sein, ebenfalls Open Source-Software.

   

Tag-Wolke

Monats-Liste