Re: Inkrementelles Backup basiert auf Hardlinks?
Am Mittwoch, 1. August 2012 schrieb Michael Stummvoll:
> Hallo Freunde,
Hi Michael,
> Ich arbeite gerade an meiner Backupstrategie. Dabei würde ich gerne
> etwas machen, das so ähnlich vorgeht wie Time Machine von OSX:
>
> - Jedes Backup ist ein kompletter Spiegel (also wie man mit rsync
> backuped halt)
> - Nicht geänderte Dateien sind Hardgelinkt auf dieselbe Datei des
> Backups davor.
[…]
> rsync scheint ein solches verhalten nicht von Haus aus zu können und
> ich habe gerade keine Idee, wie ich da am besten rangehe, um solche
> Backups effizient anzulegen. Für Hinweise bin ich Dankbar
Es gibt unzählige Tools, die auf rsync aufsetzen, und das können.
Ich löse mittlerweile für mich privat die Sache mit BTRFS, rsync und
btrfs subvolume snapshot -r
Also ohne Hardlinks. Weiß ich noch nicht mache ist rsync --inplace. Ist
aber mitunter sinnvoll, da sonst rsync eine geänderte Datei erst als Kopie
erstellt und dann wieder umbenennt. Ich weiß nicht, ob dann der Vorteil
eines Schnappschuss, dass nur die geänderten Daten in einer Datei Platz
belegen, noch greift. Ich glaube das ist der Hintergrund für die
Empfehlung --inplace zu nutzen. Wenn rsync die Datei vor dem Ändern wie cp
--reflink kopiert dann nicht. Möglicherweise gibts da in rsync
mittlerweile eine Option für – sieht aber auf den ersten Blick nicht so
aus. Naja, Linux 3.6 wird ja btrfs send/receive enthalten, derzeit noch
experimentell, das ja dann irgendwann auch mal stabil ist und bedeutend
schneller sein soll als rsync. So oder so, ich hab schon einige
Schnappschüsse, die von den ca. 893 belegten GiB gefühlt nicht mal 50 GiB
verbrauchen – auch das soll mit Kernel 3.6 und Subvolume Quotas sich dann
leichter ermitteln lassen –, bei 1,9 TiB Kapazität. Also was solls? Mehr
als einige Schnappschüsse brauch ich ja auch nicht.
Ja, ich weiß, die Upstream-Variante von BTRFS ist immer noch als
experimentiell markiert.
Doch ich habe auf den von mir genutzten BTRFS-Dateisystemen bislang noch
kein Byte verloren. Das älteste Dateisystem ist dabei über ein Jahr alt.
Und die externe Platte hat auch schon lange ein BTRFS.
Und: Mit Scrubbing habe ich die Möglichkeit, BTRFS zu fragen, ob die Daten
noch in Ordnung sind. Diese Möglichkeit bietet mir derzeit kein anderes
Dateisystem, das direkt im Kernel enthalten ist. Gerade fürs Backup finde
ich das nett.
Und durch „-r“ sind die Snapshots nur lesbar. D.h. wenn ich mich mal in
der Angabe des Backup-Ziels verhaue, richte ich auch mit rsync und Option
„--del“ keinen Schaden an.
Das ist keine Empfehlung mir. Ich übernehme auch keine Verantwortung,
dafür, wenn jemand das so macht und dann Probleme hat. Use at your own
risk ;)
Ich habe mein /home auch immer noch auf Ext4. Doch wenn die Backup-
Geschichte nun auch noch einige Monate so gut durchläuft, dann kommt auch
/home auf ein BTRFS. Durch die SSD dürften sich etwaige Performance-
Verluste, die bei BTRFS und bestimmten Szenarios durchaus immer noch
auftreten können, in Grenzen halten. Und die Komprimierung sollte einiges
an Daten in meinem /home ordentlich zusammendampfen können, so z.B. die
gigantische Menge an Mails, Quelltext-Repository-Clones und vieles weitere
mehr. Bei JPEG-Bilder und MPEG3-Dateien geht natürlich nix.
Ich mache die Snapshots nach Ausführen meines Backup-Skripts oder eines
manuellen rsync für die externe Platte, für die ich derzeit kein Skript
hab, da eh nur ein rsync-Aufruf, bislang manuell. Aber ich denke, das
skripte ich mir dann mal.
Das nur mal so als Erfahrungsbericht. Ich mach das seit 19. Juni so und
sichere etwa alle 2 Wochen. Da externe Platte und Stöpselei. Für
Langzeit-Erfahrungen reichts also noch nicht.
Ich denke hin- und wieder in Richtung NAS, bin aber immer noch nicht
schlüssig. Etwas was dauernd läuft möchte ich aufgrund des Stromverbrauchs
eher nicht. Es sei denn, es ist wirklich sehr sparsam und leise.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: