Paperless-ngx Paperless-ngx Datensicherung

[alexhell]

@plang.pl hat dir zwar schon die Antwort geliefert, aber es wäre leichter wenn man direkt beim Hersteller mal guckt wie es installiert wird.

-p 8000:8000 \
-p 9000:9000 \

Diese Ports werden schon länger nicht mehr so verwendet.
8000 ist nur nötig, wenn du Edge Agents nutzen willst (Falls du wissen willst was es ist, musst du googeln)
9000 ist der HTTP Port und sollte auch nicht verwendet werden laut Portainer. Ist nur Legacy. Man sollte 9443 wie @plang.pl dir schon geschrieben hat verwenden.
Kann dir nur empfehlen statt Youtube Video anzugucken mal beim Hersteller die Doku zu lesen. Dann hat man auch keinen alten Krempel.

Edit: Wofür brauchst du aber für die Sicherung der DB Portainer?

 

[Furchensumpf]

Ich hatte das hier so verstanden, dass ich den dafür brauche...Backup der Dateien per Hyperbackup (würde das eigentlich auch mit jedem anderem Backup-Prog gehen?) und Portainer für die zusätzliche DB-Sicherung, weil die mit Hyperbackup wegen der GEfahr, dass während der Sicherung etwas in die DB geschrieben wird, etwas "unsicher" ist.

 

[plang.pl]

würde das eigentlich auch mit jedem anderem Backup-Prog gehen?

Jap.

weil die mit Hyperbackup wegen der GEfahr, dass während der Sicherung etwas in die DB geschrieben wird, etwas "unsicher" ist

Ja so ist das. Portainer hilft dir dabei aber nicht, sondern ein Script, welches einen sog. Dump der DB erzeugt. Dabei wird quasi die Datenbank für Schreibzugriffe geblockt und exportiert, sodass die Sicherung konsistent ist. Erst nach Abschluss dieses Dumps wird die Datenbank (bzw. eigentlich nur die betroffene Tabelle) wieder für Schreibzugriffe freigegeben.

 

[alexhell]

Portainer ist nur eine UI für Docker. Das braucht man nicht dafür. Schon gar nicht, wenn man die Sicherung automatisiert machen will.
Womit du die Ordner sicherst ist dir überlassen. Du musst dafür kein Hyper Backup nutzen.

 

[Furchensumpf]

So kann man auch seine Lebenszeit verschwenden....;-)

Ich würde für die Sicherung gerne das Script von Monacum nutzen, komme aber mit der Anpassung an manchen Stellen nicht weiter. Die docker-compose.yml gibt folgendes her:

version: "3.8"
services:
  broker:
    image: docker.io/library/redis:7
    restart: unless-stopped
    volumes:
      - ./volumes/redis:/data

  db:
    image: docker.io/library/mariadb:10
    restart: unless-stopped
    volumes:
     - ./volumes/database:/var/lib/mysql
    environment:
      MARIADB_HOST: paperless
      MARIADB_DATABASE: paperless
      MARIADB_USER: paperless
      MARIADB_PASSWORD: paperless
      MARIADB_ROOT_PASSWORD: paperless

  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: unless-stopped
    depends_on:
      - db
      - broker
    ports:
      - "8000:8000"
    volumes:
      - ./volumes/data:/usr/src/paperless/data
      - ./volumes/media:/usr/src/paperless/media
      - ./volumes/export:/usr/src/paperless/export
      - ./incoming:/usr/src/paperless/consume
    env_file: docker-compose.env
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBENGINE: mariadb
      PAPERLESS_DBHOST: db
      PAPERLESS_DBUSER: paperless
      PAPERLESS_DBPASS: paperless
      PAPERLESS_DBPORT: 3306
      PAPERLESS_OCR_LANGUAGES : deu
      PAPERLESS_TIME_ZONE : Europe/Berlin
      PAPERLESS_FILENAME_FORMAT : "{correspondent}/{created_year}/{title}"

Daraus lese ich, dass als DB MariaDB verwendet wird und der Name der DB paperless ist. Der Container für die DB nennt sich zudem paperless-db-1.

Habe das Script jetzt so angepasst:

cd /volume1/paperless/db-backup
find -mtime +28 -delete
docker exec paperless-db-1 bash -c "pg_dumpall -U paperless | gzip > /var/lib/mysql/data/backup/pg_dumpall_$(date +%F_%a_%T_%Z).dump.gz"

Aber da muss noch was falsch sein, ich bekomme diese Fehlermeldung:

bash: line 1: pg_dumpall: command not found
bash: line 1: /var/lib/mysql/data/backup/pg_dumpall_2024-05-07_Tue_20:27:28_CEST.dump.gz: No such file or directory

Könnte da mal jemand drüberschauen? Mein Dank wird ihm auf ewig hinterherschleichen...;-)

 

[plang.pl]

Der Befehl von @Monacum bezieht sich auf postgres. Das geht bei MariaDB nicht. Ich verwende da folgendes Script:

docker exec mariadb mariadb-dump -u USER --password=PASSWORD paperless > /volume1/docker/mariadb/backup/paperless_$(date +%Y-%m-%d_%H-%M).sql
#Bereinigung
find /volume1/docker/mariadb/backup -name "*.sql" -mtime +7 -exec rm {} \;

EDIT: Volume-Fehler behoben.

 

[alexhell]

pg_dump ist PostgreSQL. Diese funktionieren natürlich nicht bei MariaDB. Du musst das schon anpassen.

Edit: @plang.pl war wieder schneller

 

[Furchensumpf]

Das hat funktioniert...

Supervielen Dank für die Hilfe!

 

[plang.pl]

