rsync Skript für inkrementelle Backups

[mgutt]

Viele kennen ja bereits mein Skript, mit dem man inkrementelle Backups erstellen kann:

 

Eigentlich sind sie streng nach Definition gar nicht "inkrementell", da jedes Backup ein 1:1 Vollbackup darstellt. Da aber mit Hardlinks gearbeitet wird, transferiert rsync nur neue Dateien, wodurch der Speicherplatzverbrauch genauso gering ist wie bei inkrementellen Backups. Meiner Ansicht nach sind Hardlink-Backups das bessere inkrementelle Backup, da man alte Backup-Ordner nach Belieben einfach löschen kann, während die restlichen Vollbackups erhalten bleiben. Bei einem klassischen inkrementellen Backup ist das nicht möglich, da das alle Folgebackups zerstören würde.

 

Jedenfalls habe ich nun Version 0.7 veröffentlicht, wo kleinere Fehler behoben wurden und es gibt auch neue Funktionen, die von anderen gewünscht waren:

- Sicherung auf SSH Server

- Temp, tmp, Cache ... Verzeichnisse ausschließen

- Benutzerdefinierte rsync Optionen

- Bessere Multi-Plattform Unterstützung (das Skript läuft nicht nur auf Unraid)

- diverse rsync-Hacks, die es erlauben auf SSH Server zu sichern, die ausschließlich das rsync Kommando erlauben

 

Gerade auf die rsync-Hacks bin ich echt stolz, da ich weltweit nichts dergleichen gefunden habe. Ich verschiebe zB komplette Ordner mit rsync ohne sie vorher zu kopieren oder ich lösche mit rsync, wo andere "rm" verwenden würden. Sogar das "find" Kommando konnte ich mit rsync ersetzen, um das letzte erfolgreiche Backup zu ermitteln. Dadurch können Administratoren einen SSH User verwenden, der ausschließlich das rsync Kommando verwenden darf.

 

Obwohl ich schon einige Zeit investiert habe, gibt es immer noch massig Ideen umzusetzen:

- besonders große Dateien wie vdisks splitten, um auch hier von Hardlinks zu profitieren

- wenn Ordner gesichert werden, die von Containern genutzt werden, soll dieser automatisch gestoppt werden

- Sicherung von SSH Servern (also als Quelle)

- vor dem ersten Vollbackup testen ob das Ziel Hardlinks unterstützt

 

Ich wurde auch gefragt, ob ich das nicht mal als Plugin herausbringen möchte. Der Haken daran ist, dass man sich dann die Möglichkeit verbaut das Skript auf anderen Plattformen einzusetzen. zB nutzen manche das Skript auf ihrer Syno und sichern damit auf ihren Unraid Server. Und wieder andere nutzen gar kein Unraid (buuuhh ^^). Ich müsste also einen Weg finden, womit ich das Skript 1:1 in einem Plugin nutzen kann. Muss ich mal sehen ob ich dazu irgendwann eine Lösung finde.

[mgutt]

 

4 hours ago, Death_Monkey said:

Ich habe mein Dateisystem etwas aufgesplittet und eine SSD auf der alle Docker / VM / Privaten (Sicherungswürdigen) Dateien sich befinden.

Alles andere auf Unraid bleibt nur über 2 Paritys abgesichert, sind "nur" Medien.

 

Daher würde ich gerne mehr oder weniger die komplette disk1 Sichern auf eine sich im Heimnetz befindliche Synology DS.

Funktioniert das mit dem Skript und dann auch das Aufwecken der DS über WOL, ich hab die DS118 dann nämlich nur rein dafür und wollte bedingt durch die Paritys vermutlich nur alle paar Tage sichern, da sich nicht sooo oft etwas darin ändert.

Oder führe ich dafür dann ein Skript aus zum aufwecken, dann etwas warten damit die auch hochgefahren ist und lasse dann dieses Skript im anschluss ausführen?

 

