Rdiff-backup: pokus o Time machine na Linuxu

24.7.2008 15:02 | Přečteno: 3009× | Linux | poslední úprava: 24.7.2008 15:02

Docela dlouho jsem pro zálohování dat a současně synchronizaci mezi počítači používal rsync. Při posledním spuštění skriptu a kontrole zálohy jsem však zjistil, že se něco stalo a dlouho funkční skript nefunguje. Nevím, zda došlo k nějaké změně přímo v rsyncu, v implementaci fatu, nebo je problém s flashkou. Pokud se zálohovaný soubor změní, skript ho na flasku nepřekopíruje. Po formátu flashky vytvořil skript pouze adresářovou strukturu bez jediného souboru, i když celá akce trvala srovnatelně, jako by se skutečně kopírovalo.

Protože mám teď docela dost času na hraní, a navíc mám o prázdninách všechny kompy doma, takže odpadá nutnost synchronizace (používám více méně jen jeden), rozhodl jsem se vyzkoušet rdiff-backup, který mi byl doporučen v diskuzi pod minulým zápiskem o zálohování.

Následuje jednoduchý skript, který se stará o zálohování:

[nik@venice ~]$ cat /etc/cron.hourly/rdiff_backup_0.1.sh
#!/bin/bash

#Backs up the whole $HOME directory to /backup/$USER
#Specified directories are excluded
#Cleans up backups older than specified time
#Intended to be run by Cron daily or hourly
#For more consult http://www.nongnu.org/rdiff-backup or man rdiff-backup

#Put paths to $source and $target variables
source=$HOME
target="/backup/$USER"

#How long to keep old backups
period="1W"

#Directories to be excluded
e1="/home/nik/Dokumenty/Video"
e2="/home/nik/Dokumenty/Hudba"
e3="/home/nik/Dokumenty/Torrent"

#Rdiff driven backup, rdiff itself makes log
rdiff-backup --exclude $e1 --exclude $e2 --exclude $e3 $source $target

#Chown rdiff-backup files
chown -R $USER:users /backup/$USER/rdiff-backup-data/

#Removes older backups
rdiff-backup --remove-older-than $period --force $target

Volby --exclude umožňují vyjmout jednotlivé složky ze zálohování, u mě se tak děje především kvůli nedostatku místa na cílové partici. Volba --force je při mazání starých záloh užitečná, bez ní nedojde ke smazání většího počtu starších záloh, což se projevilo rychlým zaplněním /backup.

Protože skript vytvářel adresář /backup/$USER/rdiff-backup-data vlastněný rootem, přidal jsem ještě řádek, který mění vlastníka na aktuálního uživatele. To mu umožní provést užitečné příkazy vypisující všechny diffy daného souboru nebo například zobrazit statistiky:

[nik@venice ~]$ rdiff-backup -l /backup/nik/japan.jce
Found 5 increments:
    japan.jce.2008-07-18T12:01:01+02:00.diff.gz   Fri Jul 18 12:01:01 2008
    japan.jce.2008-07-20T11:01:02+02:00.diff.gz   Sun Jul 20 11:01:02 2008
    japan.jce.2008-07-22T13:01:02+02:00.diff.gz   Tue Jul 22 13:01:02 2008
    japan.jce.2008-07-22T14:01:03+02:00.diff.gz   Tue Jul 22 14:01:03 2008
    japan.jce.2008-07-23T10:01:01+02:00.diff.gz   Wed Jul 23 10:01:01 2008
Current mirror: Wed Jul 23 18:01:01 2008

[nik@venice ~]$ rdiff-backup --calculate-average /backup/nik/rdiff-backup-data/session_statistics*
--------------[ Average of 43 stat files ]--------------
ElapsedTime 67.14 (1 minute 7.14 seconds)
SourceFiles 55040.2093023
SourceFileSize 15648105481.5 (14.6 GB)
MirrorFiles 55023.1860465
MirrorFileSize 15629970536.8 (14.6 GB)
NewFiles 101.209302326
NewFileSize 85438806.3721 (81.5 MB)
DeletedFiles 84.1860465116
DeletedFileSize 65418928.5581 (62.4 MB)
ChangedFiles 142.930232558
ChangedSourceSize 89133032.9767 (85.0 MB)
ChangedMirrorSize 91017966.093 (86.8 MB)
IncrementFiles 328.488372093
IncrementFileSize 67880095.186 (64.7 MB)
TotalDestinationSizeChange 86015039.8837 (82.0 MB)
Errors 0
--------------------------------------------------------

