Názory k článku
Šifrované inkrementální zálohy s Duplicity

Duplicity jsem kdysi pouzival, ale vadilo mi to, ze kdyz jsem provadel zalohu na vice destinaci, tak to pro kazdou destinaci vytvarelo novou zalohu, misto toho, aby to vytvorilo jedu zlohu a tu pak zkopirovalo na vice destinaci. Zmenilo se na tomto chovani uz neco?

K zalohovani na uloziste, ktera nejsou "pod mou kontrolou" pouzivam ecryptfs + rsync.

rdiff-backup:
- ma nahlaseno nekolik bugu, ale uz asi 2 roky neprobiha zadny vyvoj
- opruzuje, pokud na zalohovacim serveru je jina verze
- nesifruje

duplicity:
- odmazavani starych zaloh je problem, nedela diff do historie, jako rdiff-backup, ale smerem dopredu. takze abych mohl udrzovat inkrementalni zalohy cca 1 mesic, musim mit tak cca 4 full zalohy, coz je krome mista hlavne problem s casem, protoze pokud je potreba zalohovat stovky gigabajtu, trva full zaloha cely den

nicmene i pres hlasene bugy mi rdiff-backup funguje dobre, zalohuju na sve servery, takze sifrovani ozelim, naopak je velka vyhoda, ze je vzdy k dispozici citelna kopie produkcnich dat. jenom me strasi zastaveny vyvoj, protoze alternativu jsem zatim nenasel

Nemusí jít ani o stovky giga. Když zalohuji na Amazon S3 trvá to i dva dny.

ak som spravne pochopil princip tak sa ukladaju len komprimovane rozdiely nad zalohovanymi datami.
to znamena ze v pripade poskodenia starsej zalohy bude asi obnova dat z nosich zaloh dost problematicka alebo uplne nemozna. je mozne jednoduch a rychlo skontrolovat zalohy a overit ci niesu poskodene ?

na zalohovanie osobne pouzivam (kryptovany) zfs. po kazdej zalohe sa vytvori zfs snapshot a spusti sa zfs scrub, ktory overi integritu zalohovanych dat. data sa samozrejme synchronizuju medzi niekolkymi zfs diskami lokalne alebo po sieti. ak by sa pri kontrole integrity prislo na nekonzistenciu dat na niektorom mediu, bude vyradene/nahradene :)

Ano, ukládají se komprimované rozdíly a při poškození starší zálohy máte problém. Ale tady pomůže dobrý zálohovací plán, kdy denně děláte rozdílovou zálohu a třeba jednou týdně uděláte full backup a máte další pevný časový bod.

Ověření zálohy není problém, slouží k tomu parametr --verify.

Uprimne ja se zalohovanim take neustale bojuji a nakonec jsem skoncil na variante pouzit v nasi firemni heterogenni siti nativni zalohovanici utility (dump, backup, expd apod.) a centralni uloziste na linuxovem serveru se sifrovanymi disky poskytovane via NFS.
Pro predstavu nativnimi utilitami zalohuji UNIX servery (RHEL, CentOS, AIX, FreeBSD) i databaze (Oracle - expdp, Informix - ontape). KAzdy vikend full backup, denne level 1 backup. Data ukladam na NFS nesifrovany svazek v zalohovacim okne 20-06h, pres den 7-19h mi bezi na zalohovacim serveru komprimace nocnich zaloh a jejich ulozeni na sifrovana uloziste (lokalni velke disky cca 1,5-2,0 TB). Diky tomu si muzu udelt pred komprimaci a finalnim ulozenim i ruzne kontrolni soucty, zaznamenavani velikosti zaloh apod. + verifikaci provedenych zaloh pomoci nativnich utilit jednotlivych druhu zaloh.

Mě se líbí, jak se všichni zaklínají tím, že zálohovat se musí, ale když dojde na věc, tak se ukáže, že jeden software se už dva roky nevyvíjí a druhý software má pár chyb.

A když člověk hledá nějakou alternativu, tak nic pořádného nenajde.

To je dost smutné, ne?

