rsync Skript für inkrementelle Backups


mgutt

Recommended Posts

10 hours ago, UnraidGHD said:

Hardlinks in Unraid sind aktiviert in Global Share Settings

Häh? Das bezieht sich auf SMB Shares von unRAID. Also wenn die das Ziel sind. Auf SMB sollte man sowieso niemals sichern. Dadurch gehen diverse Dateirechte verloren.

 

10 hours ago, UnraidGHD said:

LuckBackup allerdings beschwert sich nicht und nutzt ja auch rsync.

Den Check habe ich selbst entwickelt.

 

Ergänze bitte vor dieser Zeile:

transfer_count=$(rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link" | wc -l)

 

Das:

rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link_test"

 

Und dann brauche ich die Logs von dem Skript.

Link to comment
9 hours ago, mgutt said:

Häh? Das bezieht sich auf SMB Shares von unRAID. Also wenn die das Ziel sind. Auf SMB sollte man sowieso niemals sichern. Dadurch gehen diverse Dateirechte verloren.

 

Den Check habe ich selbst entwickelt.

 

Ergänze bitte vor dieser Zeile:

transfer_count=$(rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link" | wc -l)

 

Das:

rsync --dry-run --itemize-changes --recursive --link-dest="$link_dest_path/link_dest" "$empty_dir/" "$dst_path/hard_link_test"

 

Und dann brauche ich die Logs von dem Skript.

Hm das Problem mit Samba verstehe ich, dann eher NFS oder ist SSH besser?

 

ok, hier als Versuch auch einen Share im selben UnraidServer zu sichern

 

 

 

Script Starting Sep 23, 2023 18:35.26

Full logs for this script are available at /tmp/user.scripts/tmpScripts/0000000001/log.txt

# #####################################
created directory /mnt/user/Archiv/link_dest
>f+++++++++ empty.file
--link-dest arg does not exist: /mnt/user/Archiv/link_dest
created directory /mnt/user/Archiv/hard_link_test
cd+++++++++ ./
>f+++++++++ empty.file
--link-dest arg does not exist: /mnt/user/Archiv/link_dest
removed '/tmp/_tmp_user.scripts_tmpScripts_0000000001_script/empty.file'
Error: Your destination /mnt/user/Archiv does not support hardlinks!
Script Finished Sep 23, 2023 18:35.29

Full logs for this script are available at /tmp/user.scripts/tmpScripts/0000000001/log.txt

Edited by UnraidGHD
Link to comment
1 hour ago, UnraidGHD said:

created directory /mnt/user/Archiv/link_dest

...

--link-dest arg does not exist: /mnt/user/Archiv/link_dest

Verstehe ich nicht. Der hat den Pfad doch kurz vorher erstellt 🤔 Sicher, dass der Pfad "Archiv" heißt und nicht "archiv"? Mal mit folgendem Kommando prüfen bitte:

 

ls /mnt/user

 

Bitte teste auch mal stattdessen einen Diskpfad. /mnt/user ist ja Unraid's virtueller Pfad auf alle möglichen Ziele. Nimm mal /mnt/disk1/Archiv oder welche Disk auch immer das Ziel sein soll.

 

1 hour ago, UnraidGHD said:

Hm das Problem mit Samba verstehe ich, dann eher NFS oder ist SSH besser?

Ich bin von keiner Variante ein Freund, wenn man "appdata" sichert, da dort häufig Dateien drin sind, die "root" gehören und wenn man solche Dateien 1:1 sichern will, muss man auch root auf dem Ziel sein. Und das wäre ist riskant, weil ein Angreifer, der das eine Passwort knackt, gleich auch den Backupserver platt machen kann.

 

Ich mache das komplexer, aber dafür deutlich sicherer. Ich habe einen rsync Container installiert, der rein lesend auf meine Daten zugreifen kann. Mein Backupserver verbindet sich mit diesem Container als root und kann daher die Dateien 1:1 ziehen, aber es kann niemals passieren, dass beide Server kompromittiert werden, da der Backupserver nur lesen kann und der Heimserver gar keinen Login vom Backupserver kennt. Auch kann der Backupserver die meiste Zeit aus sein, da er weiß wann das Backup fertig ist.

 

Ich sichere übrigens appdata lokal vom Cache auf das Array, damit das Skript die Container sauber stoppt. Dh mein Backupserver holt nicht appdata direkt ab, sondern nur das Backup davon.

 

Natürlich muss man das nicht so machen wie ich und kann ansonsten auch auf beliebige Ziele sicheren, aber das würde ich wie gesagt nur für Shares empfehlen, wo Nutzerrechte keine Rolle spielen bzw leicht repariert werden können wie zb persönliche Shares, wo Dokumente und Medien drin liegen.

 

Und klar. SMB ist ein No Go wegen der Hardlinks. Irgendwie geht das wohl schon, aber das sollte man nur machen, wenn man es verifiziert hat.

 

 

Link to comment

Der Pfadname ist korrekt. Die Änderung auf /mnt/disk1/Archiv bringt auch keinen Erfolg.

Wenn ich als Ziel einen nicht angelegten Pfad anlege, wird dieser erstellt, das klappt also auch.

Es bleibt bei "keine Hardlinks unterstützt", wohin auch immer ich das Backup haben will.

 

Wenn ich den Hardlink-Test im Script auskommentiere läuft ein Backup durch.

Aber der Zielordner ist leer.

 

 

Quote

Script location: /tmp/user.scripts/tmpScripts/0000000001/script
Note that closing this window will abort the execution of this script
cd+++++++++ mnt/cache_ssd/Peter/
# #####################################
Create full backup from /mnt/disk1/isos to /mnt/cache_ssd/Peter/20230923_222338
created directory /mnt/cache_ssd/Peter/.20230923_222338
cd+++++++++ ./
>f+++++++++ BigSur-install.img
>f+++++++++ EndeavourOS_Artemis_nova_22_9.iso
>f+++++++++ MX-23_ahs_x64.iso
>f+++++++++ debian-12.0.0-amd64-netinst.iso
>f+++++++++ lubuntu-22.04.3-desktop-amd64.iso
>f+++++++++ proxmox-ve_8.0-2.iso
>f+++++++++ rescatux-0.74.iso
>f+++++++++ ubuntu-22.04-live-server-amd64.iso

Number of files: 9 (reg: 8, dir: 1)
Number of created files: 9 (reg: 8, dir: 1)
Number of deleted files: 0
Number of regular files transferred: 8
Total file size: 13.39G bytes
Total transferred file size: 13.39G bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 418
Total bytes received: 103

sent 418 bytes received 103 bytes 1.04K bytes/sec
total size is 13.39G speedup is 25,707,089.57 (DRY RUN)
File count of rsync is 9
Make backup visible ...
... through local mv
# #####################################
Clean up outdated backups

 

 

 

Deinen Backupansatz finde ich toll, den Container werde ich mir mal ansehen, den habe ich schon gefunden, aber das Prinzip dahinter erst jetzt verstanden. Erst mal die Hardlinks.

 

Link to comment
34 minutes ago, UnraidGHD said:

--dry-run, genau das hatte ich und das verhindert auch den Erfolg beim Hardlinktest.

 

Oh, dann sollte ich an der Stelle das dry-run denke ich weg lassen. Der Test kann ja ruhig in beiden Fällen wirklich gemacht werden. Danke für den Hinweis.

 

35 minutes ago, UnraidGHD said:

Du sagtest, Dateirechte gehen beim Sichern auf Samba verloren. Das sollte ja bei NFS nicht der fall sein oder?

Laut meiner Recherche wird der Zugriff als Root-User automatisch in nobody geändert:

https://superuser.com/a/1226152/129262

 

Das ist halt das was ich meine. Wenn du auf ein externes System schreibst, kannst du niemals sicher sein, dass du auch da root bist, außer du nutzt wirklich den root-Login der Zielmaschine, was ich wieder als unsicher betrachten würde.

 

Nur damit du das auch mal selber prüfen kannst. So kannst du alle Dateien finden, die dem User root gehören, die im appdata Share liegen:

 

find /mnt/user/appdata -uid 0

 

Wenn du nun dieses Verzeichnis sicherst, kannst du das selbe Kommando auf der Zielmaschine selbst ausführen, um zu schauen, ob die Rechte noch passen.

 

Zählen könnte man dann zB so:

 

find /mnt/cache/appdata -uid 0 | wc -l
find /mnt/extern/server/backups/appdata -uid 0 | wc -l

 

Beide müssen logischerweise die exakte selbe Anzahl zurückgeben.

 

Noch eine Option wäre es die Backups von Cache auf Array zu machen und das Backup dann in ein tar zu packen, was du dann auf ein externes Ziel deiner Wahl kopierst. Dafür reicht dann "cp". Die Hardlinks gehen dann natürlich nicht. Aber wenn man den gesamten Backup-Ordner sichert, dann erkennt tar die Hardlinks und fügt die Datei auch nur jeweils 1x im Archiv hinzu. Vorteil in einem tar ist, dass die Dateirechte im Archiv selbst gesichert werden. Dadurch kann man ein tar auch zB auf eine Windows-Maschine sichern und verliert nichts.

Link to comment

Ich habe den Samba/NFS-Weg auf deinen Rat hin verlassen und den rsync Docker installiert.

Auf Raspberry als root angemeldet aus den SSH Schlüssel erzeugt und im Container eingegeben.

Danach kann mich mich mit

ssh -p 5533 root@tower

beim erstan mal nach der Abfrage "Are you sure you want to continue connecting"

einloggen ohne Passwortabfrage.

Wenn ich

rsync --dry-run --itemize-changes --archive -e 'ssh -p 5533' root@tower:/mnt/user/system/ /tmp

starte, läuft es durch ohne Passwortabfrage

 

Wenn ich dann auf dem Raspy das Script starte werde ich wieder gefragt "Are you sure you want to continue connecting"

und dann wird nach dem Passwort gefragt.

Das heisst, ich lande nicht im Docker

obwohl ich

QuellPfad

"[email protected]:/mnt/user/Archiv"     

alias ssh='ssh p- 5533'

im Script habe

 

Ich denke, der Port 5533 wird nicht genutzt.

alias ssh funktioniert nicht?

 

Gruß Thomas

 

Link to comment

Wenn ich den Rsync Docker ins br0 Netzwerk nehme mit eigener IP, dann klappt das ganze sowohl mit Port 22

als auch mit aslias ssg und einem anderen Port. Mit preshared Ksy, d.h ich lande im Docker.

 

im bridge modus bekommen ich im Unraid log

 

Sep 25 15:44:15 UnraidGHD sshd[25478]: Connection from 192.168.1.94 port 55110 on 192.168.1.100 port 22 rdomain ""
Sep 25 15:44:15 UnraidGHD sshd[25478]: Failed publickey for root from 192.168.1.94 port 55110 ssh2: RSA Sxxxxxxxxxxxxxxxxxxxxxxxxxx

 

d.h. der Verbindungsversuch vom Raspberry geht auf Port 22 obwohl alias ssh auf einen anderen Port verweise.

Also legt Unraid im bridge Modus SSH immer auf Port 22 ???

Dann werde ich nach dem Passwort gefragt und es geht. Aber der Preshared key geht natürlich nicht, denn ich lande wohl nicht im Docker.

 

Link to comment
  • 1 month later...

Hallo,

 

ich möchte mit dem Script einen Raspi Sichern. Dazu habe ich folgendes eingetragen:

 

 

# backup source to destination
backup_jobs=(
  # source                          # destination
  "[email protected]:/home/pi/"    "/mnt/user/backup1/Raspis/Wohnzimmer/"
 )
.
.
.

# user-defined ssh command
alias ssh='ssh -i /root/.ssh/master'

 

Nun bekomme ich diesen Fehler:

 

Error: rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: unexplained error (code 255) at io.c(231) [Receiver 3.2.7] (255)!

 

Wo habe ich was falsch gemacht?

 

Über cli komme ich mit 

ssh [email protected] -i /root/.ssh/master

 

problemlos auf den Raspi.

 

Link to comment
  • 2 months later...

Hallo @mgutt,

 

ich möchte es gerne nochmal probieren und dich wie hier fragen wie ich den Standart Port ändern kann, damit ich es mit dem rsync-server und einen individuellen Port nutzen kann. Ich hab mehrere Sachen probiert, bin für so etwas aber zu blöd.

 

Vielen Dank!

Link to comment
  • 4 weeks later...

Ich überlege momentan, ob ich nicht in näherer Zukunft die Cache Pools auf einem ZFS-formatierten Filesystem laufen lassen soll. Die Mögllichkeiten von ZFS könnten backup routinen von den SSDs/NVMEs gerade auch bei VMs vereinfachen. Zumindest ist das hier in Uberlegung....

 

Ich würde dann Snapshots nehmen und wie Spaceinvader das in seinen ZFS-Videos zeigt, eine Harddisk im Array als ZFS formatieren als Ziel für Snapshots/Replikation von den ZFS Datasets von den SSDs

So weit so gut - kann man machen...

 

Aber bisher mache ich Backups vom Array (XFS Filesystem) und allen wichtigen Shares zur Zufriedenheit mit dem Script von @mgutt.

 

Meine Frage:

Könnte ich das Backup script (wohl momentan Vers 1.7) weiterhin verwenden um Backups vom Array zu nehmen auch wenn eine der Array Disks ZFS formatiert ist und ich natürlich mit dem Backup-Script auch die ZFS Datasets auf externe Datenträger, evlt sogar via SSH auf einen Externen Server übertragen will.

Bisher sind das nur USB3 Platten, die ich turnusgemäss wechsele und extern bewahre, aber vielleicht ist es sogar bessen einen externen Server zu haben....

 

Was sind die Konsequenzen, wenn ZFS datensets Teil des Backups sein sollen ?

- Permissions, etc...

- funktioniert die Hardlinks dann noch auf dem Ziel medium - mit XFS funktionierte immer alles - habe schon mehrmals was zurücksetzen müssen...

- Offenbar werden die Docker nicht wieder neu gestartet, aber sehr wohl gestoppt vor dem Backup ?

- Gibt es sonst noch irgendwelche Konsequenzen sollte ich dem Script ZFS formatierte Daten anbieten ?

 

Danke für Info von dem Stand der Dinge.

 

Unraid evaluiert immer mehr Richtung guter Unterstützung von ZFS - daher denke ich, dass es eine gute Idee ist sich mal genauer mit dem Thema auseinander zu setzen und nach Möglichkeiten des Vorteilhaften Einsatzes der neueren Technologie zu suchen...

Meine heutigen Cache drives sind NVME BTRFS Raid 1 ....

Link to comment

Edit: Vergiss es. Hat sich erledigt. War wirklich eine blöde Idee. Hab's einfach ausprobiert und gleich gesehen ...

 

---

 

@mgutt Ich hätte da mal eine blöde Frage zu Deinem Skript.

 

Kann man auch mit Subdirectories arbeiten? Ich habe einen Ordner den ich nur einmal wöchentlich komplett sichern will. Einen Unterordner davon will ich aber täglich sichern.

 

Könnte man das in einen Backup Ordner unterbringen oder muss ich dafür zwei Backup Ordner anbieten?

 

Vielen Dank.

 

# einmal woechentlich komplett
/mnt/pool_nvme/system/appdata/plex/ -->
   /mnt/disk1/Backup/plex/

# taeglich
/mnt/pool_nvme/system/appdata/plex/Library/Application Support/Plex Media Server/Plug-in Support/Databases/ -->
   /mnt/disk1/Backup/plex/Library/Application Support/Plex Media Server/Plug-in Support/Databases/

 

Edited by hawihoney
Link to comment
  • 4 weeks later...
1 hour ago, derjp said:

Kann mir jemand sagen warum er 3 mal gefailed ist?

Einfach im Log nach fail oder error suchen.

 

Ein Beispiel:

Quote

rsync: [sender] change_dir "/mnt/cache/syslog" failed: No such file or directory (2)

 

Den Pfad gibt es also nicht.

 

 

Link to comment
42 minutes ago, mgutt said:

Einfach im Log nach fail oder error suchen.

 

Ein Beispiel:

 

Den Pfad gibt es also nicht.

 

 

 

Dann ist das Problem vermutlich nur, das der Ordner groß geschrieben ist oder?

image.png.9794d81e549745c4d2e6071eea9588a8.png

Link to comment

Das docker.img konnte nicht gelesen werden, was beim laufenden Docker Betrieb evtl die Ursache sein könnte. Allerdings macht es auch keinen Sinn das zu sichern. Die Docker Umgebung (also das Image) enthält keine Nutzerdaten. Die liegen in appdata. 

Link to comment
7 minutes ago, mgutt said:

Das docker.img konnte nicht gelesen werden, was beim laufenden Docker Betrieb evtl die Ursache sein könnte. Allerdings macht es auch keinen Sinn das zu sichern. Die Docker Umgebung (also das Image) enthält keine Nutzerdaten. Die liegen in appdata. 

 Okay, die ganzen letzten Tage gab es damit kein Problem das zu sichern.

 

Aber okay, wenn es eh keinen Sinn macht das zu sichern, dann werde ich das rausnehmen. Die Appdata werden bei mir gesichert.

 

Wundert mich trotzdem, dass es vorher damit nie Probleme gab und nun auf einmal doch.

 

Aber danke für deine Antwort :)

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.