Zálohování pomocí rdiff-backup

7.8.2010 23:20 | Přečteno: 6624× | Linux |

Konečně jsem začal trochu systematicky zálohovat. V tomto zápisu se chci podělit o můj postup a hlavně si ho uchovat pro zapamatování.

Popis situace a požadavků

Zdroj zálohování: Mám linuxový desktop, na kterém soustředím všechny své dokumenty, rodinné fotky apod., zatím řádově desítky gigabytů. Podle objemu dat je třeba volit velikost zálohovacího disku. Na tomto stroji musí být nainstalovaný rdiff-backup. Původně jsem někde vyčetl, že musí být i na cílovém stroji, ale to se dá za určitých okolností obejít mountováním do lokálního adresáře, viz dále.

Cíl zálohování: Obecně jsem chtěl něco, co nepojede non-stop, ale zapnu si to jen podle potřeby. Vzhledem ke kapacitě, pracnosti a ceně jsem zavrhl DVD, BlueRay nebo flashky. Nakonec jsem se přiklonil ke dvěma variantám - ne snad, že bych najednou začal s dublovaným zálohováním, ale proto, že shodou okolností jsem to zálohování řešil současně pro dvě domácnosti.

1. starý počítač (AMD Duron 650, asi by šlo použít i něco ještě staršího) - sestavil jsem ho ze všelijakých zbytků, nakonec jsem našel i starší 120 GB disk, který mi zatím stačí
2. ZyXEL NSA210 + nějaký 1 TB disk = asi 3500 Kč. Dalo by se pořídit asi i něco levnějšího a jednoduššího, ale tento NAS disk má celkem pěkné možnosti na začlenění do domácí multimediální sítě, což by se mohlo časem hodit. Nebo naopak něco lepšího s více disky v RAIDu.

Ostatní požadavky: Kromě výše uvedeného je nutným předpokladem zasíťování celé domácnosti. Máme nový domeček a s něčím takovým jsem počítal - v každé místnosti LAN zásuvka, vše vyvedeno na půdičku, kde je switch, na komíně bazmek, který mě bezdrátově připojuje do světa, a zásuvky na 230 V. Nemusíte to mít pochopitelně takto pohodlně, ale obě řešení vyžadují připojení zdroje i cíle zálohování zapojené do sítě, třeba i napůl bezdrátové. To první řešení se starým počítačem je trochu hlučnější a náročnější na prostor (neřeším to, poněvadž stejně skončí na půdičce vedle switche), ale ten NAS disk můžete mít takřka kdekoliv - prostorově je to velké asi jako kniha a ten větráček při občasném zapnutí NAS disku nevadí, ale pokud byste ho měli v provozu pořád, tak bych to umístění doporučil promyslet.

rdiff-backup

rdiff-backup jsem si zvolil proto, že by měl umět inkrementální zálohy s možností návratu ke kterékoliv verzi, přičemž jednotlivé verze se dají ošéfovat, aby jich tam nebylo moc, nebo moc staré apod. Taky prostě proto, že jsem na něj nějak narazil, zkusil a ono to jede, tak co bych hledal dál. Líbí se mi také průhlednost zálohy - jsou tam prostě kopie posledních verzí vašich souborů a v jednom novém adresáři si program udržuje inkrementace, údaje o přístupových právech jednotlivých souborů apod.

Tento program má celkem hodně možností, já tady zmíním jen mé příklady použití. Pro zbytek doporučuji následující odkazy:

• anotace tady na abclinuxu.cz
• stránky projektu
• manuálové stránky
• český článek
• jiný český článek
• nějaká webová nadstavba - nepoužívám

Obnova dat může probíhat prostým kopírovaním, poněvadž v té záloze najdete přímou kopii zálohovaných dat. Pokud byste však potřebovali nějakou konkrétní verzi souboru, musíte už využít program.

Základní syntaxe pro tvorbu zálohy je:

rdiff-backup /zdroj/který/zálohujeme /cíl/kam/zálohujeme

