Paperless-ngx Paperless-ngx Datensicherung

[plang.pl]

Den DB-Namen findest du in den Umgebungsvariablen des Paperless Containers

 

[Dog6574]

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

Hallo.

Kann jemand mir die Unterschiede zu meinem Script erklären:

cd /volume1/docker/paperlessngx/export
find -mtime +30 -delete
/usr/local/bin/docker exec Paperless-NGX-DB pg_dump -U paperless -c paperless > /volume1/docker/paperlessngx/backup/backup.sql

Ich kann mir es zwar denken aber irgendwie steige ich da noch nicht durch

Vorab Danke

 

[Monacum]

Bei mir wird die Datei gezippt (gzip >)und mit einem Datumsstempel versehen ($(date +%F_%a_%T_%Z)), bei Dir nicht, bei Dir heißt jede Datei backup.sql.

 

[Dog6574]

Hallo.

Ich bin nun weiter gekommen:

cd /volume1/docker/paperlessngx/export
find -mtime +30 -delete
/usr/local/bin/docker exec Paperless-NGX-DB pg_dump -U paperless -c paperless | gzip > /volume1/docker/paperlessngx/backup/backup_$(date +%F_%a_%T_%Z).sql.gz

Das Script erzeugt bei mir eine 7,3 MB große zip Datei.

Kann das von der Größe sein bei 3479 Dokumenten??

Gruß,

 

[plang.pl]

Ja, kann gut sein. Mein Dump ist 5,7 MB groß bei 600 Dokumenten. Is aber bei mir nicht komprimiert. Ist halt auch davon abhängig, wie viele Tags / Beschreibungen / Korrespondenten es gibt. Der Dump enthält ja nicht die Dokumente, sondern die dahinter hängende Struktur in paperless

 

[Frank73]

Mein Dump ist bei 3.021 Dokumente unkomprimiert ca. 22,1 MB groß.
Nutzung von 8 Tags, ca. 55 Korrespondenten, ca. 20 Dokumententypen und ca. 25 Speicherpfaden.

 

[Dog6574]

Hallo unkomprimiert war er bei mir auch 25 MB groß

 

[SabineFranke]

Guten Morgen,

ich häng mich hier mal mit dran.

Mein Plan zur Sicherung ist es, über "geplante Aufgaben" alle Container zu stoppen und dann alle Daten der Volumes mit Hyperbackup wegzusichern. Mit einer zweiten Aufgabe starte ich dann alle Conatiner wieder.

Klappt wunderbar, bis auf den Punkt, dass ich jedesmal eine Warnmail bekomme, dass mariadb unerwaretet beendet wurde.
Hab ich einen Denkfehler, oder muss ich mariadb anders "beenden"?

Danke und LG
Bine

Die geplante Aufgabe wird als root ausgeführt

docker stop paperlessngx-webserver-1
docker stop paperlessngx-broker-1
docker stop mariadb

Installationsinfo:

Portianer Stack auf Synology:

version: "3.4"
services:
  broker:
    image: docker.io/library/redis
    restart: always
    volumes:     
      - /volume1/docker/paperlessngx/redisdata:/data
 
  db:
    image: library/mariadb:latest
    container_name: mariadb
    restart: unless-stopped
    volumes:
      - /volume1/docker/paperlessngx/mariadb:/var/lib/mysql
    command:
      - "--character-set-server=utf8mb4"
      - "--collation-server=utf8mb4_unicode_ci"
    environment:
      TZ: Europe/Berlin
      MARIADB_HOST: paperless
      MARIADB_DATABASE: paperless
      MARIADB_USER: paperless
      MARIADB_PASSWORD: paperless
      MARIADB_ROOT_PASSWORD: supergeheim
 
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    restart: always
    depends_on:
      - db
      - broker
    ports:
      - 8080:8000
    healthcheck:
      test: ["CMD", "curl", "-fs", "-S", "--max-time", "2", "http://localhost:8000"]
      interval: 30s
      timeout: 10s
      retries: 5
    volumes:     
      - /volume1/docker/paperlessngx/data:/usr/src/paperless/data     
      - /volume1/docker/paperlessngx/media:/usr/src/paperless/media     
      - /volume1/paperlesstransfer/export:/usr/src/paperless/export
      - /volume1/paperlesstransfer/import:/usr/src/paperless/consume   
   
    environment:
      PAPERLESS_REDIS: redis://broker:6379
      PAPERLESS_DBENGINE: mariadb
      PAPERLESS_DBHOST: db
      PAPERLESS_DBPORT: 3306     
      USERMAP_UID: 1030
      USERMAP_GID: 100
      PAPERLESS_SECRET_KEY:megageheim
      PAPERLESS_TIME_ZONE: Europe/Berlin
      PAPERLESS_OCR_LANGUAGE: deu+eng
      PAPERLESS_ADMIN_USER: admin[/FONT]
      PAPERLESS_ADMIN_PASSWORD:strenggeheim

 

