March 4, 20251 yr Moin, ich hol mal ein bisschen weiter aus, vielleicht lässt sich das Problem dann ja auch schon an einer anderen Stelle lösen. Ich teste gerade Backupstrategien für meinen Unraid Server (7.0.0) Bisher hatte ich meine Backups mit dem Appdata Backup Plugin auf ein WD NAS gesichert. Das NAS ist über SMB Shares in Unraid gemountet, es gibt noch weitere Shares für das Nextcloud AIO eigene Backup und für die iobroker backups. Das hat soweit auch immer gut funktioniert. Jetzt wollte ich mich aber doch mal um ein weiteres ausgelagertes Backup kümmern, dafür habe ich mich für Duplicacy in Verbindung mit iDrive e2 entscheiden. Da das Appdata Backup Plugin aber alles in Archive verpackt, macht das mit inkrementellen backups keinen Sinn, so würden ja jedesmal alle Daten neu in den Cloud Speicher geschoben. Bin dann auf das zfs snapshot & replication Skript von SpaceinvaderOne gestoßen, damit lasse ich jetzt Appdata und meine wichtigen Datasets mit rsync auf das WD NAS sichern. Das funktioniert schon mal ganz gut. Jetzt sichere ich mit Duplicacy den gesamten Ordner vom NAS in den rsync die Daten geschoben hat auf iDrive e2. Auch das funktioniert eigentlich ganz gut, aber... Im Log finde ich sehr viele permission denied und cannot be opened Meldungen, in Summe 157 Verzeichnisse und 2714 Dateien. Hier mal ein kurzer Auszug aus den logs: 2025-03-04 11:28:14.683 WARN LIST_FAILURE Failed to list subdirectory cache_system/2025-03-03_0245/docker/: readdirent /data/cache_system/2025-03-03_0245/docker: permission denied 2025-03-04 11:28:14.798 WARN LIST_FAILURE Failed to list subdirectory cache_system/2025-03-03_0918/docker/: readdirent /data/cache_system/2025-03-03_0918/docker: permission denied 2025-03-04 11:28:14.886 WARN LIST_FAILURE Failed to list subdirectory cache_system/2025-03-03_1038/docker/: readdirent /data/cache_system/2025-03-03_1038/docker: permission denied 2025-03-04 11:28:15.353 WARN OPEN_FAILURE Failed to open file for reading: open /data/rsyncd.secrets: permission denied 2025-03-04 11:28:15.415 WARN OPEN_FAILURE Failed to open file for reading: open /data/cache_appdata/2025-03-03_0010/ApacheGuacamole/databases/ddl_recovery-backup.log: permission denied 2025-03-04 11:28:15.454 WARN OPEN_FAILURE Failed to open file for reading: open /data/cache_appdata/2025-03-03_0010/ApacheGuacamole/databases/ddl_recovery.log: permission denied Hier scheint es wohl ein rechte Problem zu geben. ich habe dann die Permission Variablen im duplicacy Docker angepasst: PUID:0 PGID:0 UMASK:002 aber auch das brachte keine Verbesserung. Dann hatte ich die Idee, einfach nach dem rsync der Daten, einmal alle rechte mittels newperms neu zu setzten, aber auch das brachte für die Verzeichnisse immer ein Operation not permitted, trotz root rechten. Habe mit dann mal ein einzelnes Verzeichnis rausgesucht, zufällig von duplicacy selber, hier die Ausgabe von newperms: root@Unraid:/# sudo /usr/local/sbin/newperms /mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/ Processing: /mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/ ... chown -R nobody:users chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/bin': Permission denied chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/cache/localhost': Permission denied chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/filters': Permission denied chown: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/stats': Permission denied ... chmod -R go-rwx,u-x,go+u chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/bin': Permission denied chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/cache/localhost': Permission denied chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/filters': Permission denied chmod: cannot read directory '/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/stats': Permission denied ... find -type d -exec chmod 777 {} \; find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/bin’: Permission denied find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/cache/localhost’: Permission denied find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/filters’: Permission denied find: ‘/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy/stats’: Permission denied ... sync Completed, elapsed time: 00:00:04 und so sehen die Rechte im Ordner aus: root@Unraid:/mnt/remotes/172.30.2.21_duplicacy/cache_appdata/2025-03-03_1033/duplicacy# ls -lah /bin/ls: duplicacy.json: Permission denied /bin/ls: keyring: Permission denied /bin/ls: licenses.json: Permission denied /bin/ls: bin: Permission denied /bin/ls: filters: Permission denied /bin/ls: stats: Permission denied total 20K drwxrwxrwx 2 nobody users 0 Mar 2 19:30 ./ drwxrwxrwx 2 nobody users 0 Mar 2 22:03 ../ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 bin/ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 cache/ -rwxrwxrwx 1 nobody users 3.0K Mar 2 19:30 duplicacy.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:39 filters/ -rwxrwxrwx 1 nobody users 171 Mar 2 17:15 keyring* -rwxrwxrwx 1 nobody users 1.1K Mar 2 17:43 licenses.json* -rwxrwxrwx 1 nobody users 33 Mar 2 17:13 machine-id* -rwxrwxrwx 1 nobody users 144 Mar 2 17:13 settings.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:13 stats/ Sind doch eigentlich für alle lese und schreibrechte vergeben (lesen sollte im fall duplicacy -> idrive eigentlich sogar reichen) mal von diesen Permission denied Meldungen von ls abgesehen. Ich bin jetzt über ssh direkt auf das NAS und habe mir dort die Rechte für den selben Ordner angesehen: root@backup duplicacy # ls -hla drwxrwxr-x 6 nobody netdev 4.0K Mar 2 19:30 . drwxrwxrwx 30 nobody netdev 4.0K Mar 2 22:03 .. drwx------ 2 nobody netdev 4.0K Mar 2 17:13 bin drwxrwxr-x 3 nobody netdev 4.0K Mar 2 17:13 cache -rw------- 6 nobody netdev 2.9K Mar 2 19:30 duplicacy.json drwx------ 3 nobody netdev 4.0K Mar 2 17:39 filters -rw------- 7 nobody netdev 171 Mar 2 17:15 keyring -rw------- 7 nobody netdev 1.0K Mar 2 17:43 licenses.json -rw-rw-r-- 7 nobody netdev 33 Mar 2 17:13 machine-id -rw-rw-r-- 7 nobody netdev 144 Mar 2 17:13 settings.json drwx------ 4 nobody netdev 4.0K Mar 2 17:13 stats sieht schon garnicht mehr so richtig aus. habe die Rechte jetzt direkt über ssh auf dem NAS für den gesamten share auf rwx gesetzt chmod -R 777 /shares/duplicacy/ Duplicacy läuft jetzt ohne Fehler sauber durch. Aber macht das Sinn? Ich bin ja kein Freund von so großzügigem Rechte verteilen, hat ja bestimmt auch einen Grund. Klar ein chmod -R 644 hätte wahrscheinlich auch gereicht, aber war ja erstmal nur zum testen. Hat jemand eine Idee warum die Rechte auf dem NAS anders sind wie wenn ich über den SMB Share darauf zugreife? Wie löse ich das Problem am saubersten? Muss ich bei Rsync noch weitere Parameter angeben? Liegt es an den Shares und Rechte Einstellungen des WD NAS? Oder habt ihr einen anderen Vorschlag für meine Backupstrategie? Grüße Michi Edited March 4, 20251 yr by Michael Lanzl
March 6, 20251 yr Hast du es mal mit Privilegierte Rechte auf ein versucht? Ich hatte das Theater mit duplicati ebenfalls. Aber bei meinen Tests ist duplicati mit wehenden Fahnen durchgefallen. Habe ein Testbackup gemacht ca. 3 GB. Zurückgelesen (dauerte ewig) dann habe ich beim zweiten Versuch den duplicati Ordner aus appdata absichtlich gelöscht. Was für ein Chaos. Nichts ging mehr. duplicati wollte die Datenbank neu aufbauen und nach 12 Stunden habe ich es dann abgebrochen. Ein Backup welches von Dateien wie z.B. einer Datenbank abhängig ist das ist kein Backup. Habe mir jetzt einen Docker mit Borgbackup gemacht. Das läuft ohne Probleme. Hatte ich früher schon einmal.
March 6, 20251 yr Author Hey, danke für deine Antwort. Das habe ich tatsächlich noch nicht Probiert, würde das auch gerne vermeiden. Von duplicati habe ich schon einige negative Sachen gelesen wenns um's zurückspielen der Backups ging, deswegen bin ich erstmal auf Duplicacy gegangen. Borgbackup sieht auch interessant aus, spielt aber soviel ich auf die Schnelle gesehen habe nicht mit meinem Cloudspeicher. Ich habe zwischenzeitlich ein bisschen weiter getestet. Ich habe mir mal den rsync Befehl aus dem Skript genommen und für einen Test umgestrickt: rsync -azvh -e ssh /mnt/cache/appdata/duplicacy/.zfs/snapshot/autosnap_2025-03-06_11\:08\:37_daily/ sshd@172.30.2.21:/shares/duplicacy/test1/ im Original kommt halt noch --delete und --link-destination für die Hardlinks dazu, aber das brauchen wir für den test ja nicht. Wichtig, die Rechte Optionen sind identisch. Als erste einmal die Rechte und Owner im Original Ordner: root@Unraid:/mnt/cache/appdata/duplicacy/.zfs/snapshot/autosnap_2025-03-06_11:08:37_daily# ls -hla total 43K drwxrwxr-x 7 root root 12 Mar 6 00:46 ./ drwxrwxrwx 9 root root 2 Mar 6 11:20 ../ drwx------ 3 nobody users 4 Mar 5 22:42 bin/ drwxrwxr-x 3 root root 3 Mar 2 17:13 cache/ -rw------- 1 root root 4.3K Mar 6 00:46 duplicacy.json drwx------ 3 nobody users 3 Mar 2 17:39 filters/ -rw------- 1 nobody users 171 Mar 2 17:15 keyring -rw------- 1 nobody users 1.1K Mar 2 17:43 licenses.json drwxrwxr-x 3 root root 15 Mar 6 00:40 logs/ -rw-rw-r-- 1 nobody users 33 Mar 2 17:13 machine-id -rw-rw-r-- 1 nobody users 144 Mar 2 17:13 settings.json drwx------ 4 nobody users 4 Mar 2 17:13 stats/ Ergebnis des rsync über ssh: root@Unraid:/mnt/remotes/172.30.2.21_duplicacy/test1# ls -hla /bin/ls: bin: Permission denied /bin/ls: filters: Permission denied /bin/ls: logs: Permission denied /bin/ls: stats: Permission denied /bin/ls: duplicacy.json: Permission denied /bin/ls: keyring: Permission denied /bin/ls: licenses.json: Permission denied total 24K drwxrwxrwx 2 nobody users 0 Mar 6 00:46 ./ drwxrwxrwx 2 nobody users 0 Mar 6 21:50 ../ drwxrwxrwx 2 nobody users 0 Mar 5 22:42 bin/ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 cache/ -rwxrwxrwx 1 nobody users 4.3K Mar 6 00:46 duplicacy.json* drwxrwxrwx 2 nobody users 0 Mar 6 21:50 filters/ -rwxrwxrwx 1 nobody users 171 Mar 2 17:15 keyring* -rwxrwxrwx 1 nobody users 1.1K Mar 2 17:43 licenses.json* drwxrwxrwx 2 nobody users 0 Mar 6 21:50 logs/ -rwxrwxrwx 1 nobody users 33 Mar 2 17:13 machine-id* -rwxrwxrwx 1 nobody users 144 Mar 2 17:13 settings.json* drwxrwxrwx 2 nobody users 0 Mar 6 21:50 stats/ Und hier nochmal der Ordner direkt über ssh abgerufen: root@backup test1 # ls -hla drwxrwxr-x 7 root root 4.0K Mar 6 00:46 . drwxrwxrwx 17 root root 4.0K Mar 6 21:50 .. drwx------ 3 nobody netdev 4.0K Mar 5 22:42 bin drwxrwxr-x 3 root root 4.0K Mar 2 17:13 cache -rw------- 1 root root 4.3K Mar 6 00:46 duplicacy.json drwx------ 3 nobody netdev 4.0K Mar 2 17:39 filters -rw------- 1 nobody netdev 171 Mar 2 17:15 keyring -rw------- 1 nobody netdev 1.0K Mar 2 17:43 licenses.json drwxrwxr-x 3 root root 4.0K Mar 6 00:40 logs -rw-rw-r-- 1 nobody netdev 33 Mar 2 17:13 machine-id -rw-rw-r-- 1 nobody netdev 144 Mar 2 17:13 settings.json drwx------ 4 nobody netdev 4.0K Mar 2 17:13 stats Direkt auf dem NAS sehen die Rechte wie im Original aus, über den SMB Share zugegriffen gibt es aber Probleme, obwohl hier die Rechte für alle auf rwx stehen. Jetzt habe ich das ganze mal nicht über ssh sondern direkt mit rsync auf den smb share geschoben: rsync -azvh /mnt/cache/appdata/duplicacy/.zfs/snapshot/autosnap_2025-03-06_11\:08\:37_daily/ /mnt/remotes/172.30.2.21_duplicacy/test Ergebnis: root@Unraid:/mnt/remotes/172.30.2.21_duplicacy/test# ls -hl total 24K drwxrwxrwx 2 nobody users 0 Mar 5 22:42 bin/ drwxrwxrwx 2 nobody users 0 Mar 2 17:13 cache/ -rwxrwxrwx 1 nobody users 4.3K Mar 6 00:46 duplicacy.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:39 filters/ -rwxrwxrwx 1 nobody users 171 Mar 2 17:15 keyring* -rwxrwxrwx 1 nobody users 1.1K Mar 2 17:43 licenses.json* drwxrwxrwx 2 nobody users 0 Mar 6 00:40 logs/ -rwxrwxrwx 1 nobody users 33 Mar 2 17:13 machine-id* -rwxrwxrwx 1 nobody users 144 Mar 2 17:13 settings.json* drwxrwxrwx 2 nobody users 0 Mar 2 17:13 stats/ und hier nochmal über ssh abgerufen: root@backup test # ls -hla drwxrwxrwx 7 unraid share 4.0K Mar 6 00:46 . drwxrwxrwx 17 root root 4.0K Mar 6 21:50 .. drwxrwxrwx 3 unraid share 4.0K Mar 5 22:42 bin drwxrwxrwx 3 unraid share 4.0K Mar 2 17:13 cache -rwxrwxrwx 1 unraid share 4.3K Mar 6 00:46 duplicacy.json drwxrwxrwx 3 unraid share 4.0K Mar 2 17:39 filters -rwxrwxrwx 1 unraid share 171 Mar 2 17:15 keyring -rwxrwxrwx 1 unraid share 1.0K Mar 2 17:43 licenses.json drwxrwxrwx 3 unraid share 4.0K Mar 6 00:40 logs -rwxrwxrwx 1 unraid share 33 Mar 2 17:13 machine-id -rwxrwxrwx 1 unraid share 144 Mar 2 17:13 settings.json drwxrwxrwx 4 unraid share 4.0K Mar 2 17:13 stats Erstmal keine Permission denied Meldung, die Rechte sind gleich geblieben aber der Owner wurde geändert. "unraid" ist der user auf dem NAS der Schreibrechte auf dem Share hat. Eigentlich ist das was über ssh geschoben wird das Richtige, nur das unraid über den Share nicht richtig drauf zugreifen kann. Ich denke mal es liegt an irgendwelchen User Rechten auf dem NAS selber. Mir würden jetzt spontan folgende Sachen einfallen: 1. Das Skript so bearbeiten das es statt über ssh direkt über den SMB Share auf das NAS kopiert 2. Oder das Skript gleich so umschreiben das der Rsync erstmal auf einen anderen Pool geschrieben wird, dann mit Duplicacy hochgeladen wird und erst danach auf den NAS. Das würde wahrscheinlich auch die Backupzeit reduzieren, weil nicht erst auf das NAS geschrieben wird und dann wieder davon die Daten für Duplicacy geholt werden müssen. 3. Oder eine weitere Platte einbauen auf zfs und direkt darauf sichern und dann weiter mit Duplicacy 4. In dem Skript werden für Rsync temporäre Snapshots angelegt, man könnte das Skript so umbauen, das Duplicacy die gleich mit verwenden kann. Edited March 7, 20251 yr by Michael Lanzl
March 7, 20251 yr Quote Borgbackup sieht auch interessant aus, spielt aber soviel ich auf die Schnelle gesehen habe nicht mit meinem Cloudspeicher. Wie ich gesehen habe schiebst du jetzt auch alles per rsync und SSH in deine Cloud oder liege ich da falsch. Weil das kann Borgbackup direkt ohne rsync.
March 8, 20251 yr On 3/6/2025 at 4:41 PM, mikiunraid said: Was für ein Chaos. Nichts ging mehr. duplicati wollte die Datenbank neu aufbauen und nach 12 Stunden habe ich es dann abgebrochen. Ein Backup welches von Dateien wie z.B. einer Datenbank abhängig ist das ist kein Backup Na sag das mal nicht Veeam oder anderen Backup Programmen auf Enterprise Basis. Klar, es gibt auch Programme, wie Borg Backup, welche keine Datenbank benötigen. Diese brauchen dafür um einiges länger beim gezielten Wiederherstellen von einzelnen Daten, da diese meist das ganze Backup nach diesen Daten dursuchen müssen. Der Vorteil einer Datenbank bei Backupprogrammen sind solche Dinge wie Metadatenverwaltung, Deduplizierung & Komprimierung, inkrementelle und differenzielle Backups, Konsistenzprüfung & Integrität als auch die bereits erwähnte schnelle Wiederherstellung. Aber auch Borgbackup ist von anderen Daten abhängig, in dem Fall seinen Repositorys. Und wenn diese versehentlich (oder absichtlich zum testen) gelöscht werden, sind die Backups unbrauchbar. Da freut man sich dann doch über Tools wie Veeam oder Duplicacy, welche die Datenbank anhand der Backupdaten einfach wieder aufbauen. Edited March 8, 20251 yr by Gorosch
March 9, 20251 yr Ich kann Borg Repositorys einfach einhängen und Daten einfach zurück kopieren. Dazu kommt das ich das Repositorys im ganzen wegsichere. Bei den anderen Programmen muss ich die Datenbanken immer noch extra irgendwo irgendwie sichern. Ich komme mit Borg super zurecht. Ich schaue mir Duplicacy mal an. Duplicati geht aber mal gar nicht.
March 9, 20251 yr Das sollte hier kein "das eine ist besser als das andere" werden. Denn das ist es nicht. Sowohl Borg als auch Duplicacy sind beides gute Tools, um verlässlich Backups zu fahren. Wenn du mit Borg zufrieden bist, gibt es keinen Grund außer der eigenen Neugier, sich Duplicacy anzuschauen. Ich wollte dir nur aufzeigen, dass es völlig normal ist, dass gute Backupprogramme generell immer mit Metadaten arbeiten, welche auch irgendwo abgelegt sind und diese ebenfalls in ein Backup einfließen sollten. Im Falle von Borg am besten nicht im gleichen Backup. Edited March 9, 20251 yr by Gorosch
March 9, 20251 yr Author On 3/7/2025 at 8:27 PM, mikiunraid said: Wie ich gesehen habe schiebst du jetzt auch alles per rsync und SSH in deine Cloud oder liege ich da falsch. Weil das kann Borgbackup direkt ohne rsync. Nicht ganz. Das Skript von SpaceinvaderOne das ich verwende erstellt erstmal ZFS Snapshots und schiebt dann die Daten aus den Snapshots mit rsync auf mein NAS. Duplicacy soll das dann um den offsite Part erweitern und die Daten vom NAS in die Cloud schieben. Aber egal welches Tool ich am Ende dafür verwende, des Problem ist aktuell wohl das NAS und die Rechte. Aktuell fällt mir auch nur ein, die Rechte nach dem sichern auf dem NAS einmal zu überschreiben, oder das Skript die Daten nicht über SSH sondern direkt auf den SMB Share schreiben. Dann spare ich mir das nachträgliche anpassen. Privilegierte Rechte hat übrigens auch nichts geändert. Ich habe auch statt SMB mal NFS getestet, ähnliches Problem.
March 9, 20251 yr Dein Dupli läuft mit Root rechten, was nur beim Sichern vom USB Stick notwendig ist. Normal sollte USR_ID=99 and GRP_ID=100 (nobody:users) für Dupli reichen. Mit WD NAS kenn ich mich leider nicht aus. Bei QNAP und Synology gibt es jedoch für NFS Freigaben den Punkt "Sqash". In deinem Fall teste Mal diese Option, sofern es das in dieser Art auch bei deiner WD NAS gibt: Dann sollte das erst Mal funktioneren und du weist, dass du ein Beretigungsproblem hast. Ob du das auf Dauer so lassen willst, musst du dann für dich selbst entscheiden. Im lokalen Netz spricht da eigentlich nicht viel dagegen.
March 10, 20251 yr Author Leider sind die NFS Einstellungen in meinem alten WD My Cloud NAS sehr rudimentär. Aber Squash war das richtige Stichwort. folgende Zeile habe ich in der /etc/exports auf dem NAS angepasst. "/nfs/duplicacy" 172.30.2.1(rw,no_root_squash,sync,no_wdelay,insecure,no_subtree_check,anonuid=99,anongid=100) geändert hatte ich von "all_squash" auf "no_root_squash" und die ID`s auf nobody angepasst. jetzt kann Duplicacy sowohl auf die über ssh übertragenen Daten als auch auf die die über NFS geschoben wurden zugreifen. Danke für den Tipp! Edited March 10, 20251 yr by Michael Lanzl
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.