mgutt Posted March 18, 2023 Author Share Posted March 18, 2023 8 hours ago, bastl said: Ist das normal bei Hardlinks? Nein. Es könnte vielleicht sein, dass das "du" Kommando auf der Syno die Hardlinks nicht abzieht. Aber dagegen spricht eigentlich die lange Laufzeit des Backups. Du kannst es aber auch anders herausfinden. Such dir eine Datei raus, die in jedem Fall nicht verändert wurde, zwischen den Backups und dann führe das "stat" Kommando aus und schau bei "Links" nach der Zahl. Zum Beispiel hier die Datei hat 23 Hardlinks: # stat /mnt/disk7/Backups/Shares/Music/20230318_050036/Allgemein/Eminem/The\ Eminem\ Show\ \[Explicit\]/Folder.jpg File: /mnt/disk7/Backups/Shares/Music/20230318_050036/Allgemein/Eminem/The Eminem Show [Explicit]/Folder.jpg Size: 33686 Blocks: 72 IO Block: 4096 regular file Device: 907h/2311d Inode: 23684871800 Links: 23 Access: (0666/-rw-rw-rw-) Uid: ( 99/ nobody) Gid: ( 100/ users) Access: 2021-12-22 10:31:55.718268343 +0100 Modify: 2017-11-11 10:50:48.000000000 +0100 Change: 2023-03-18 05:06:43.995974531 +0100 Birth: 2021-12-22 10:31:55.718268343 +0100 Quote Link to comment
Revan335 Posted March 19, 2023 Share Posted March 19, 2023 (edited) Habe das Skript jetzt mal zum Backup des Cache genutzt. Allerdings mag es noch nicht richtig laufen, es schreibt die Backup NVMe voll obwohl die Quelle nur 70% belegt ist. Cache xfs und Cache Backup btrfs. (Wegen deduplication) Hier die Änderungen am Script: # backup source to destination backup_jobs=( # source # destination "/mnt/cache" "/mnt/cachebtrfs/Cache_Backup" ) Edited March 19, 2023 by Revan335 Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 Gibt es irgendeinen Grund, dass du das komplette Skript hier einfügst? Mach das mal bitte wieder weg und dann zeig nur das was du angepasst hast. Ansonsten könnte ich mir vorstellen, dass ein inkrementelles Skript wenig geeignet ist für dieses Vorhaben. Schließlich bleiben Unterschiede erhalten. Also jedesmal wenn du eine VM startest: Volles Backup der IMG Datei. Oder wenn Docker laufen: Alle geänderten Dateien werden addiert. Oder wenn du Dateien auf den Server hochlädst, die noch nicht auf das Array verschoben wurden: Landen ebenfalls auf der Backup NVMe. Hier mal ein Beispiel von meiner Sicherung: du -hs /mnt/cache/appdata 637G /mnt/cache/appdata du -hs /mnt/disk7/Backups/Shares/appdata 1.9T /mnt/cache/appdata Also wenn kannst du vielleicht zwei inkrementelle Backups auf die Art erhalten. Aber selbst dann könnte es voll laufen. Je nachdem wie viel sich geändert hat. Also entweder holst du eine größere Backup NVMe, damit in jedem Fall zwei Backups drauf passen, oder du machst nur einen simplen rsync: rsync --archive /mnt/cache/ /mnt/cachebtrfs/backup Vorzugsweise so, dass du vorher noch Docker und VMs stoppst, damit ein sauberes Backup erstellt wird. 1 Quote Link to comment
Revan335 Posted March 19, 2023 Share Posted March 19, 2023 26 minutes ago, mgutt said: Gibt es irgendeinen Grund, dass du das komplette Skript hier einfügst? Dachte das ganze Skript wird benötigt. Hab es korrigiert. Sorry. 43 minutes ago, mgutt said: Vorzugsweise so, dass du vorher noch Docker und VMs stoppst, damit ein sauberes Backup erstellt wird. Ist das bei deinem Skript nicht so, dass dies durch den Snapshot realisiert wird, der dort gemacht wird? Dann muss ich ggf. mit exclude für bspw. system/docker noch arbeiten um unnötigeres auszuschließen. Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 23 minutes ago, Revan335 said: Ist das bei deinem Skript nicht so, dass dies durch den Snapshot realisiert wird, der dort gemacht wird? Ja, diese Funktion ist drin, aber wie gesagt kannst du mit einem inkrementellen Backup nichts anfangen. Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 16 hours ago, mgutt said: Du kannst es aber auch anders herausfinden. Such dir eine Datei raus, die in jedem Fall nicht verändert wurde, zwischen den Backups und dann führe das "stat" Kommando aus und schau bei "Links" nach der Zahl. Zum Beispiel hier die Datei hat 23 Hardlinks: Hab nun 4 Sicherungen auf dem NAS. Ich habe jetzt mal anhand der "Nextcloud_Manual.pdf", die sich nicht geändert haben sollte, in einem User Daten Ordner liegend, wie gewünscht geprüft. Unabhängig welches Sicherungsverzeichnis ich wähle, unter Links steht immer eine 1. Wenn es ein Hardlink sein sollte, wenn ich das richtig verstehe, sollte da eigentlich eine 4 stehen, oder? Ich hab es auch noch mit der Datei "make_bootable.bat" vom gesicherten USB Stick getestet. Gleiches Ergebnis. stat "/volume1/UNRAID/BACKUPS_MINI/nextcloud/20230319_140249/data/Bastl/files/Nextcloud Manual.pdf" File: ‘/volume1/UNRAID/BACKUPS_MINI/nextcloud/20230319_140249/data/Bastl/files/Nextcloud Manual.pdf’ Size: 12765379 Blocks: 24936 IO Block: 4096 regular file Device: 2ch/44d Inode: 1020153 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 33/ UNKNOWN) Gid: ( 33/ UNKNOWN) Access: 2023-03-19 14:02:53.095240488 +0100 Modify: 2022-06-24 20:22:53.785054785 +0200 Change: 2023-03-19 14:02:53.459239951 +0100 Birth: - du -d1 -h /volume1/UNRAID/BACKUPS_MINI/nextcloud/ | sort -k2 393G /volume1/UNRAID/BACKUPS_MINI/nextcloud/ 99G /volume1/UNRAID/BACKUPS_MINI/nextcloud/20230317_191825 99G /volume1/UNRAID/BACKUPS_MINI/nextcloud/20230318_121818 99G /volume1/UNRAID/BACKUPS_MINI/nextcloud/20230319_011145 99G /volume1/UNRAID/BACKUPS_MINI/nextcloud/20230319_140249 Bei einem dry-run läuft übrigens die Sicherung mit allen 3 zu sichernden Ordnern in knapp 3min durch. Start 15:25 Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 9 minutes ago, bastl said: unter Links steht immer eine 1. Wenn es ein Hardlink sein sollte, wenn ich das richtig verstehe, sollte da eigentlich eine 4 stehen, oder? Jo. Dann gehen die Hardlinks nicht. Das ist komisch, weil über NFS Hardlinks eigentlich gehen sollten. Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 @mgutt Aktuell sehen die Einträge für die Pfade wie folgt aus im Script: backup_jobs=( # source # destination "/mnt/data/appdata" "/mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/appdata" "/mnt/data/nextcloud" "/mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/nextcloud" "/boot" "/mnt/remotes/DISKSTATION_UNRAID/BACKUPS_MINI/flash" ) Kann ich den Zielpfad auch wie folgt irgendwie erstellen, direkt über ssh gehen und wie geb ich dann die Zugangsdaten und den non-default Port mit? # source # destination "/boot" "ssh backup@nas:/volume1/UNRAID/BACKUPS_MINI/flash" Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 Jo, SSH geht auch. Dann solltest du aber die Schlüssel austauschen, damit keine Passwortabfrage kommt. Also auf dem Terminal musst du in der Lage sein "ssh user@server" ohne Passwort auszuführen. Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 31 minutes ago, mgutt said: Jo, SSH geht auch. Dann solltest du aber die Schlüssel austauschen, damit keine Passwortabfrage kommt. Also auf dem Terminal musst du in der Lage sein "ssh user@server" ohne Passwort auszuführen. Vom Terminal aus mit custom Port klappt die passwortlose Anmeldung. Wie geb ich denn den Port in dem Script mit? folgendes funktioniert leider nicht "/boot" "ssh -p 5022 backup@NAS:/volume1/UNRAID/BACKUPS_MINI/flash" Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 Bei den Einstellungen ist ein Beispiel. # user-defined ssh command #alias ssh='sshpass -p "<password>" ssh -o "StrictHostKeyChecking no"' Du machst nur eben alias ssh='ssh -p 5022' Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 13 minutes ago, mgutt said: Du machst nur eben alias ssh='ssh -p 5022' Pfadziel: "ssh backup@NAS:/volume1/UNRAID/BACKUPS_MINI/flash" mit folgendem custom ssh Befehl: alias ssh='ssh -p 5022' schmeißt er folgenden Fehler: Auszug aus log.txt Error: ()! Script Finished Mar 19, 2023 17:07.10 Full logs for this script are available at /tmp/user.scripts/tmpScripts/rsyncIncrementalBackup/log.txt Danke schonmal für die Hilfe Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 @mgutt Gerade noch mal Schreibrechte kontrolliert. Über nen Unraid Terminal komme ich wie folgt passwortlos auf den Server. IP im Script hinterlegt war nicht die Lösung ssh -p 5022 [email protected] Dateien im Zielverzeichnis kann ich problemlos erstellen und löschen. Auch nochmal geprüft, Pfad passt. /volume1/UNRAID/BACKUPS_MINI/flash/ 4 Dateien extra erstellt unter "/boot" was gesichert werden soll. Half leider auch nicht. Ich verzweifel so langsam. Is bestimmt wieder nur irgend ne Kleinigkeit. Ist der Syntax im Zielpfad wie im Post davor zu sehen evtl. falsch? Normal die Pfadangabe hinter "user@server:/Pfad" bringt auch nen Fehler vom Terminal aus. Muß man da nicht extra nen "cd /Pfad" anhängen um im richtigen Ordner zu landen? Wird das von dem Script automatisch erledigt? Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 @mgutt Hab jetzt zum Test folgendes als Zielpfade hinterlegt: "/boot" "ssh [email protected] 'cd /volume1/UNRAID/BACKUPS_MINI/flash'" und bekomme beim ausführen des Scripts folgende Meldung: rsync: [Receiver] mkdir "/usr/local/emhttp/ssh [email protected] 'cd /volume1/UNRAID/BACKUPS_MINI/flash'/link_dest" failed: No such file or directory (2) rsync error: error in file IO (code 11) at main.c(789) [Receiver=3.2.7] --link-dest arg does not exist: /usr/local/emhttp/ssh [email protected] 'cd /volume1/UNRAID/BACKUPS_MINI/flash'/hard_link/ssh [email protected] 'cd /volume1/UNRAID/BACKUPS_MINI/flash'/link_dest removed '/tmp/_tmp_user.scripts_tmpScripts_rsyncIncrementalBackup_script/empty.file' rsync: [Receiver] change_dir#3 "/usr/local/emhttp/ssh [email protected] 'cd /volume1/UNRAID/BACKUPS_MINI" failed: No such file or directory (2) rsync error: errors selecting input/output files, dirs (code 3) at main.c(827) [Receiver=3.2.7] Error: Your destination ssh [email protected] 'cd /volume1/UNRAID/BACKUPS_MINI/flash' does not support hardlinks! Script Finished Mar 19, 2023 18:04.54 Full logs for this script are available at /tmp/user.scripts/tmpScripts/rsyncIncrementalBackup/log.txt "does not support hardlinks!" wundert mich ein wenig. Das NAS ist mit BTRFS formatiert. Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 Der Zielpfad ist "user@server:/pfad". Wie im Beispiel zu sehen. Nix "ssh " und nix "cd". Quote Link to comment
bastl Posted March 19, 2023 Share Posted March 19, 2023 2 hours ago, mgutt said: Der Zielpfad ist "user@server:/pfad". Wie im Beispiel zu sehen. Nix "ssh " und nix "cd". Hab ich getestet, leider ohne Erfolg. Ich erhalte jedesmal den Fehler Ich hab nun so einiges durchprobiert. Share auf dem NAS neu erstellt, Zeit-Synchronisation passt, neuer Benutzer, diverse Berechtigungen geprüft, selbst mit maximalen Rechten war nix zu machen. Hab nun die ssh Verbindung erstmal verworfen und nochma den Share als NFS Mount in Unraid als Ziel eingebunden und beim Testen ist mir etwas aufgefallen. Wenn ich den Unraid Share "/mnt/data/test" mit der Datei "libvirt.iso" auf das NFS mount sichere scheint es nun zu funktionieren. Bei 3 Sicherungen gibt mir stats "Links: 3" aus. Mache ich das gleiche mit "/boot" als Source um den USB Stick zu sichern, bin ich wieder bei meinem ursprünglichem Problem, dass jede Sicherung scheinbar vollständig Platz belegt und "Links: 1" angezeigt wird. Gleiches habe ich noch mit einem weiteren Unraid Share getestet, der von dem Docker TDARR benutzt wird, da funktioniert es wieder nicht. Die ersten 3 Sicherungen sind der "test" ordner, die letzten Beiden "/boot" $ du -d1 -h /volume1/UNRAID/test/ 508M /volume1/UNRAID/test/20230319_230436 4.0K /volume1/UNRAID/test/20230319_230453 4.0K /volume1/UNRAID/test/20230319_230550 674M /volume1/UNRAID/test/20230319_231939 674M /volume1/UNRAID/test/20230319_232048 1.9G /volume1/UNRAID/test/ virtio.iso $ stat /volume1/UNRAID/test/20230319_230550/virtio.iso File: ‘/volume1/UNRAID/test/20230319_230550/virtio.iso’ Size: 531632128 Blocks: 1038344 IO Block: 4096 regular file Device: 2ch/44d Inode: 1060159 Links: 3 Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-03-19 23:04:36.775398397 +0100 Modify: 2023-03-17 15:48:38.615599360 +0100 Change: 2023-03-19 23:05:50.403330135 +0100 Birth: - make_bootable.bat $ stat /volume1/UNRAID/test/20230319_232048/make_bootable.bat File: ‘/volume1/UNRAID/test/20230319_232048/make_bootable.bat’ Size: 1760 Blocks: 8 IO Block: 4096 regular file Device: 2ch/44d Inode: 1060690 Links: 1 Access: (0777/-rwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2023-03-19 23:20:55.507531684 +0100 Modify: 2022-11-20 22:27:34.000000000 +0100 Change: 2023-03-19 23:20:55.546531654 +0100 Birth: - Ich bin so langsam fertig mit mein Nerven. Halben Sonntag verdöddelt mit dem Kram. Irgendwie blick ich nicht dahinter woran es liegt. 😒 Quote Link to comment
mgutt Posted March 19, 2023 Author Share Posted March 19, 2023 5 minutes ago, bastl said: Die ersten 3 Sicherungen sind der "test" ordner, die letzten Beiden "/boot" Wenn du alle in den selben Ordner sicherst, kann das auch nicht funktionieren. Das Skript sucht ja in dem Ordner nach dem letzten Backup. Das letzte Backup ist dann zB zufällig das vom /boot Verzeichnis. Du sicherst aber gerade irgendeinen anderen Share. Er findet nichts in dem letzten Backup was dazu passt und erstellt es komplett neu. Fazit: Die Zielverzeichnisse müssen pro Quellverzeichnis unterschiedlich sein. Quote Link to comment
bastl Posted March 20, 2023 Share Posted March 20, 2023 1 hour ago, mgutt said: Die Zielverzeichnisse müssen pro Quellverzeichnis unterschiedlich sein. Das war doch schon der Fall, ganz zu Beginn. Alles in einen Ordner zu sichern hatte ich nur bei den letzten Tests getan, sry my bad falls das vielleicht verwirrend war, ändert aber nichts an der Sachlage. Gleiches Bild zeigt sich wie folgt: Hier jetzt nochmal verdeutlicht, was ich gerade teste. Folgende 4 Ordner sollen gesichert werden. Eindeutig 4 verschiedene Ziele. "/boot" "/mnt/remotes/DISKSTATION_UNRAID/test/1" "/mnt/data/test" "/mnt/remotes/DISKSTATION_UNRAID/test/2/" "/mnt/data/backup/ca_backup/flash" "/mnt/remotes/DISKSTATION_UNRAID/test/3/" "/mnt/data/appdata" "/mnt/remotes/DISKSTATION_UNRAID/test/4" Es existieren nun von jedem Ordner 3 Sicherungen. Es wurden keinerlei Änderungen am Script, Berechtigungen oder Pfaden vorgenommen In den ordnern 2 und 3 scheint es Hardlinks zu geben, bei 1 und 4 scheinbar nicht. Ich hab nun testweise von Hand den "/mnt/data/appdata" Ordner in den zu sichernden Ordner "/mnt/data/test" kopiert und dann 2 weitere Sicherungen von nur diesem Ordner erstellt (die anderen 3 Pfade auskommentiert im Script). Die Datei ".../2/.../virtio.iso" zählt jeweils 1 pro Sicherung hoch bei Links, die Dateien in ".../2/.../appdata/ordner/datei" eben nicht. Beide Inhalte sind zwischen den beiden Sicherungen unverändert. Sollte nicht spätestens bei der 2ten zusätzlichen Sicherung von "/mnt/data/test" wo nun zusätzlich "appdata" hineinkopiert wurde, bei erfolgreich erstellten Hardlinks der Counter hochzählen bei Dateien innerhalb des appdata Ordners? Woran kann es liegen, dass von der einen Datei ein Hardlink erstellt wird und ein paar Ebenen tiefer in der gleichen Ordnerstruktur auf einmal nicht mehr? Ich versteh die Welt nicht mehr 😑 Quote Link to comment
mgutt Posted March 20, 2023 Author Share Posted March 20, 2023 Steht in den Logs von dem Skript evtl etwas von Fehlern? Ich kann mir das nur mit irgendwelchen Berechtigungsfehlern erklären. Gehört die perms.txt auf der Quelle auch dem User root? Quote Link to comment
bastl Posted March 21, 2023 Share Posted March 21, 2023 21 hours ago, mgutt said: Steht in den Logs von dem Skript evtl etwas von Fehlern? Ich habe das log File "/tmp/user.scripts/tmpScripts/rsyncIncrementalBackup/log.txt" mal grob nach "error", "auth", "authentication", "privilege" durchsucht. Hatte die Datei schonmal gelöscht, aktuell 72MB und fast 900k Zeilen, da wird es schwer den Überblick zu behalten. Treffer sind dann aber nur bei Dateien oder Ordner die so benannt sind. In den Zusammenfassungen nach jedem Pfad beinhalten auch keine Fehlermeldungen. 21 hours ago, mgutt said: Gehört die perms.txt auf der Quelle auch dem User root? Ja. Und hier nochmal zum Vergleich die Berechtigungen im eigentlichen appdata Verzeichnis, was ich als root nach "test" kopiert hatte. Quote Link to comment
mgutt Posted March 21, 2023 Author Share Posted March 21, 2023 ja dann keine Ahnung 🤷😅 Quote Link to comment
bastl Posted March 21, 2023 Share Posted March 21, 2023 22 hours ago, mgutt said: Ich kann mir das nur mit irgendwelchen Berechtigungsfehlern erklären. Hab jetzt mal folgendes getestet. Aus dem zu sichernden Nextcloud Ordner hab ich ne Video Datei in den test Ordner kopiert. Desweiteren werden nur ein paar Docker Config Ordner gesichert um die tests zu beschleunigen. Hab dann einige Backups nacheinander erstellt ohne was zu ändern. Wie gehabt, bis auf die Datei "virtio.iso" werden scheinbar alle Dateien erneut übertragen. Dauert auch jedesmal identisch lang. Hab nun die Berechtigungen der Videodatei auf 777 gesetzt und siehe da, Backup is ruckzuck durch und die Datei zählt bei Links hoch. Und siehe da, "du" gibt diesmal auch Werte aus, die Sinn machen. Die 1,8MB sind sicherlich die paar Appdata Files, die erneut gesichert werden. So und nune? 😂 Quote Link to comment
Rockikone Posted March 26, 2023 Share Posted March 26, 2023 @mgutt Evtl kann ich dir eine notwendige Anpassung deines Scripts für das kommende Unraid 6.12 melden. Ich setze dein Script nun seit geraumer Zeit ein, ohne Probleme. Inzwischen läuft bei mir auf dem Server 6.12 RC2 sehr stabil. Jedoch habe ich nun folgendes Problem hinsichtlich der Sicherung appdata. Die Docker Container werden per Script gestoppt und das BackUP gemacht, jedoch im Anschluss nicht mehr gestartet. Dieses Verhalten habe ich erst seit 6.12. Evtl musst du hier nachbessern. Danke und Gruß Quote Link to comment
mgutt Posted March 26, 2023 Author Share Posted March 26, 2023 12 hours ago, Rockikone said: Die Docker Container werden per Script gestoppt und das BackUP gemacht, jedoch im Anschluss nicht mehr gestartet. Dieses Verhalten habe ich erst seit 6.12. Evtl musst du hier nachbessern. Ich habe es gerade auf meinem Testserver probiert und kann das nicht nachvollziehen: Hast du mal Logs parat bzw steht was wegen einem Fehler in den Logs?! Quote Link to comment
Rockikone Posted March 27, 2023 Share Posted March 27, 2023 @mgutt Ich habe inzwischen einen Fehler bei mir entdeckt. Den Cache habe ich auf einen ZFS Pool umgezogen. Pool heißt zfs-cache. Dieses hatte ich unter Einstellungen nicht bei Docker abgeändert. Jetzt kommt aber der nächste Fehler. Unraid meckert, dass der zfs-pool keine Hardlinks unterstützt. Quote Link to comment
Recommended Posts
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.