Die DS kann man über Zeitpläne automatisch ein- und ausschalten. Das Skript solltest du dann auf der DS ausführen, damit diese mit einem rein lesenden User die Daten von Unraid abholt. Ansonsten macht dein Backup-Konzept wenig Sinn, weil ja auch jeder Angreifer die DS hochfahren könnte und die Backups wieder löschen könnte. Auch kann nur der lokale root User der DS die Dateirechte aus Unraid 1:1 übernehmen. Mountest du dagegen die DS zB über SMB, dann machst du das nur als irgendein Nicht-Root-User und alle Dateirechte gehen kaputt.

 

Der Aufbau wäre als besser so:

- rsync server Container in Unraid installieren und read-only den Zugriff auf /mnt/user gewähren, außerdem den SSH Key der DS hinterlegen

- DS mit Einschaltzeitpunkten versehen

- rsync Backup Skript als Aufgabe in der DS hinterlegen (am besten irgendwo als Datei ablegen und in der Aufgabenplanung dann nur den Pfad zum Skript hinterlegen)

- am Ende des Skriptes noch einen shutdown-Befehl ergänzen, damit er nach dem Backup das NAS herunterfährt

 

Willst du trotzdem vom automatischen Docker-Stop / Start profitieren, musst du zusätzlich:

- auf Unraid ein Skript hinterlegen, was alle aktiven Container stoppt, dann einen Snapshot nach /mnt/cache/backup/appdata erstellt und die Container wieder startet (könnte ich dir noch zur Verfügung stellen)

- die DS soll dann NICHT /mnt/user/appdata, sondern /mnt/user/backup/appdata sichern (muss dann natürlich zu einem späteren Zeitpunkt erfolgen)

 

Das macht es zwar von der Einrichtung her etwas aufwendiger, aber es ist deutlich sicherer als mit vollen Lese- und Schreibrechten auf Quelle und Ziel zu agieren.

[Death_Monkey]

Ah danke, wenn ich dann mal alle Daten aufs Array kopiert habe werde ich wohl nochmal drauf zurück kommen.

Die Tips bzgl. Sicherheit werde ich aber beherzigen und das ganze dann noch etwas umkonfigurieren und einen Backup User erstellen.

 

Sorry wegen dem Post im anderen Thread, durch die Auto Übersetzung, dachte ich, ich wäre in diesem ^^

[Rockikone]

@mgutt

Hallo Mgutt,

ich setze dein Script bereits schon seit längerer Zeit ein um meinen Hauptunraid Server auf einen Unraid Backup Server zu sichern. Als Übertragungsweg verwende ich ssh, was soweit super funktioniert.

Nun habe ich auf meinem Hauptunraid Server TrueNas als VM installiert und eine PCI-Kontrollerkarte im IT Modus mit Platten an die VM durchgereicht. Funktioniert soweit super.

Jedoch bekomme ich das mit deinem Script nicht hin. Schlüsselaustausch (Unraid ---> Truenas) über ssh habe ich eingerichtet und funktioniert ohne Passwort.

Die Platten in Truenas sind gespiegelt (2x 15 TB) als ZFS.

 

Wenn ich das Script laufen lasse, werden in den dafür vorgesehen Ordnern in Truenas, das BackUP erstellt. Jedoch habe ich folgende Fehler

1. In deinem Script muss ich Zeile 239 auskommentieren, da das Script aufgrund Syntax Fehler abbricht

2. Beim Erstlauf wird das Vollbackup erzeugt. Jedoch beim zweiten Lauf wieder ein Vollbackup.

 

Kann es sein, dass TrueNas mit Hardlinks ein Problem hat. Es kommt jedoch keine Fehlermeldung im Script. ZFS als Dateisystem sollte doch okay sein?

 

Danke für evtl Hilfe

 

 

[mgutt]

42 minutes ago, Rockikone said:

1. In deinem Script muss ich Zeile 239 auskommentieren, da das Script aufgrund Syntax Fehler abbricht

