b_tob

What Filesystem has the server at your Remote Location? Have a look at the "Warnings" section of the very first post in this thread from mgutt, some filesystems do not support Hardlinks.

looks like you have a typo in your command, its "appdata", not "appadata"

You may wanna have a look at this

@Mark Augustin I have 5 Keys registered in my Vaultwarden, 3 Yubikey 5C NFC, 1 Token2 Dual and 1 Token2 mini. Everything works like a charm. Are there any infos in the container logs?

@Cannon Ich glaube SMB unterstützt keine Hardlinks, siehe hier. Am besten schaust du mal den Englischen Thread durch, dort sollten Lösungen beschrieben sein.

Hi everyone I have a problem with the Barcode Splitting functionality. In the Docker settings, I enabled the following variables: PAPERLESS_CONSUMER_ENABLE_BARCODES: PAPERLESS_CONSUMER_BARCODE_STRING: I then tried to scan the documents with a PATCH T barcode, and with a QR code i found on this page: https://github.com/paperless-ngx/paperless-ngx/discussions/2678 With the PATCH T code, i entered "PATCHT" in the barcode string variable, with the QR Code i entered "paperless:separator". I then tested with 2 documents, but the strange thing is that paperless only consumes the first document, the second document is nowhere. In the Docker Logs i can see the following: [2024-12-09 17:20:16,859] [INFO] [paperless.management.consumer] Adding /usr/src/paperless/consume/Document_20241209_0001.pdf to the task queue. [2024-12-09 17:20:16,922] [INFO] [celery.worker.strategy] Task documents.tasks.consume_file[02aec755-4ab6-4221-ada6-b89bd79c0788] received [2024-12-09 17:20:18,446] [INFO] [celery.worker.strategy] Task documents.tasks.consume_file[c27d131f-bb0b-45f2-8682-e2376af5a181] received [2024-12-09 17:20:18,446] [INFO] [paperless.barcodes] Created new task c27d131f-bb0b-45f2-8682-e2376af5a181 for Document_20241209_0001_document_0.pdf [2024-12-09 17:20:18,461] [INFO] [paperless.barcodes] Created new task e9a17693-f4d1-4581-b9df-196897d315c9 for Document_20241209_0001_document_1.pdf [2024-12-09 17:20:18,464] [INFO] [paperless.tasks] BarcodePlugin requested task exit: Barcode splitting complete! [2024-12-09 17:20:18,479] [INFO] [celery.app.trace] Task documents.tasks.consume_file[02aec755-4ab6-4221-ada6-b89bd79c0788] succeeded in 1.5541348340921104s: 'Barcode splitting complete!' [2024-12-09 17:20:19,681] [INFO] [paperless.tasks] BarcodePlugin completed with no message [2024-12-09 17:20:19,684] [INFO] [paperless.tasks] WorkflowTriggerPlugin completed with: [2024-12-09 17:20:19,692] [INFO] [paperless.consumer] Consuming Document_20241209_0001_document_0.pdf [2024-12-09 17:20:19,708] [INFO] [paperless.parsing.tesseract] pdftotext exited 0 [2024-12-09 17:20:20,939] [INFO] [ocrmypdf._pipeline] page is facing ⇧, confidence 8.90 - no change [2024-12-09 17:20:22,979] [INFO] [ocrmypdf._pipelines.ocr] Postprocessing... [2024-12-09 17:20:24,901] [INFO] [ocrmypdf._pipeline] Image optimization ratio: 1.00 savings: 0.0% [2024-12-09 17:20:24,902] [INFO] [ocrmypdf._pipeline] Total file size ratio: 0.27 savings: -270.2% [2024-12-09 17:20:24,904] [INFO] [ocrmypdf._pipelines._common] Output file is a PDF/A-2B (as expected) [2024-12-09 17:20:25,624] [INFO] [paperless.parsing] convert exited 0 [2024-12-09 17:20:26,090] [INFO] [paperless.handlers] Assigning correspondent "redacted" to 2022-12-29 Document_20241209_0001_document_0 [2024-12-09 17:20:26,095] [INFO] [paperless.handlers] Assigning document type Rechnung to 2022-12-29 "redacted" Document_20241209_0001_document_0 [2024-12-09 17:20:26,191] [INFO] [paperless.consumer] Document 2022-12-29 "redacted" Document_20241209_0001_document_0 consumption finished [2024-12-09 17:20:26,193] [INFO] [paperless.tasks] ConsumeTaskPlugin completed with: Success. New document id 109 created [2024-12-09 17:20:26,206] [INFO] [celery.app.trace] Task documents.tasks.consume_file[c27d131f-bb0b-45f2-8682-e2376af5a181] succeeded in 7.4470139590557665s: 'Success. New document id 109 created' As far as i understand, the Barcode is being recogniszed, the first document is consumed and created, but with the second document, theres nothing happenig. Does anyone have an idea why this is happening? thank you!