Zdroje zálohování se dají omezovat či rozšiřovat pomocí parametrů --exclude a --include. Tvorba vzorců pro zálohované soubory je popsána v manuálových stránkách, ale mě se to zdálo pro mé účely zbytečné - zálohuji prostě celý adresář /home/, ze kterého jsem z kapacitních důvodů jen vyloučil podadresář /home/data/Filmy/, /home/kubik/.VirtualBox/ a /home/lost+found/. Myslím, že pomocí parametru --include se dá z vyloučeného adresáře zase nějaký podadresář začlenit zpátky.

Zdroj nebo cíl (možná i oboje) může ležet na vzdáleném stroji, pak jeho adresování vypadá trochu jinak, například: root@192.168.2.56::/home/zaloha/. Toto by sypalo soubory na počítač s IP adresou 192.168.2.56, na něm do adresáře /home/zaloha/ a ke komunikaci by bylo použito ssh s přihlášením pod uživatelským jménem root (o heslo si to řekne). To ssh z toho nijak nevyplývá, ale je to výchozí chování programu, které se dá nějak nastavit, asi parametrem --remote-schema.

Ještě jsem přidal parametr --terminal-verbosity s hodnotou 5, který zajistí, výpis zpracovávaných souborů na standardní výstup - standardně se nevypisuje nic, kdežto takhle má člověk přehled, jak daleko je celý postup.

Celý příkaz v mém případě vypadá takto:

rdiff-backup --terminal-verbosity 5 --exclude /home/data/Filmy/ --exclude /home/kubik/.VirtualBox/ --exclude /home/lost+found/ /home/ root@192.168.2.56::/home/zaloha/

Pokud by si člověk vyhrál s ssh přihlašováním bez hesla například pomocí klíčů, mělo by to jít rovněž použít ve skriptu.

Důležité upozornění: rdiff-backup údajně nezpracovává právě otevřené soubory.

Příprava stroje se zdrojem zálohování

Nic zvláštního - musíte mít nainstalovaný program rdiff-backup a doporučuji také program wakeonlan, pomocí kterého zapínám na dálku zálohovací stroj. Instalace u mě na Debianu je

apt-get install rdiff-backup wakeonlan

Samozřejmě musíte mít funkční síť a musíte mít rozmyšleno, které adresáře budete/nebudete zálohovat a kolik na to potřebujete místa na zálohovacím stroji.

Příprava starého zálohovacího stroje

Hardware

Z hardwarových zvláštností bych zmínil pouze podporu WakeOnLAN na síťovce a v BIOSu a tím pádem ATX zdroj i desku. Moje síťovka a možná i deska vyžadovaly extra propojení napájení. To se dělá třípinovým kablíkem, který jsem pochopitelně neměl. Použil jsem dva čtyřpinové kablíky, které se používají na přímé propojení CD mechaniky se zvukovkou. Dva proto, že mají sice jiné koncovky, ale na jednom konci mají ještě jednu jakoby redukci - tak jsem ji z jednoho kablíku ustřihl a dal na druhý místo té špatné koncovky. A že jsou čtyřpinové? Tak jsem prostě ty koncovky seřízl zalamovacím nožem, aby byly třípinové a pasovaly do desky a síťovky.

Tohoto laborování můžete být ušetřeni, pokud pro vás WakeOnLAN není důležité a budete si zálohovací stroj zapínat ručně, nebo máte štěstí na desku a síťovku, které podporují WakeOnLAN přímo přes sběrnici PCI. Více viz WakeOnLAN na Wikipedii. Vlastnosti své síťovky můžete dohledat také na webu, například já jsem se něco dočetl o svém Realteku 8139 - záleží na přesném označení čipu, já mám RTL8139A, který sice WakeOnLAN podporuje, ale na rozdíl od RTL8139C nikoliv přes sběrnici PCI.

Někam si napište MAC adresu té síťovky, bez ní ten počítač neprobudíte. Tu zjistíte například z výpisu příkazu /sbin/ifconfig.

Upozornění: Nezapomeňte, že pro účely WakeOnLAN a u ATX desek je počítač pořád napájen, takže jestli řešíte spotřebu, tak tohle není pro vás.

Software

Nainstaloval jsem tam svého oblíbeného Debiana (Lenny), přesněji jen základ bez grafického prostředí. Musí být funkční připojení do sítě.

Z dodatečných programů jsem instaloval jen rdiff-backup a SSH server (to abych to mohl na dálku vypínat):

