[Eisfair] rsnapshot 1.2.0

[Marcus Roeckrath]

Hallo Hilmar,

Hilmar Böhm wrote:

> Aber das sind schon sehr spezielle Überlegungen. Ich frage mich auch was
> bei Monaten mit 5 statt 4 wöchentlich Backuptagen passiert... (aber wenn
> das wichtig werden sollte, sollte man sich nach einem besseren
> Backup-System/App umschauen.)

IMHO unproblematisch, jedenfalls passiert beim Hochkopieren nichts, denn da
wird immer das letzte (höchste) zu dem 0 des nächsten Levels.

Übrigens passiert dieses Hochkopieren sowieso nur, wenn für den Vorlevel
auch die Zahl der Backups voll ist.

Bei 5 für wöchentlich, wird am 1. eines Monats die weekly.5 zu monthly.0
sofern weekly.5 existiert, was aber nach 5 Wochen der Fall ist und dann
auch immer so bleibt, denn nach Hochmoven wird mit dem nächsten weekly-Job
der fünfte wieder angelegt..

Bei 4 für wöchentlich muss .4 existieren, bis erstmalig ein monthly.0
angelegt wird.

> Wichtig für den Übertrag ist halt, dass der Backup-Job eines Lvels
> abgeschlossen sein muss, bevor der Job eines nächsten Levels beginnt.

Genau.

> Das ist u.a. wichtig beim Einrichten der eigener Backupzeiten. (Und
> muss auch beachtet werden, wenn man die Default-Backupzeiten verwendet!
> Ne Viertelstunde kann u.U. schon zu knapp sein.).

Wie ich schonmal schrieb, wird nur im unterstenLevel bei .0 wirklich kopiert
und dann mit Hardlinks gearbeitet, das geht sehr schnell.

Die von Alex gemachten Defaults sind auch deshalb als Voreinstellung für den
Heimbedarf zu sehen und bislang - das Originalpaket ist uralt - scheint es
damit auch keine Probleme zu geben.

Wer das Paket in einer ganz anderen Umgebung benutzt, ist Fachmann oder wird
auf professionelle Lösungen setzen.

Hier mal ein Log für den letzten nächtlichen Aufruf von daily und weekly mit
den Standardeinstellungen:

[2018-07-22T00:30:04] /usr/bin/rsnapshot weekly: started
[2018-07-22T00:30:04] echo 22315 > /var/run/rsnapshot.pid
[2018-07-22T00:30:04] mv /mnt/.../daily.6/ /mnt/.../weekly.0/
[2018-07-22T00:30:04] rm -f /var/run/rsnapshot.pid
[2018-07-22T00:30:04] /usr/bin/rsnapshot weekly: completed successfully

Der mv braucht keine Zeit, denn da wird nur im Dateisystem umgehängt, die
Datenmenge interessiert nicht.
 
[2018-07-22T00:45:04] /usr/bin/rsnapshot daily: started
[2018-07-22T00:45:04] echo 4107 > /var/run/rsnapshot.pid
[2018-07-22T00:45:04] mv /mnt/.../daily.5/ /mnt/.../daily.6/
[2018-07-22T00:45:04] mv /mnt/.../daily.4/ /mnt/.../daily.5/
[2018-07-22T00:45:04] mv /mnt/.../daily.3/ /mnt/.../daily.4/
[2018-07-22T00:45:04] mv /mnt/.../daily.2/ /mnt/.../daily.3/
[2018-07-22T00:45:04] mv /mnt/.../daily.1/ /mnt/.../daily.2/
[2018-07-22T00:45:04] /bin/cp -al /mnt/.../daily.0 /mnt/.../daily.1
[2018-07-22T00:45:13] /usr/bin/rsync -a --delete --numeric-ids --relative
--delete-excluded /data/ /mnt/.../daily.0/.../
[2018-07-22T00:45:15] touch /mnt/.../daily.0/
[2018-07-22T00:45:15] rm -f /var/run/rsnapshot.pid
[2018-07-22T00:45:15] /usr/bin/rsnapshot daily: completed successfully

Das läuft alles ganz schnell und obiges sogar per USB angeschlosseneer HD.

Wenn erstmal das allererste Backup des untersten Level existiert, ist im
Normalfall der Rest kaum noch ein Zeitthema, solange da nicht Terabytes
ständiger Änderung unterworfen sind und dann sollte man sich nicht mit
Hobbylösungen zufrieden geben.

Zeitkritisch ist nur der unterste Level und da in der Regel auch nur die
Erstanlage.

>  > Du kannst sie mit "fcrondyn -x ls | grep snapshot" abfragen
> Super, wieder was gelernt... :-)
> Einbauen: Wäre schön, aber ich will nicht unverschämt sein... :)

Vielleicht aber doch besser schlicht die cron-Datei anzeigen lassen, oder?

-- 
Gruss Marcus