[plang.pl]

Wenn du den Container nicht über die DSM API stoppst, taucht dieser Fehler auf. Über die API stoppst und startest du ihn so:

synowebapi --exec api=SYNO.Docker.Container version=1 method=stop name=paperlessngx-webserver-1
synowebapi --exec api=SYNO.Docker.Container version=1 method=stop name=paperlessngx-broker-1
synowebapi --exec api=SYNO.Docker.Container version=1 method=stop name=mariadb

Zum Starten das "stop" halt durch "start" ersetzen

 

[Monacum]

Ich beende keine Container, um Hyper-Backup-Sicherungen durchzuführen.

 

[plang.pl]

Ich auch nicht. Ich gehe lieber auf einen Dump der DB. Wenn man nur das Verzeichnis sichert, sollte man aber die Container vorher anhalten.

 

[Frank73]

Ich auch nicht. Ich mache einen Dump von der DB und schreibe diesen in ein separates Verzeichnis. 1x die Woche sichere ich per HB alle Verzeichnisse dieses Shares, allerdings ohne das Verzeichnis in welchem die Datenbank liegt.

 

[Monacum]

Wenn man nur das Verzeichnis sichert, sollte man aber die Container vorher anhalten.

Mache ich, wie gesagt, nicht, bisher problemlos. Und alleine schon wegen der Experimente hin und wieder muss ich die Daten zurückspielen und schauen, dass es wieder funktioniert.

 

[plang.pl]

Es KANN dabei halt zu unbrauchbaren Infos der Datenbank kommen. Deshalb macht man ja den Dump. Relationale Datenbanken locken vor dem Dump die entsprechende Datenbank / Tabelle, damit das nicht passiert. Beim Kopieren des Ordners auf Dateisystemebene ist das nicht der Fall, weil die DB das ja gar nicht mitbekommt.

 

[Monacum]

Das ist mir bekannt. Ich wollte nur klarstellen, dass ich auch für Sicherungen über Hyper Backup (was die Ausgangsfrage war) keine Container anhalte.

 

[plang.pl]

Wenn man beim Hyper Backup den Dump wegsichert, ist das auch so in Ordnung. Nur nicht, wenn man halt das Dateisystem als einziges sichert

 

[Monacum]

Das ist mir so zu pauschal. Das Dateisystem enthält bei korrekter Anlage gemäß Anleitung auch die Datenbank, so dass ich beim Zurückspielen alle Daten wieder am Ort habe und man muss nicht pauschal einen Dump einspielen, damit das ganze wieder läuft – musste ich zum Beispiel noch nie. Worauf du zurecht hinweist, ist, dass es natürlich sein kann, dass wenn gerade bei der Sicherung in die Datenbank geschrieben wird, da bei der Sicherung Inkonsistenzen auftreten und dann bringt dir die Sicherung nichts mehr ohne den Dump.

Mir geht es darum, dass für viele Benutzer, egal wie sie Paperless-ngx installiert haben, die Sicherung über Hyper Backup, also mit Bordmitteln, die einfachste Möglichkeit darstellt, auch bei einem Problem mit ihrer Disk Station schnell und einigermaßen unkompliziert wieder an ihre Daten zu kommen, ohne sich Gedanken machen zu müssen, wie sie jetzt über das Terminal Daten in eine Datenbank schreiben lassen. Entweder hat man eine Konfigurationsdatei oder die meisten nutzen ohnehin aus meinem Gefühl heraus Portainer. Dann noch die Daten wieder an Ort und Stelle kopiert und in den überwiegenden Fällen: fertig.

Ich erstelle die beiden anderen Sicherungen (Dump und über den Exporter, auch wenns nur teilweise ist) schon alleine deswegen, weil das noch mal zwei völlig andere Wege sind, die Daten zu sichern und sollte es bei der einen oder anderen Sicherung des einen Tipps ein Problem geben, dann ist die Wahrscheinlichkeit sehr gering, dass das Ganze auch noch mal woanders auftritt.

 

[cplex]

... Mein Skript lautet

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

...
3. erstellt den Dump, der Dateiname wird über den Teil „$(date +%F_%a_%T_%Z)“ aus dem Zeitstempel erstellt

hänge mich auch einmal rein, mit meinem Versuch ein Dump-Skript auszuführen:

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

erzeugt leider ein No such file or directory

bash: line 1: /volume1/docker/paperless-ngx/export/backup-db/pg_dumpall_2024-04-17_Wed_06:06:19_CEST.dump.gz: No such file or directory

Ordner existieren und Skript führe ich auch als root aus.

Kann mich jemand in die richtige Richtung schubsen?

 

[Dog6574]

ich werde das mal mit einer einfachen Rücksicherung auf meiner virtuellen DSM testen zur Not habe ich den Dump ja auch noch

 

[cplex]

Vielleicht hat hier (Post #98) doch noch jemand eine zündende Idee...

Beste Grüße!
Christian