apt-get install rdiff-backup ssh

Příprava ZyXEL NSA210

Základní příprava proběhla dle návodu. Vadí mi, že prvotní inicializaci musíte provádět z windowsovské stanice spuštěním nějakého programu z přiloženého CD, ačkoliv tento NAS server řídí nějaká linuxová distribuce - proč na tom CD není také třeba bash skript? Během tohoto startovacího procesu si server natáhne z internetu nějaké aktualizace, nastaví se hesla a zformátuje se vložený disk. K tomuto startovacímu procesu jsem použil instalaci MS Windows XP ve VirtualBoxu, poněvadž nic jiného nemám.

Další komunikace už může naštěstí probíhat přes libovolný prohlížeč s Javascriptem. Já jsem pouze doinstaloval podporu NFS (viz dále), což se provádí v sekci Package Manager webového rozhraní - dá se takto přiinstalovat ještě pár věcí, ale moc toho tam není. Například bych uvítal SSH, ale to chybí, nicméně se prý dá přidat nějakým bastlením pomocí bootovací flashky, která se do toho serveru připojí před jeho zapnutím, více viz informace v němčině. U toho NFS sdílení jsem nastavil read/write podporu a přístup jako public. Je potřeba si opsat přesnou cestu k tomu sdílení, bude potřeba při připojení na začátku procesu zálohování.

Na to webové rozhraní se mi moc neosvědčila má oblíbená Opera. V Iceweaselu (Firefoxu) byla práce o poznání stabilnější a asi i svižnější.

Proces zálohování

Popis rozliším podle cíle zálohování. Vše je řešeno z pohledu zálohovaného stroje, i když se občas bude pracovat vzdáleně, nicméně, pokud vám funguje WakeOnLAN, tak se není třeba od zálohovaného stroje zvedat. Výjimku tvoří případné zapnutí ZyXEL NSA210.

Zálohování na starý počítač

Nejdříve se musí probudit zálohovací stroj posláním tzv. magického paketu, o což se postará program wakeonlan:

 wakeonlan -i 192.168.2.255 00:00:b4:a7:a3:9b

Na konci je pochopitelně MAC adresa síťovky počítače, co ho budíme. Parametr -i 192.168.2.255 můžete vynechat, omezuje posílání magického paketu jen anurčitý segment sítě, což v domácnosti asi moc smysl nemá.

Teď počkejte, až se ten stroj probudí. Že se tak stalo můžete ověřit například pingem.

A nyní spustíme samotný proces zálohy příkazem:

rdiff-backup --terminal-verbosity 5 --exclude /home/data/Filmy/ --exclude /home/kubik/.VirtualBox/ --exclude /home/lost+found/ /home/ root@192.168.2.56::/home/zaloha/

Pokud nemáte rozběhanou ssh autentizaci pomocí klíčů, zeptá se vás to na heslo. Pokud je vše v pořádku, měli byste na obrazovce vidět lítat názvy právě zpracovávaných souborů.

Až je to hotové, můžete zálohovací server vypnout. Přihlaste se pomocí SSH (ssh root@192.168.2.56) a zadejte příkaz halt.

Mých zhruba 90 GB se zálohovalo několik hodin. Ani inkrementace neprobíhaly o moc rychleji, přestože se drtivá většina dat nezměnila. Takže doporučui to vždycky zapnout na noc nebo před odchodem do práce (pokud by vás hluk strojů rušil při spaní).

Zálohování na ZyXEL NSA210

Tady WakeOnLAN nefunguje nebo o něm nevím, takže se musí zapnout ručně. Počkáme, až to naběhne.

Jak jsem psal výše, SSH připojení ani instalace třeba rdiff-backup není standardně podporována, což situaci komplikuje, poněvadž rdiff-backup komunikuje se vzdáleným strojem jen když je tam nainstalovaný jeho protějšek. Naštěstí to lze obejít namountováním NFS sdílení vzdáleného stroje do nějakého lokálního adresáře:

mount -t nfs -o rw,users 192.168.2.89:/i-data/ab81bc07/nfs/zaloha-nfs /mnt/zyxel-nfs/