Zeile 239 ist bei mir "else"?! Und Syntax Fehler habe ich noch nicht gehört. Sicher, dass du es als Bash und nicht Shell ausführst?

 

45 minutes ago, Rockikone said:

Unraid ---> Truenas

Denk dran, dass das Skript in dem Fall auf dem TrueNAS ausgeführt werden sollte. Siehe auch vorheriger Beitrag von mir.

 

 

[n3ro365]

Hallo.

Ich nutze dein Script ua um von einem Windows PC zeitgesteuert Backups zu machen. Das funktioniert auch soweit.

Wäre es möglich, dass Script auch manuell vom PC aus anzustoßen?

[kiesow]

Kann es sein, dass das Script beim Neustarten der Docker Container die Reihenfolge von /boot/config/plugins/dockerMan/userprefs.cfg ignoriert? Bzw. auch die Verzögerungen, die in der Unraid GUI bei Wait eingetragen werden, scheinen nicht berücksichtigt zu werden. 

Kann ich das irgendwie beeinflußen?

[mgutt]

On 2/2/2023 at 8:41 PM, OOmatrixOO said:

Wäre es möglich, dass Script auch manuell vom PC aus anzustoßen?

Dazu ist mir auch noch keine Lösung eingefallen.

 

5 minutes ago, kiesow said:

Kann ich das irgendwie beeinflußen?

Aktuell tatsächlich nicht. Muss ich mir mal anschauen, wie man das "nachbauen" könnte. Mir war wichtig, dass nur die Container gestartet werden, die auch gerade laufen. Wenn dir das egal ist, könntest du am Anfang des Skriptes das machen:

/etc/rc.d/rc.docker stop

 

und das am Ende:

/etc/rc.d/rc.docker start

 

 

[kiesow]

Ok, danke für den schnellen Tipp.

Dann werde ich mal die beiden Zeilen entsprechend ersetzen. zigbee2mqtt ist da echt empfindlich, wenn mosquitto beim Start noch nicht verfügbar ist ...

[tom233]

Hallo ,

das Skript ist super.

mein kleiner Unraid Server ist in eine neue Hardware umgezogen. Der Stick wurde nicht verändert  , auf der neuen Hardware bin ich von 6.0.9.2 auf 6.1.xx gewechselt.

 

Jetzt bekomme ich die Fehlermeldung:

 

cript Starting Feb 10, 2023 08:05.05

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

Stop containers:
0d5da0b13f8c
c8b4f39373f2
b1b506222f7e
Created snapshot of /mnt/cache/appdata to /mnt/cache/.appdata_snapshot
Start containers (fast method):
0d5da0b13f8c
c8b4f39373f2
b1b506222f7e
# #####################################
last_backup: '_'
date: invalid date '_'
/tmp/user.scripts/tmpScripts/test_mgut_neu/script: line 228: (1676012718 - ) / 86400 : syntax error: operand expected (error token is ") / 86400 ")
Script Finished Feb 10, 2023 08:05.18

Die besagte Zeile       last_backup_days_old=$(( ($(date +%s) - $(date +%s -d "${last_backup:0:4}${last_backup:4:2}${last_backup:6:2}")) / 86400 ))

habe ich nicht verändert.

 

Das Sicherungsverzeichnis liegt auf einem Backup Server  und ich habe die alten Backups in ein anderes Verzeichnis verschoben.

 

Die Sicherungspfade  sind gleich und auf der alten Kiste lief es tadellos.

 

Ist mein SSH Schlüssel durch die neue Hardware falsch ? oder hat das Skript eine Historie und weiß das im Sicherungsverzeichnis eigentlich Backups sein müssen ?

 

Vielen dank

VG Thomas

 

 

 

 

[Revan335]

55 minutes ago, tom233 said:

Ist mein SSH Schlüssel durch die neue Hardware falsch ?

Bei neuer Hardware oder Generierung ist auch der Key ein anderer.