Obnovení zálohovaných souborů je možné několika způsoby:

Pokud důvod pro obnovu vznikl v době od poslední zálohy, stačí zkopírovat příslušný soubor pomocí preferovaného souborového manažeru, nebo konzole:

[nik@venice ~]$ cp /backup/nik/japan.jce japan.jce.orig

Pokud se něco pokazilo dříve, je vhodné nejprve zjistit, ze kterého diffu obnovovat (viz výše uvedený příklad vypsání diffů), a pak vybraný diff obnovit příkazem:

[nik@venice ~]$ rdiff-backup /backup/nik/rdiff-backup-data/increments/japan.jce.2008-07-18T12\:01\:01+02\:00.diff.gz japan.jce.2008-07-18

Mnoho příkladů použití nástroje rdiff-backup obsahují oficiální stránky projektu.

V této chvíli mě rdiff-backup chrání především proti vlastní nepozornosti. Pokud bych zálohu prováděl na druhý disk, případně na domácí server (ani jedno však v tuto chvíli nemám), byl bych docela dobře zajištěn i proti selhání hardwaru. S dostatečně velkou flashkou nebo externím diskem by šlo vyřešit i problém synchronizace.

       

Komentáře

[progdan]

No asi bych si mel taky neco takoveho zavest...nejdriv ale musim sehnat dostatecne velke uloziste

[kralyk z abclinuxu]

+1 taky ten problem resim

[andree]

hmm, nejak to nikde nemozem najst - asi to sam vyskusam, ale predsalen sa opytam.. vie ten rdiff vyriesit aj situaciu, ked dojde k vymazaniu suboru? myslim takyto scenar:

%dir1=file1 file2 file3
rdiff-backup
delete dir1/file2
rdiff-backup

ked potom zavolam obnovu zo zalohy, znovu by to obnovilo aj ten file2? (to by som chcel, aby ostal zmazany ) ak by ho neobnovilo, je mozne sa vratit do nejakej starsej verzie, v ktorej by ten subor bol? viem si predstavit este viac 'okrajovych pripadov' (napr. ze by bol ten file2 znovy vytvoreny a zavolany rdiff-backup a clovek by sa chcel vratit k situacii bez file2, alebo so starsou verziou file2), ale toto by asi stacilo na rozumne zalohovanie...

[andree]

ok, nedalo mi to funguje to tak, to je parada :o))

[Nicky726]

Ano, toto rdiff-backup umí. Poslední verze souborů (z poslední zálohy) je jako mirror, starší verze souborů (od předposlední zálohy dále do minulosti) jsou jako diffy (včetně těch smazaných souborů). Pro obnovu pak stačí obnovit patřičný diff. To samé bude možné i pokud se soubor znovu vytvoří s jiným obsahem, budou totiž diffy dva.

[disorder]

je to dobre, ale nieco sa pokazilo po case a ked si zalohujem home, tak sa mi to zdrbe (debian etch)

[disorder]

pokazeny fs, po oprave to pada na nejakom CRC checku, nevedel som to opravit :/

[Honza Jaroš]

Hmm, tak to bude asi chtít zkusit parametr --force, ale nejsem si jist, jestli v takovém případě nezačne rovnou z čistého stolu a nesmaže starší verze záloh. Pokud jsou porušené diffy, asi mu nic jiného nezbyde...

[disorder]

nejak ma to nepali, tak som sam zmazal celu zalohu a spravil novu... ale zaujimalo kedy sa mi to mohlo poskodit, nespominam, ze by som zabudol umount :/

[Honza Jaroš]