Nastavení -o rw,users je asi zbytečné. Poslední cesta je přípojný bod, kde pak najdete obsah NFS sdílení. Před ní je IP adresa NAS serveru následovaná absolutní cestou k NFS sdílení, kterou jste si měli opsat při jeho zakládání (můžete to udělat dodatečně z toho administračního webového rozhraní).

Teď můžete provést zálohu pomocí rdiff-backup do jakože lokálního adresáře /mnt/zyxel-nfs/, aniž by tam ten program byl nainstalovaný. Má to jen jeden zádrhel: na konci procesu zálohování se asi provádí nějaká změna přístupových práv na adresáři, kam se ta záloha provedla. Pokud je to samotný kořen NFS sdílení, tak to prostě nejde a zálohování skončí chybou. Snadná pomoc - prostě zálohování neprovedeme přímo do kořene, ale nějakého podadresáře (mám pocit, že pokud neexistuje, tak si ho rdiff-backup při prvním spuštění dokáže vytvořit sám).

V mém případě pak výsledný příkaz vypadá následovně:

rdiff-backup --terminal-verbosity 5 --exclude /home/data/Filmy/ --exclude /home/kubik/.VirtualBox/ --exclude /home/lost+found/ /home/ /mnt/zyxel-nfs/zaloha/

Pokud je vše v pořádku, měli byste na obrazovce vidět lítat názvy právě zpracovávaných souborů.

Až je to hotové, odpojte NFS sdílení a můžete vypnout zálohovací server, což se dá provést přes webové rozhraní.

       

Komentáře

[RapMan]

ani jsem to necet, ale me stacilo nainstalovat grsync, klik klik, Simulate abych si overil, ze jsem neudelal nejakou blbost, pak OK a zalohovani mam pripravene....

[Messa]

ani jsem tvůj komentář nečetl, ale grsync neumí inkrementální zálohování.

[RapMan]

Kopiruje jen nove nebo zmenene soubory.

[Jendа]

IMHO myslel inkrementální v tom smyslu, že se inkrementy zachovávají, takže se můžeš vrátit do minulosti.

[Michal Fecko]

Ak milujete navraty do zalohovanej minulosti tak jednoznacne BackInTime

[Heron]

Klasické gui nad rsync, diff, cp. Už to fakt chce pořádný FS s podporou snapshotů, cow a deduplikace.

Blog je skoro dobrý, hodil by se i na článek z praxe (jak na to). To "skoro" proto, že mi tam chybí dost podstatná věc: obnovení zálohy.

rdiff-backup je užitečný, ale v otevřeném stavu je pouze poslední záloha. Na starší zálohy je potřeba už použít příkazy (nebo ale zálohu připojit pomocí ArchFS). Ale zase je velmi úsporný (co se místa na disku týče). Já používal rsnapshot. Ten uchovával data v otevřeném stavu z každé zálohy (úspora místa se řešila pomocí hardlinků). Tam stačilo vykopírovat soubory z daného data, bez nějakých dalších příkazů. Velice praktické. Jenže problém (a dokládá to i mnoho dotazů na mailling listech FS), představují právě ty hardlinky (100mil linků pro 1mil souborů už představuje výkonnostní problém).

[kubik]

Ta obnova mi tam skutečně chybí, ale je tohlavně proto, že jsem ji zatím nepotřeboval a doufám, že co nejdéle potřebovat nebudu. Nicméně až se tak stane, tak bych text rád doplnil. Teď tam nebudu psát něco, co jsem nezkoušel, ani tam zatím nemám několik verzí souborů, na kterých bych to vyzkoušel.

[Nicky726]

IMO je potřeba mít vyřešenou a vyzkoušenou obnovu (resp. celý zálohovací proces) ještě před tím, než bude ostré použití zálohy potřeba.

[kubik]

Naprosto souhlasím, před tím jsem se vyjádřil trochu nepřesně. Obnovu dat jsem si pochopitelně zkusil, především kopírování posledních verzí. Zatím však nemám možnost provádět obnovu třeba z desítek verzí. A v takovém počtu verzí a vlastně i množství souborů přichází na přetřes spolehlivost, přehlednost a rychlost. A to bez skutečného použití asi nikdo neposoudí.

[Nicky726]

