Am Freitag 01 Oktober 2010 schrieb Heinz Diehl: > On 01.10.2010, Dirk Salva wrote: > > rsync -aHvzx --numeric-ids --delete --sparse --stats --exclude > > "proc/*" --exclude "sys/*" /quelle /ziel > > > > Weiss jemand ad hoc, wo der Unterschied zwischen den beiden o.g. > > Befehlen bzw. Optionen ist (also in Auswirkungen ausformuliert)? > > Die kurze Variante von mir reicht aus fuer deine Zwecke :-) > "numeric-ids" kannst du dir sparen, Wenn die Synchronisation auf einen anderen Rechner geht, kann es ohne -- numeric-ids ziemliche Probleme geben: Ich habe auf dem Quellsystem zum Beispiel zwei Benutzer: 1000 martin 1001 daniela Auf dem Zielsystem habe ich: 1000 klaus 1001 martin und keine "daniela". rsync übersetzt in diesem Fall martin namensgebunden auf 1001 und läßt daniela ebenfalls bei 1001 ;-). Da wünsche ich viel Spaß beim späteren Auseinanderbasteln der Eigentümer von Dateien. Bevor ich über solche Konstellationen nachdenke, nehme ich beim Backup auf ein Fremdsystem *immer* --numeric-ids. > ebenso wie das excluden von /proc > usw., es macht keinen Sinn, da das meiste sowieso wieder dynamisch > angelegt wird. Schonmal versucht, ein System aus dem laufenden Betrieb heraus via rsync ohne "/proc" zu excluden, zu sichern? Je nach verwendetem Kernel wünsche ich Dir viel Spaß dabei. Nun, okay, es scheint nicht mehr ganz so schlimm zu sein, wie früher: shambhala:~#23> du -sch proc 13M proc 13M insgesamt shambhala:~#23> du -sch sys 11M sys 11M insgesamt Aber trotzdem sind das 24 MiB, die rsync vollkommen überflüssigerweise mitsichert. Bei früheren Versuchen hatte ich noch eine Kernel-Option drin, die den gesamten Speicherinhalt über eine Datei in /proc zugänglich macht. Und das waren da einer nochmal zwei MiB extra. Ganz zu schweigen von den vielen Fehlermeldungen beim Versuch /proc und vor allem /sys zu sichern. Ich sehe lieber nur die Fehlermeldungen, die für mich relevant sind. Gerade bei /sys dauert das Kopieren via rsync durch die komplexe Hierarchie auf meinen ThinkPad T42 gefühlt mindestens 2 Minuten. Auch /tmp/**, /var/tmp/** und bei den heutigen Internet-Geschwindigkeiten in der Regel auch /var/cache/apt/archives/*.deb ist vollkommen überflüssig mitzusichern. Daher bleibt mein Votum: shambhala:~> cat backup/debian-exclude /dev/.udev /proc/** /sys/** /tmp/** /var/cache/apt/archives/*.deb /var/tmp/** > Der GROSSE Unterschied ist das "--delete", es bewirkt, dass "Ziel" > genau auf "Quelle abgeglichen wird". Sind also Dateien bereits in > "Ziel", welche in Quelle fehlen, dann werden sie einfach geloescht. > Das ist zu empfehlen, wenn du oft auf das gleiche Backup abgleichst, > ansonsten ist es mehr fehlertraechtig als nuetzlich. Es ist nur in einem Fall fehlerträchtig: Wenn Quelle und Ziel nicht exakt aufeinanderpassen. Bei regelmäßigen Backups der gleichen Quelle auf das gleiche Ziel halte ich --delete für sehr empfehlenswert, sonst bleiben im Backup Dateien erhalten, die in der Quelle längst gelöscht sind, was sogar dazu führen kann, dass rsync neu erstellte gleichnamige Dateien nicht anlegen kann. In diesem Fall würde ich aber mit einem Skript arbeiten, wo ich einmal ganz genau geprüft habe, dass Quelle und Ziel aufeinander passen. rsync -n ist da durchaus auch hilfreich, um erstmal einen Probelauf zu starten. > > BTW: gibts ausser proc und sys (und wohl auch tmp) nochwas, was man > > excluden kann? > > Vergiss' es, mach einfach dein Backup, alles wird gut :-) > Der Aufwand lohnt sich nicht. Da bin ich anderer Meinung. 2-3 Minuten und >500 Fehlermeldungen weniger lohnen sich. Zumindest wenn das Backup regelmäßig erfolgt. Und eine geeignete exclude-Datei einzubinden, wie ich sie nun in diesem Thread zum zweiten Mal anbot, finde ich nun wirklich nicht aufwendig. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.