[mgutt]

2 hours ago, tom233 said:

last_backup: '_'
date: invalid date '_'

Hast du das Skript von einer sehr alten Version aktualisiert? Früher waren die Pfade ein klein wenig anders. Wenn das so ist, müsste man alle Dateien aus dem letzten Backup eine Ebene höher verschieben (früher wurde nach /appdata/datum/appdata gesichert, heute nach /appdata/Datum)

[tom233]

 

Version 1.5 ist es eine alte ??

Das Verzeichnis ( siehe unten ) ./share1/appdata ist leer.

Den oberen Teil meines Scripts füge bei.

 

 

 

 

 

 

 

 

 

 

#!/bin/bash
# #####################################
# Name:        rsync Incremental Backup
# Description: Creates incremental backups and deletes outdated versions
# Author:      Marc Gutt
# Version:     1.5
# 
# Todo:
# - chunksync hardlinks for huge files (like images), rsync still misses --reflink
# - docker container stop and start for SSH sources
# - skip container stop if container CPU load is higher than X
# - resume if source went offline during last backup
# - create differential backup if full backup of the same day exists (which would make clean ups much faster), how to solve restore?
# - use external configuration file https://forums.unraid.net/topic/97958-rsync-incremental-backup/?do=findComment&comment=1081711
# - allow changing settings through script parameters like "-d14 -m12 /src /dst"
# - allow different timestamp formats for the destination path like YYYYMMDD, YYYY-MM-DD, etc
# #####################################

# #####################################
# Settings
# #####################################

# backup source to destination
backup_jobs=(
  # source                          # destination
  "/mnt/cache/appdata"              "[email protected]:/mnt/user/Tower2_Backup/rsync_test/share1/appdata"
#  "root@tower:/mnt/user/isos"       "/mnt/user/Backups/isos"
)

 

[mgutt]

23 minutes ago, tom233 said:

Version 1.5 ist es eine alte ??

Ne. Der Pfad hat sich in Version 0.9 oder so meine ich geändert. Dann ist es das nicht.

 

23 minutes ago, tom233 said:

Das Verzeichnis ( siehe unten ) ./share1/appdata ist leer.

Ach so. Dann ist das wirklich komisch. 

 

Führe das mal bitte auf dem Ziel aus:

 

mkdir /tmp/empty_dir

 

rsync --dry-run --recursive --itemize-changes --exclude="*/*/" --include="[0-9]*/" --exclude="*" "/mnt/user/Tower2_Backup/rsync_test/share1/appdata/" "/tmp/empty_dir"

 

rmdir /tmp/empty_dir

[tom233]

So ich bin jetzt etwas weiter..

Die Befehle habe ich auf dem Backup Server ausgeführt ,  es hat aber nichts geändert.

Der Fehler  ist immer noch da.

Ich habe dann den Dest. Pfad konventionell auf remote gesetzt und das Verzeichnis eingehängt, ich hatte zwar einige Fehler aber es ist durch gelaufen.

Ich habe die ssh Ordner von beiden Server gesichert und gelöscht, dann neue Schlüssel generiert.

 

Mit der Fehlermeldung:

 

root@Tower2:~# ssh [email protected]
hostfile_replace_entries: link /root/.ssh/known_hosts to /root/.ssh/known_hosts.old: Operation not permitted
update_known_hosts: hostfile_replace_entries failed for /root/.ssh/known_hosts: Operation not permitted

 

Ich habe die alten Schlüssel und Ordner wieder hergestellt, und folgenden Befehl auf beiden Server ausgeführt.

 

ssh-keyscan -H TARGET_HOST >> ~/.ssh/known_hosts

 

Jetzt läuft das Skript ohne Probleme durch.

 

Wenn ich ich mich über ssh vom backup server auf dem Hauptserver anmelde 

ist die Meldung  immer noch da

 