Rdiff-backup je šikovná věc, používal jsem ho na hodinové zálohování dokumentů ve skriptu přes cron.

IMO není moc dobrý nápad vzdáleně zálohovat pod rootem, spíš si vytvoř speciálního uživatele s omezenými právy.

[kubik]

S tím rootem je to určitě pravda a jsem rád, že to tu zaznělo. V té naší domácí síti to zatím neřeším. Vzhledem k době běhu je pravděpodobnost rizika pro mě přijatelná. Jako řešení pro plné nasazení by se to určitě muselo dotáhnout.

[Nicky726]

Nu dělej, jak myslíš, proč ale používat roota na něco, na co není potřeba. Nemluvě o tom, že můžeš udělat chybku ty, nebo může být v programu.

[kubik]

Asi jsi mě nahlodal.

[kavol]

shodou okolností jsem rdiff-backup nasazoval asi před třemi týdny ...

IMO není moc dobrý nápad vzdáleně zálohovat pod rootem, spíš si vytvoř speciálního uživatele s omezenými právy.

... na cílovém stroji jsem vytvořil uživatele "zalohator", na zálohovaných strojích jsem pod každým uživatelem vytvořil ssh klíče (pokud neměli), dal veřejné zálohátorovi do authorized_keys, a každému zálohovanému uživateli vytvořil zálohovací cronjob

bezpečnostní chybkou tohoto řešení je, že kterýkoliv zálohovaný uživatel může vidět (a modifikovat) všechny zálohy, ale dokud mám ty účty pod palcem, tak mě to netrápí - jinak by to samozřejmě chtělo zvláštního zálohovacího uživatele pro každý zálohovaný účet

[Non_E]

Na něco podobného se chystám také. Budu muset ale vyřešit ještě jednoduché obnovy, mazání starých záloh (ideálně pro různé soubory volitelně) a fungování s windows.

[kubik]

Obnova posledních verzí souborů je prosté kopírování z identické adresářové struktury.

Na mazání starých verzí je tam spousta parametrů, viz ty odkazy. Myslím, že lze odmazávat nejen podle data, ale i podle počtu verzí. Selekce na vybraný adresář je tam taky. Ty seznamy adresářů lze mít v externím souboru.

V mém případě je většina souborů fotky a muzika, které prostě žádné verze nebudou mít. A jak budou narůstat inkrementace zbývajících souborů ukáže až čas.

Verze pro Windows existuje, mě však zatím moc nezajímá. Nicméně ocenil bych, kdyby sem někdo připsal nějaké zkušenosti.

[Nicky726]

V mém případě je většina souborů fotky a muzika, které prostě žádné verze nebudou mít.

No také jsem v to doufal, ale ono stačí opravit špatné ID3 u hudby, přidat tagy k fotkám a hned je nová verze souboru na světě. Je ale fakt, že to není kritické, jako u některých konfiguráků, které se mění každou chvilku (třeba v .kde).

[VSi]

Používám rdiff-backup taky, má některé dobré, až unikátní vlastnosti, ale i problémy.

Co se mi líbí: poslední záloha je obnovitelná prostou kopií; lze si snadno nechat vylistovat verze konkrétního souboru / adresáře, takže člověk vidí, že z 50 záloh se ten soubor změnil třeba dvakrát, a kdy; zálohuje metadata (práva, ACL, rozšířené atributy) zvlášť, takže se tyhle věci neztratí třeba při zálohování na FAT32 disk nebo něco takového.

Co je "horší": starší zálohy jsou v nějakém speciálním formátu a jsou inkrementální mezi jednotlivými zálohami, takže při obnově hodně starého stavu se musí projít všechny inkrementy - trvá to dlouho a při jednom poškozeném souboru jsou všechny starší zálohy taky nečitelné. Vytváření těch inkrementů u velkých souborů na pomalejším stroji taky může trvat dlouho, je pak lepší vypnout kompresi.

Zálohuju tím i Windows stroje - přes mount.cifs si na linuxovém serveru připojím sdílený adresář z Windows. Je dobré si na to ve Windows založit speciálního uživatele, kterému dáme ACL jen pro čtení na celou zálohovanou oblast. Záloha z Windows stroje s 10000 soubory a 2.5 GB trvá 3-5 minut. Teoreticky lze Windows zálohovat i přes ssh a nativní rdiff (ano, na Win lze pustit ssh server), ale jsou problémy s češtinou v názvech a nepřišlo mi to nějak výhodné.

