rsync Skript für inkrementelle Backups


mgutt

Recommended Posts

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

 

Link to comment

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 by Revan335
Link to comment

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.

  • Like 1
Link to comment
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.

Link to comment
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

 

grafik.png.1247dae66c44d6ecb5669c05d53068fd.png

 

Link to comment
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.

Link to comment

@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"

 

Link to comment
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"

 

Link to comment
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:

grafik.png.ce920eda3d83e2dc10cc4014e5ae19ec.png

 

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

Link to comment

@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?

 

Link to comment

@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:

grafik.png.561d19ef68f41deb61708bc153c8d7c6.png

 

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.

 

Link to comment
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

grafik.png.411bb982220d8b7ef6664bbbc8a92fef.png

 

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. 😒

Link to comment
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.

Link to comment
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

grafik.png.091dadf9cbeca9f31df850026b226cbc.png

 

grafik.png.b7403f98f6aa5bd69f49dc7094f0fb15.png

 

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.

 

grafik.png.c8289e85a5594feb08b16a551502138a.png

 

grafik.png.93067c572d669c292863ed22d5276d7f.png

 

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 😑

 

Link to comment
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.

grafik.png.f5c4ba429b16fc7cc92add0c1ae3c394.png

 

Und hier nochmal zum Vergleich die Berechtigungen im eigentlichen appdata Verzeichnis, was ich als root nach "test" kopiert hatte.

grafik.png.328a3735fd5a2c52c75c814f030ae248.png

 

Link to comment
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.

grafik.png.497cadad4b58f76532aebd73ac85c489.png

grafik.png.a5dbba07cc723d0ea1207aa947ff6c72.png

 

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.

grafik.png.2e149e40a4b485059a9aad27b814734f.png

 

So und nune?

 

😂

Link to comment

@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ß

 

 

Link to comment
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:

 

image.thumb.png.a94c26112b21c3c44a322d075d7aa157.png

 

Hast du mal Logs parat bzw steht was wegen einem Fehler in den Logs?!

 

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.