root@Tower2:~# ssh [email protected]
hostfile_replace_entries: link /root/.ssh/known_hosts to /root/.ssh/known_hosts.old: Operation not permitted
update_known_hosts: hostfile_replace_entries failed for /root/.ssh/known_hosts: Operation not permitted

 

 

 

 

 

 

[mgutt]

1 hour ago, tom233 said:

Die Befehle habe ich auf dem Backup Server ausgeführt ,  es hat aber nichts geändert.

Ich wollte das Ergebnis haben ^^

[tom233]

Nachdem  das Skript läuft sieht es so aus.

 

root@Tower2:~# rsync --dry-run --recursive --itemize-changes --exclude="*/*/" --include="[0-9]*/" --exclude="*" "/mnt/user/Tower2_Backup/rsync_test/share1/appdata/" "/tmp/empty_dir"
cd+++++++++ 20230211_210421/
cd+++++++++ 20230211_212834/
cd+++++++++ 20230211_213109/
cd+++++++++ 20230211_221758/
cd+++++++++ 20230212_183020/
cd+++++++++ 20230213_185737/

 

Aber als das Verzeichnis leer war gab es kein Ergebnis

 

 

[n3ro365]

On 2/9/2023 at 8:05 AM, mgutt said:

Dazu ist mir auch noch keine Lösung eingefallen.

 

...

 

 

 

Hi. Irgendwie eine bat Datei, die dann das Script ausführt wäre vllt was. Aber keine Ahnung, ob und wie man das umsetzen könnte.

[ullibelgie]

Was das Backup Script angeht nutze ich z.zt noch Vers 1.3

 

Im Englischen Forum fand ich zu den neuen Features von (damals) Vers. 1.4:

           " 1.) The script can be now called with source and destination path as arguments

           Example:

           /usr/local/bin/incbackup /src_path /dst_path "

 

Soll man also das Script nicht mehr über das Unraid-Plugin "user scripts" ausführen, sondern manuell im Terminal aus irgendwelchen Gründen?

Ich fand das Plugin hilfreich, da es ja die Möglichkeit bietet den Backup Prozess über Cron zu automatisieren .

Was ist der Vorteil dieses neuen Features ?

 

Ich sichere Appdata gesondert mit den Appdata plugin - dann gibt es wohl z.Zt noch keinen ganz triftigen Grund um auf die neueste Version zu updaten ?

Denn alles läuft aktuell ohne Probleme...

 

Zumindest würde das Belassen auf Vers 1.3 erstmal einige Arbeit ersparen, bevor ich auf ganz neue Hardware mit meinem Unraid Server wechseln kann.

[mgutt]

1 hour ago, ullibelgie said:

Soll man also das Script nicht mehr über das Unraid-Plugin "user scripts" ausführen, sondern manuell im Terminal aus irgendwelchen Gründen?

Das neue Feature ist optional. Man kann es auch nach wie vor per User Scripts ausführen.

 

1 hour ago, ullibelgie said:

Was ist der Vorteil dieses neuen Features ?

Man könnte sich das Script irgendwo hinlegen und per User Scripts eine Zeile pro Pfad ausführen:

 

Später plane ich noch die anderen Optionen wie die Aufbewahrungszeiten hinzuzufügen. Erst so schaffe ich die Basis das vielleicht mal als Plugin umzusetzen.

 

Sonstige Vorteile hat man bei der neuen Version nicht.

[ullibelgie]

Ah ja, das würde das Sammelsurium der vielen userscripts (1 script per Unraid client) vereinfachen.

Aber wo legt man dann das script ab, dass es von dem "master"-userscript wie oben in dem Bild auch ausgeführt wird.

Ich steh' auf'm Schlauch...😕

 

 

[mgutt]

7 hours ago, ullibelgie said:

Aber wo legt man dann das script ab, 

Naja. Irgendwo ^^

 

Wenn ich mal alle Optionen verfügbar gemacht habe, werde ich dazu aber auch noch mal Anleitungen schreiben.

 

 

[Ironcurtain]

Hi,

 