Pokud zálohujete linuxový systém, kde má data víc uživatelů, stejně bude muset zálohování běžet pod rootem. Jiná možnost by byla dát speciálnímu uživateli právo čtení na zálohované soubory, ale to lze ve složitějších případech jen pomocí ACL, a stejně to není jistota (uživatel může i nechtěně ACL odebrat). Naštěstí lze s využitím ssh klíčů zajistit, že rdiff-backup sice poběží pod rootem, ale nebude moct dělat nic jiného, než číst z daného adresáře (za předpokladu, že v rdiff-backup není bug):

command="rdiff-backup --server --restrict-read-only /",from="nejakystroj",no-port-forwarding,no-
X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1 ...

Tím se dosáhne toho, že při kompromitaci zálohovacího stroje není ohrožen stroj zálohovaný. Samozřejmě útočník získá data, s tím nejde dělat nic (leda je zálohovat šifrovaná).

Nakonec dělám zálohy radši pomocí nástroje dirvish (totožná funkce s rsnapshot, ale líbí se mi víc, má dobře ošetřené i chybové stavy, kdy se během zálohování stroj vypne; pochopit konfiguraci ale nebylo vůbec snadné). Výhoda je snadná "viditelnost" všech záloh. Tam zase člověk narazí na problémy s množstvím hardlinků, jak už tu bylo zmíněno. Jen mazání jedné staré zálohy trvá desítky minut. Zálohuju 1 milion souborů, 90 GB, a smazání jedné zálohy + udělání nové je na 2 hodiny i když se skoro nic nezmění. Ale je to slabý stroj (Celeron 1.7 GHz, 256 MB RAM) a zálohuje se na obyčejný SATA disk.

Všechny tyhle zálohovací programy typu rsnapshot a rdiff vypadají hezky, ale pro větší nasazení můžou přijít problémy, na to pozor! Pak je často nejlepší volba klasický inkrementální TAR nebo něco obdobného. Skutečně by to chtělo pořádný filesystem typu ZFS, a tohle řešit na jeho úrovni.

[iki]

Pouzivam dlouhodobe na zalohovani objemu cca 100GB Disk ARchive. Umi diferencialni i inkrementalni zalohy, resp. v prikazu se urcuje, oproti cemu probiha rozdilova zaloha, takze muzete vybrat jak posledni full archiv, tak posledni inkrementalni archiv. Neni to klient-server - zalohovaci medium/server je nutne primountovat na zalohovanem stroji. Je portovany i na Windows (nutnost zadavat cesty v Cygwin formatu).

[iki]

Obnova OK ;)

[David Šmíd]

Doporučuji logovací file system nilfs2 + rsync.

Udržuje historii zápisů, FS dá se namountovat tak, jak vypadal v určitém bodě v čase (readonly). Staré logy (starší než tzv. protection period) se automaticky mažou, aby se uvolňovalo místo.

 

---

[bender]

rdiff-backup má ještě jednu výhodu - výborně se popere s různýmy souborovými systémy. Takže můžeš klidně zálohovat z ext3 na fat32 a nepřijdeš o správné názvy souborů a ani třeba o rozšířené atributy atd.

[Cohen]

Další nespornou výhodou je, že máte „zadarmo“ ošetřenou kontrolu integrity dat (i v historických snapshotech) – v rámci metadat se ukládají SHA-1 součty souborů, takže se dá ověřit, že data na záložním médiu tiše nedegradují. Dokud nebude počítání kontrolních součtů všech dat běžnou funkcí filesystémů (jako to dělá Btrfs či ZFS), tak je to k nezaplacení.

Tichá degradace dat totiž dle mého bude v budoucnu asi docela závažný problém a je dobře, že nadcházející filesystémy už to řeší. Zajistit bezchybnost dat na 2/4/8... TB disku je totiž podstatně obtížnější úkol, než zajisti bezchybnost dat na 40 GB disku, i když disky sami mají nejrůznější mechanismy pro kontrolu předávaných dat.