Bohužel máš pravdu. Když jsem před časem hledal zálohovací řešení, narazil jsem i na projekty, kde bylo napsáno "recovery jsme neřešili". Ano, ono řešení generovalo poměrně standardní tary, se kterými šlo pracovat, ale takto si tedy zálohovací produkt nepředstavuji.

Nakonec jsem na to rezignoval, pomocí rsyncu tahám celý /, včetně všech lokálních systémů souborů (tedy ne speciální jako /dev/ a síťové) a na zálohovacím stroji používám btrfs snapshoty. Takže co záloha (brutálně rychlá, změn není tolik), to snapshot (úspora místa, ukládají se pouze změněné bloky).

Pokud si odpustíme nevýhodu spočívající v devel stavu btrfs, tak toto řešení má asi jen výhody.

Zálohovaná data jsou k disposici v otevřeném stavu, v mnoha (klidně až do maxima zálohovací kapacity) verzích zpět. A na rozdíl od rdiff-backup, duplicity apod, je možnost smazat libovolný snapshot (v podstatě libovolný soubor, ale myslím, že na zálohy by se tato nemělo sahat), de facto neexistuje žádný full a žádný increment.

Pokud k tomu časem bude i deduplikace bloků, tak je tímto způsobem možno zálohovat větší množství serverů bez nějakých přehnaných nákladů na místo.

Pro mě osobně je to asi nejlepší způsob zálohování a obnovy, co jsem kdy viděl.

Pokud potřebuju zálohy archivovat, tak to lze uložit do squashfs, který má detekci duplikátů, takže není problém tímto způsobem zaarchivovat mnoho snapshotů, výsledný squashfs je malý.

Ještě doporučím jako možnou alternativu dirvish. Co záloha, to normálně přístupný adresář (klidně to lze zpřístupnit skrz sambu - pochopitelně readonly), pokud se soubor nezměnil tak je hardlinkován s předchozí verzí, zazálohuji cokoliv, co si zpřístupním přes rsync (hint: rsync server pro Win funguje docela pěkně :-) ). Dirvish elegantně řeší i plánované mazání starých záloh. Bohužel už se taky zrovna moc nevyvíjí :-(

Ovšem z hlediska bezpečnosti je to dost nepraktické. Nechci mít na jednom zálohovacím stroji volně přístupné zálohy X důležitých serverů.

Chci mít "hloupý" zálohovací server, který sám nikam nemá přístup a kterému jednotlivé servery tlačí své zašifrované zálohy, od kterých zálohovací server nemá heslo. Chci aby jednotlivé servery nemohly mazat starší zálohy sama sebe (pro případ že jsou kompromitované a hacker chce mazat zálohy). Chci aby byl přenos dat efektivní a jednou přenesaná data se znovu nepřenášela.

Nic takového jsem zatím nenašel. Možná jsou ty požadavky hloupé a na bezpečnost už se nehraje?

Všechny tři požadavky jsou splnitelné s Duplicity. Stačí nastavit write-only přístup na uložiště a nějakým způsobem zabránit přepisování existujících souborů a je to. Trochu problém je, jak ty staré zálohy jednou odmazat, ruční sahání do uložiště duplicity asi není úplně v pořádku.

Jednoduchy zalohovaci sw Deja Dup je grafickou nadstavbou Duplicit urceny pro BFU

Docela zaujimavo vyzera toto:

https://github.com/apenwarr/bup

Interne to pouziva git, takze sa "automaticky" riesia duplicity a zda sa to byt docela rychle. Bohuzial je to zatial v zaciatkoch a neni moc vyrieseny recovery - nie ze to neslo, ale clovek musi vediet, co robi :-). Ale az to dozrie, mohla by to byt pekna alternativa k rsyncu.

Nevím, zda jsem četl dostatečně pozorně: šifruje duplicity i názvy souborů, nebo jen přidá tu příponu šifrovaného tar archivu?

Šifrovaný je celý TAR archiv, takže se není možné dostat k názvům souborů. Jinak samotné soubory se šifrovanými archivy mají tvar např:

duplicity-full.20111025T211016Z.vol1.difftar.gpg