Mně se to stává u 2.5" HDD v levné škatuli napájené přes USB. I když ho korektně odpojím včetně sync, nevyprázdní se cache přímo na disku a po vytažení USB kabelu se to už bez napájení samozřejmě nezapíše. Řeším to tak, že před vytažením kabelu provedu hdparm -t /dev/sdb, to obvykle pomůže.

[disorder]

dik, mam to externe tiez cez nejaky lacny radic

[Heron]

Umí to zálohovat i ACL? Případně, pokud ne, neznáte něco co to umí?

[Heron]

Odpovím si sám, podle dokumentace umí

[Nicky726]

Co se práv týče, jde spíš o použitý systém souborů, záloha z ext3 na ext3 prává zachovává.

[Heron]

No klasická práva ano, mě šlo o ACL (set-getfacl). Udělám experiment, doma.

[Heron]

Hmm, takže neumí

getfacl /var/www/drupal/modules/
getfacl: Removing leading '/' from absolute path names
# file: var/www/drupal/modules
# owner: apache
# group: apache
user::rwx
user:tomas:rwx
group::rwx
mask::rwx
other::r-x

#backup, restore - oba lokalni fs a umi ACL

getfacl /root/tmp/modules/
getfacl: Removing leading '/' from absolute path names
# file: root/tmp/modules
# owner: apache
# group: apache
user::rwx
group::rwx
other::r-x

Škoda

[Heron]

#rdiff-backup --never-drop-acls /var/www/ /BACKUP/www
Fatal Error: --never-drop-acls specified, but ACL support
disabled on destination filesystem

#tune2fs -l LABEL=backup
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   backup
Filesystem UUID:          15829cd4-5d25-496c-90f4-32d62ef7865c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    user_xattr acl

[VSi]

Mě to s ACL funguje. Myslím, že bylo potřeba doinstalovat zvlášť ještě nějakou python knihovnu - v debianu python-pylibacl.

[Heron]

S tím to funguje, díky.

[zelial]

v minulé práci jsem rdiff-backup používal a vím, že ACL uměl. dokonce i při záloze na ne-ACL oddíl - uložil si ty údaje někde bokem...

[Honza Jaroš]

Jenom doplním - zachovává je pouze u lokální kopie nebo pokud zalohujete na vzdálený stroj s právy roota. Pokud se na vzdálený stroj přihlašujete pod běžným uživatelem, jsou soubory záloh vlastněny tímto uživatelem a původní oprávnění k nim jsou uložena v metadatech v adresáři rdiff-backup-data; samozřejmě při obnově to pak chce používat 'rdiff-backup -r ...', jinak se práva k souborům neobnoví.

[Kyosuke]

A rsnapshot nedělá to, co potřebuješ?

[Nicky726]

To vypadá zajímavě, zatím jsem nezkoušel.

[sssssssss]

hehe, tak po přečtení nadpisu jsem si řikal "cože?" a po přečtení zápisku a diskuze "aha". Ještě tomu dát GUI a klikátka ať je to použitelný i pro ty "normálnější" uživatele linuxu.

[lmanik]

takove mensi ot... "normalnejsi" gui nepotrebuji :) a jine uzivatele neznam, jinak diky za typ, uz dlouho se chystam k necemu podobnemu a tohle me konecne nakoplo

[msk]

Su tomu tak 3-4 roky, co som zacal riesit (automatizovane) zalohovanie v jednej malej firme na dvd-rw media. Najrpv to bol hlupy script typu tar + growisofs, potom som sa dostal nad 4GB, takze som presiel na afio + growisofs na viac medii, potom som zacal pisat projekt sb2dvd ( este umiera na sf.net ), napisany v pythone. Potom dlho nic, dva roky to nejak bezalo a cca pred mesiacom som narazil na rdiff-backup. Po chvili badania som si dal dve-tri facky, kupil dve 16GB usb flashky a zalohujem na ne na striedacku pomocou rdiff-backup. V pripade, ze niekto zabudne pripojit flashku v dany den, maju bfu useri moznost jednim kliknutim pustit manualny backup ( cez webmin ), statistiky backupov mi sleduje zorba.