Nachdem ich nun im Script beide Pfade von Usershare auf Diskshare umgestellt habe dauert der Kopiervorgang nur noch etwa 15-20 Minuten.

Wie sieht dieses Script aus? Das Backupscript funktioniert eigentlich einwandfrei, nur das Kopieren auf den Backupserver nicht. Ich benutze dazu wie gesagt den rsync Befehl mit der Option -H: #!/bin/bash # Konfiguration QUELL_SERVER="[email protected]" QUELL_ORDNER="/mnt/cache/inc_backup" ZIEL_ORDNER="/mnt/user/ZEUS" # rsync-Aufruf rsync -avH --delete --chmod=ugo=rwX --rsync-path="mkdir -p $ZIEL_ORDNER && rsync" "$QUELL_SERVER:$QUELL_ORDNER" "$ZIEL_ORDNER" So wird der Ordner auf dem Server B mit dem Ordner auf dem Server A abgeglichen, sprich wenn ein Backup auf Server A entfernt wird (Aufbewahrungszeit vorbei) wird es auch auf Server B gelöscht.

Also vielleicht nochmal zur Klarstellung, ich möchte eigentlich auf Server A das Script laufen lassen und appdata von Server A sichern, anschliessend auuf Server B ein anderes Script ausführen welches die Backups von Server A abholt. Das Script von @mgutt funktioniert auf Server A auch ohne Probleme, nur wenn ich dann auf Server B das rsync Script ausführe dauert es Stunden bis alles kopiert ist, auch wenn es nur inkrementell kopieren müsste. Im rsync Befehl habe ich die Option -H eingefügt, so sollten Hardlinks übernommen werden, und nicht jeweils alle Files komplett wieder kopiert werden. Aber auch mit dieser Option dauert der Kopiervorgang mehrere Stunden. Auf den Hinweis von jj1987 habe ich dann das Script auf Server B ausgeführt, dies stoppt aber die Docker auf Server A nicht, im Script steht auch dass das per SSH aktuell noch nicht funktioniert. Zusammenfassend: Ich möchte die inkrementellen Backups von Server A auf Server B und auch Server C kopieren, aufgrund der Dauer von mehreren Stunden ist dies aber nicht praktikabel. Fullbackups, welche mit dem appdata Backup Plugin erstellt wurden kopiere, dauert das ein paar Minuten, braucht aber auch ein vielfaches an Speicherplatz. Ich denke daher dass entweder bei meinem rsync Befehl ein Problem mit den Hardlinks besteht oder der Server B vielleicht zu wenig Leistung hat, da beim Kopiervorgang der inkrementellen Backups die CPU auf 100% ist.

Danke für den Input, habe das mal getestet, leider werden die Docker Container nicht gestoppt bevor das Backup erstellt wird. Wenn man das Script lokal ausführt wird ein Snapshot vom appdata Ordner erstellt, dies funktioniert gemäss Hinweis im Script leider noch nicht per SSH, daher möchte ich es nicht auf dem Server B ausführen.

Wenn du im VM Reiter auf den Namen der VM klickt solltest du die Disk erweitern können:

Vielleicht noch ein paar genauere Angaben: Ich führe auf Server A das Backup Script von dir @mgutt aus, welche inkrementelle Backups erstellt, diese werden auf dem Cache abgelegt. Nun möchte ich diese auf Server B übertragen, dazu habe ich SSH Keys der beiden Server ausgetauscht damit ein Login ohne Passwort funktioniert. Nun wird auf Server B, auf welchen die Backups kopiert werden sollen, das oben genannte Script ausgeführt, welches die Backups von Server A abholt (192.168.1.193 ist Server A, 192.168.1.120 wäre Server B). Diese Variante zum kopieren habe ich bisher benutzt und die Backups, welche mit Hilfe des appdata Backup Plugin erstellt wurde, auf Server B zu kopieren. Dies hat jeweils nur paar minuten gedauert. Wenn ich das Script nun aber die bereits erstellten inkrementellen Backups kopieren lassen will, steht im Log jeweils für mehrere Stunden "receiving incremental file list". Zuerst habe ich den Fehler gemacht und die Option "-H" nicht eingefügt, darum wurden die Hardlinks nicht berücksichtig und es hat jedes Backup als Fullbackup kopiert. Aber auch mit der Option -H dauert es immer noch Stunden. Ich weiss nicht ob es nicht anders möglich ist, weil mit Hardlinks gearbeitet wird, oder ob ich einen (Denk)Fehler mache. Wie würden dann die Pfade lauten? Müsste man direkt die Disk angeben, also in meinem Fall /mnt/disk3/...? Wie muss man vorgehen wenn ein Share nicht nur auf einer Platte liegen würde?

Hallo zusammen ich habe ein Problem mit der Übertragung meiner Backups. Jeweils am Morgen um 04:00 Uhr wird mittels des Backupscripts von @mgutt eine Sicherung erstellt. Nun möchte ich diese Backups mit rsync auf meine anderen Server übertragen. Bisher habe ich die Sicherungen mit dem Appdata Backup Plugin erstellt und dann wegkopiert, einmal auf einen Server bei mir zu Hause und einmal per VPN zu meinen Eltern. Die Übertragun hat jeweils nur ein paar Minuten gedauert. Wenn ich nun die Backups, welche mit dem Script erstellt wurden, wegkopieren will, dauert dass Stunden. Gestern waren 12 Backups in dem Ordner, diese auf den Server im gleichen Netzwerk zu kopieren hat fast 24 Stunden gedauert. Nachdem heute morgen ein neues Backup erstellt wurde habe ich etwa um 8 Uhr den rsync Befehl manuell ausgeführt, diesmal hat das Kopieren etwa 8 Stunden gedauert. Ich sichere mit dem Script meinen appdata, boot und nextcloud Ordner, auf dem Cache belegen die Ordner etwa 67GB. Das Script, welches ich benutze und bisher anstandslos funktioniert hat, sieht wie folgt aus (erstellt mit Hilfe von ChatGPT): #!/bin/bash # Konfiguration QUELL_SERVER="[email protected]" QUELL_ORDNER="/mnt/cache/inc_backup" ZIEL_ORDNER="/mnt/user/ZEUS" # rsync-Aufruf rsync -avH --delete --chmod=ugo=rwX --rsync-path="mkdir -p $ZIEL_ORDNER && rsync" "$QUELL_SERVER:$QUELL_ORDNER" "$ZIEL_ORDNER" # Benachrichtigung an Unraid Dashboard senden /usr/local/emhttp/webGui/scripts/notify -e "Backup abgeschlossen" -s "Das Backup von appdata ZEUS wurde erfolgreich durchgeführt." Weiss jemand wieso die Übertragung inkrementeller Backups so lange dauert? Würde es Sinn machen mit dem Script direkt auf den Remoteserver zu sichern? Können mehrere Ziele im Script angegeben werden? Besten Dank für eure Hilfe.

Reboot hat geholfen, die Shares sind wieder da! Besten Dank!

Okay, wusste nicht ob es eventuell eine blöde Idee ist neu zu starten, daher habe ich damit noch gewartet. Werde somit nachher den Server mal rebooten.