Gerne. Ich bin der Meinung, dass man grundsätzlich mit MariaDB besser fährt als mit postgres.
Und ich würde empfehlen, dass du die Wiederherstellung einmal in einer Testumgebung (z.B. vDSM) testest, damit du im Bedarfsfall weißt wie und ob es überhaupt funktioniert.

EDIT: Und schau dir nochmal die letzte Zeile an zur Bereinigung, da stand in meinem Post noch /volume2/ das musst du vielleicht noch anpassen.

 

[alexhell]

. Ich bin der Meinung, dass man grundsätzlich mit MariaDB besser fährt als mit postgres.

Dem würde ich nicht zustimmen. Das hängt sehr von der Anwendung ab. Ich setze komplett bei allem auf PSQL wenn es geht. Sowohl beim hosten oder wenn ich selber was entwickle. Für mich ist es die bessere DB.

 

[plang.pl]

Naja, das ist vermutlich Geschmackssache oder wie du sagst, halt Anwendungssache. Grundsätzlich hat mich überzeugt, dass es bei Updates keine Probleme gibt.

 

[Kenji]

Mitunter empfehle ich folgendes Tutorial von SemperVideo für das Export/Import, mitunter für das meiste passend. Je nach Anleitung müssen halt die Namen angepasst werden.

SemperVideo Export/Import

 

[Furchensumpf]

Ich habe gestern noch das erste Backup (Cobian Backup) versucht, dabei ist folgende Fehlermeldung aufgetreten:

ERR 2024-05-08 07:35 Datei "\\DS218PLUS\paperless\volumes\database\.my-healthcheck.cnf" konnte nicht kopiert werden: Zugriff verweigert
ERR 2024-05-08 07:35 Datei "\\DS218PLUS\paperless\volumes\database\aria_log.00000001" konnte nicht kopiert werden: Zugriff verweigert
ERR 2024-05-08 07:35 Datei "\\DS218PLUS\paperless\volumes\database\aria_log_control" konnte nicht kopiert werden: Zugriff verweigert
ERR 2024-05-08 07:35 Datei "\\DS218PLUS\paperless\volumes\database\ibdata1" konnte nicht kopiert werden: Zugriff verweigert
ERR 2024-05-08 07:35 Datei "\\DS218PLUS\paperless\volumes\database\ib_logfile0" konnte nicht kopiert werden: Zugriff verweigert
ERR 2024-05-08 07:35 Datei "\\DS218PLUS\paperless\volumes\database\multi-master.info" konnte nicht kopiert werden: Zugriff verweigert

Sind die Dateien "wichtig" für die Wiederherstellung?

Besten dank schon mal

 

[Monacum]

Das kann ich dir nicht sagen, die Frage ist eher, warum da der Zugriff verweigert wurde.

 

[alexhell]

Probier es doch einfach aus. Einfach eine zweite Instanz aufsetzen. Wenn paperless InnoDB verwendet dann ist die Datei wichtig. Wenn MyISAM verwendet wird, dann dürfte die Datei dafür nicht relevant sein.
Ich würde aber eher gucken, dass dein Backup Programm Zugriff auf die Dateien bekommt

Edit: Ich würde mich auch auf keine Aussage wie "Klar, das wird schon funktionieren" in einem Forum blind verlassen. Wenn derjenige sich irrt, dann ist im schlimmsten Fall alles weg. Daher immer selber ausprobieren und nicht blind auf irgendwas verlassen. Man selber kann ja auch einen Fehler machen und es lässt sich nicht zurück spielen.

 

[NSFH]

Lese mich gerade erst in PNGX ein, aber ein typisches Problem beim Backup oder Restore von Serverdatenbanken ist der laufende Betrieb. Solche Programme sollten für das Backup immer pausiert/beendet werden um Inkonsistenten oder parallel stattfindende Zugriffe zu vermeiden.

 

[alexhell]

Bei PSQL ist das kein Problem: Siehe hier

Dumps created by pg_dump are internally consistent, that is, updates to the database while pg_dump is running will not be in the dump. pg_dump does not block other operations on the database while it is working. (Exceptions are those operations that need to operate with an exclusive lock, such as VACUUM FULL.)

Wie es bei MariaDB genau ist weiß ich nicht so genau. Glaube aber, da wäre es gut wenn man -single-transaction als Parameter angeben würde. Dann würde die DB eine Transaktion starten und einen kurzen Lock für die Tabellen setzen. Dies geht aber nur bei InnoDB. Laut Doku stellt das ebenfalls sicher, dass es nicht zu Inkonsistenten Dumps kommt.

 

[Furchensumpf]

Das lässt sich dann aber nicht automatisieren.

Habe es gerade mal mit aktiviertem Volume Shadow Copy versucht, hat aber leider auch nichts gebracht. Wenn ich den Ordner so kopieren will, bekomme ich bei den Dateien die Meldung, dass ich die erforderlichen Rechte vom "Administrator des Computers" erhalten muss. An den generellen Rechten kann es aber nicht liegen, die sind gegeben.

 

[alexhell]

Guck doch mal in der Filestation oder mit SSH wem die Dateien gehören. Ich kenne dein Backup Programm nicht, aber es aussieht hat es nicht die Rechte für die Datei. Als welcher User machst du denn das Backup?

 

[Furchensumpf]

Die Meldung kommt ja auch beim normalen Kopiervorgang über den Explorer - und da bin ich mit entsprechenden Rechten ausgestattet.

In der Filestation wird mir als Besitzer zunächst "999" angezeigt - aber selbst ein Ändern auf den Nutzer, mit dem ich vom Rechner aus auf die DS zugreife, bringt keinen Unterschied.