ich habe bei mir 2* Externe 2,5 Zoll 5TB Festplatten. Eine davon lagere ich immer off-site. Ich wechsel die beiden Platten jede Woche. Das beduetet eine davon liegt immer bei mir und ich schließe diese 1* am Wochenende an meinen unraid Server. Ich würde dann manuell das Skript starten und ein inkrementelles Backup machen. Nächstes Wochenende hätte ich dann die andere Platte zu Hause und würde bei dieser ein inkrementelles Backup machen. Ich habe dabei ein sehr wichtiges Verzeichnis wo die inkrementellen Backups der letzten 2 Jahre beibehalten werden müssen. Bei anderen Verzeichnissen reicht es wenn die letzten 3 Sicherungen behalten werden.

Kann man sowas bei diesem Skript realisieren? Da man ja Parameter für täglich, monatlich etc. eingeben muss. Ich sichere aber nur 1* die Woche auf zwei verschiedene Platten im Wechsel.

[mgutt]

Just now, Ironcurtain said:

Kann man sowas bei diesem Skript realisieren? Da man ja Parameter für täglich, monatlich etc. eingeben muss. Ich sichere aber nur 1* die Woche auf zwei verschiedene Platten im Wechsel.

Dem Skript ist das ziemlich egal. Es nimmt das letzte Backup was auf der Platte findet und macht damit das nächste inkrementelle Backup. Die Aufbewahrungsregeln werden auch ganz normal angewendet. Willst du zb 2 Jahre aufbewahren, wird er alles was älter ist als 2 Jahre löschen. Und zwar bei jeder Platte separat, wenn sie dann angeschlossen ist. Dass das Skript irgendwas vorher mal gemacht hat, merkt es sich nicht. Es gibt also Null Abhängigkeiten zu irgendwas. Du könntest das Skript für verschiedene Pfade und mit verschiedenen Aufbewahrungsregeln ja auch mehrfach hinterlegen.

 

Denk aber dran, dass du die Platten in einem Format formatierst, wo auch Linux-Dateirechte geschrieben werden können. Also kein NTFS und kein FAT32, sondern XFS oder BTRFS oder ext4.

[bastl]

Hallo zusammen.

 

Danke erstmal an @mgutt für das super Script!

 

Ich bin darüber gestolpert, als ich auf der Suche nach einer einfachen Möglichkeit war meine Nextcloud Daten von Unraid auf ne Synology im gleichen Netzwerk zu sichern. Gesagt, getan. Script in User Scripts hinterlegt, auf dem NAS nen Share erstellt, als NFS Share mit UD gemounted, Pfade im Script angepasst und Feuer frei.

Wie zu erwarten bei 106GB (knapp 106000 Dateien) hat die erste Sicherung gut über ne Stunde gedauert bis sie durch war. Seitdem hat sich an den Daten auch nicht großartig was geändert. Gesichert wird appdata, der Nextcloud Userdaten Ordner und der Unraid USB Stick.

 

 

Als ich eben aus Interesse die 2te Sicherung angestoßen hab, hat diese ebenfalls ziemlich genauso lang gedauert wie die initiale Sicherung, knapp über ne Stunde. Sicherung wurde etwa 12Uhr gestartet und war 13:10Uhr fertig. Was mich ein wenig verwundert hat.

 

 

 

 

Hab dann auf dem NAS nach der Größe der Sicherungen geschaut und diese wurde mir dann ziemlich genau doppelt so groß angezeigt, wie die erste Sicherung allein.

 

 

 

 

 

Ist das normal bei Hardlinks? Eigentlich nein, oder versteh ich da was falsch? Hab ich etwas übersehen? Bin gerade ein wenig ratlos. Am Script selber hab ich nichts weiter verändert, als die Pfade zu hinterlegen, Rest ist default.

 

Falls mich jemand in die richtige Richtung schubsen könnte, woran es liegt, wäre ich sehr dankbar.

 

MfG