ZIP – málem jsem přišel o data; mám rád rdiff-backup

6.11.2010 20:51 | Přečteno: 1857× | Ostatní

Tak jsem narazil na limit ZIP archivu, o kterém jsem neměl povědomí. Nebýt rdiff-backup, tak jsem přišel o data.

Při balení souborů utilitou zip vznikl archiv velký zhruba 5,6 GiB. Pokud vím, tak balení proběhlo bez chybových hlášení a zip skončil s nulovým návratovým kódem. Naštěstí jsem se druhý den ještě na archiv díval a zarazilo mne, že Krusader v jeden moment při procházení zahlásil chybu. Ani zip po sobě nedokázal archiv rozbalit – data za 4 GiB byla nečitelná, původní soubory jsem mezitím smazal.

Přiznám se, že o tomto limitu ZIP archivů na maximálně 4 GiB jsem nevěděl. Dodatečně mi kolega říkal, že ZIP archivy prý mají ještě spoustu dalších nepříjemných limitů (na délku cesty, maximální velkost jednoho souboru apod.). To by mi ani tak nevadilo, ale co mne opravdu zaráží je to, že zip soubory bez jediného varování zabalil i přes limit a nakonec se tvářil, že je vše v nejlepším pořádku. Takto by se programy opravdu chovat neměly.

Jediné štěstí bylo, že vstupní soubory mi před tím několik dní ležely na disku nekomprimované. Nad ránem mi všechny soubory zálohuje rdiff-backup, takže je stačilo obnovit ze zálohy.

Docela mne překvapuje, že je o rdiff-backup poměrně málo slyšet a spousta lidí o něm neví. Podle mého je to geniální zálohovací nástroj (takže mu tu zkusím udělat trošku reklamu ).

Ideálně by dle mého měla být záloha v podobě samostatných normální souborů, případně souborů uložených v nějakém standardním rozšířeném archivu (typu ZIP, 7ZIP, TAR apod.). Prostě tak, aby bylo možné data obnovit standardními prostředky operačního systému (cp, tar, unzip...) bez potřeby pomoci použitého zálohovacího programu (člověk nikdy neví, jestli zálohu nebude potřebovat obnovit někde úplně jinde nebo za nějaký čas nezjistí, že potřebuje obnovit starou zálohu, u které ani pořádně neví, čím byla vyrobena). Určitě bych se vyhnul různým uzavřeným řešením, která zálohují do nějakého vlastního binárního formátu. Když zálohu nepůjde obnovit, tak je člověk v háji. Navíc se dost těžko zjišťuje, jestli zálohování vůbec proběhlo korektně (a bylo zálohováno všechno, o čem si člověk myslí, že bylo) apod.

Tohle řeší rdiff-backup. Je to snadno použitelný multiplatformní nástroj (Python) a bere ohledy na specialitky různých operačních systémů, respektive jejich filesystémů (a to i když běží pod jiným typem systému; např. informace o přístupových právech zachová, i když je záloha uložena na disku se souborovým systémem FAT – metadata o zálohovaných datech jsou rdiff-backupem uložena jako součást zálohy v běžných souborech ve speciálním adresáři na záložním médiu), přes síť pracuje podobně jako rsync, tzn. přenosy jsou efektivní.

Zálohování je transparentní – poslední záloha je úplně normální kopie souborů a adresářů (obnova pomocí cp). Starší zálohy je možné získat pomocí rdiff-backupu (v případě nutnosti by to ale snad šlo nějak rozparsovat i „ručně“) – do toho speciálního adresáře s metadaty se totiž ukládají rozdíly aktuální zálohy oproti předchozí verzi, takže je možné obnovit kteroukoliv předchozí verzi zálohy (protože se ukládají jen rozdíly (případně komprimované), tak to neplýtvá místem).

rdiff-backup se navíc „zdarma“ postará i o kontrolu konzistence všech verzí zálohy, protože součástí metadata jsou SHA-1 součty všech zálohovaných souborů. Dá se tak snadno ověřit, že je záloha v pořádku a záložní médium nám tiše nedegraduje (plus se to dá použít k rychlému důkladnému porovnání zálohy s aktuálním stavem dat – celé soubory se čtou jen z primárního úložiště, ze záložního (potencionálně pomalého) média se přečtou jen kontrolní součty).

       

Komentáře

[____]

Absolutně nechápu proč ještě používat ZIP.

[Cohen]

Napadají mne hned dva – rozšířenost (tzn. nikdo – ani BFU na Windows bez nainstalovaného dodatečného software – nemá problém s rozbalením), rychlé listování obsahem archivu (to je hlavní důvod pro mne, proč místo TARu někdy používám ZIP).

[Grunt]

rychlé listování obsahem archivu (to je hlavní důvod pro mne, proč místo TARu někdy používám ZIP).

To jsem nějak nepobral. Vždyť PKZIP má Central Directory signaturu až na konci archivu, ne?

[Luk]

Možná má Cohen na mysli, že se k jednotlivým souborům dostane rychleji, protože u ZIPu je každý soubor komprimován samostatně, kdežto u TAR + něco (např. GZIP, BZIP2, LZMA...) je komprimován archiv jako celek, takže na rozdíl od ZIPu nelze přímo přistupovat k jednotlivým souborům.

[Grunt]

To též nějak nechápu. Program tar je přímo s těmi kompresními metodami slinkován, takže stačí jen zadat konkrétní kompresní metodu a jak čte program tar stream, tak ho automaticky rozbaluje a hledá si v něm vše potřebné (metadata). A díky řazení metadat je to ještě rychlejší než u toho PKZIPu a díky tomu, že bloková komprese se vztahuje na komplet celý archiv, tak může být účinnější (např. pro spousty malých podobných souborů). -z pro gzip, -j pro bzip2, -J pro xz, --lzma pro lzma. Takže např. pro *.tar.bzip2:

• tar -tvjf neco.tar.bz2 pro vylistování souborů.
• tar -xvjf neco.tar.bz2 pro rozbalení celého archivu
• tar -xvjf neco.tar.bz2 cesta/ke/konkretnimu.souboru pro vytažení konkrétního souboru bez nutnosti rozbalovat celý archiv
• …

No a různé archviční programy s tím už také počítají, takže se nikde nic nemusí celé rozbalovat. V případě GNU má obyčejný PKZIP (a nástroj Info-ZIP) jen samé nevýhody a omezení oproti zaběhlým archivům.

[Grunt]

-z pro gzip, -j pro bzip2, -J pro xz, --lzma pro lzma.

Ba co víc.

Popular tar programs like the BSD and GNU versions of tar support the command line options -z (gzip), and -j (bzip2) to automatically compress or decompress the archive file it is currently working with. GNU tar from version 1.20 onwards also supports --lzma (LZMA). 1.21 also supports lzop via --lzop, 1.22 adds support for xz via --xz or -J, and 1.23 adds support for lzip via --lzip. Both will automatically extract compressed gzip and bzip2 archives with or without these options.

Tudíž stále nechápu o čem je řeč.

[Cohen]

Mám tu GNU tar 1.21 na openSUSE 11.2. Faktem ale je, že není možné snadno projít obsahem archivu. Příklad: V Krusaderovi vstoupím od ZIP archivu jako do adresáře a prakticky okamžitě vidím adresářovou strukturu. Pokud to stejné zkusím udělat s komprimovaným TARem, tak to chvíli trvá (dle velikosti archivu) a je vidět, že musel dojít k dekompresi celého archivu. To stejné se děje pod Windows např. v Altap Salamander.

Nakonec ani výše popsané tar -*vjf IMHO nepracují jinak – tar stejně musí sekvenčně projít celý archiv a celý ho dekomprimovat – to že dekompresi zvládne sám a nepotřebuje k tomu externí program na tom nic nemění.

To, že komprese celého archivu místo jednotlivých souborů je účinější je samozřejmě pravda, nicméně těch pár ušetřených procent na velikosti archivu při dnešních cenách disků dle mého absolutně nevyváží nepohodlí při práci s takto komprimovaným archivem.

Velká škoda, že 7-Zip nepodporuje unixové speciální soubory (linky apod.).

[chrono]

... to že dekompresi zvládne sám a nepotřebuje k tomu externí program na tom nic nemění ...

Tar potrebuje externé programy (len ich vie použiť automaticky).

[Grunt]

Knihovny, ne programy. A to je sakra rozdíl.

[chrono]

Myslíš? Skús napr. vymazať/premenovať gzip a použi tar na rozbalenie .tar.gz archívu (prípadne pozri ldd tar).

[Grunt]

Aha. No je pravda, že s náhodným přístupem to fakt není sranda. O tom, který z použitých způsobů je lepší se tu můžeme hádat (On také nikdo nebrání udělat si *.gz.tar archiv).

[Filip Jirsák]

Rozdíl je v tom, že ZIP má všechna metadata na jednom místě. Takže se přečtou metadata, a hned víte, co je uvnitř. Tar má ale metadata u každého souboru, takže abyste z komprimovaného taru dostal seznam souborů, musí se nejprve celý dekomprimovat.

[R]

Viem, ze blby nie si, tak sa nehraj na debila. Schvalne si zober nejaky 500MB .zip a 500MB .tar.gz a porovnaj si cas trvania "unzip -l test.zip" s "tar tf test.tar.gz". Ze je zoznam suborov na konci archivu, to neznamena nic, kedze mame operaciu seek().

[Grunt]

Já jen že na nekompletní zipech se seekuje docela dost blbě (osobní zkušenost – jsem to musel dělat přes ruční hledání ZIP hlaviček, pípu, funzip a zkoušení a odhadování) a pokud nepočítám tedy tu Central Directory signaturu na konci, tak to s náhodným přístupem není o moc snazší u těch zipů.

[chrono]

zip -FF prejde nekompletný archív, nájde v nom úplné súbory, skráti ho a na koniec pridá potrebné údaje.

[____]

Ale ano, někdo problém má, na GNU/Linuxu většinou není důvod proč nějaký zip instalovat (nicméně těch pár set kilobajtů navíc pro ty ojedinělé případy neuškodí). Většina civilizovaného světa přešla na RAR a 7zip, alespoň dle mého pozorování.

[pavlix]

RAR

Asi máme jiné představy o civilizaci :).

[____]

A to by mě zrovna zajímaly důvody. Mně na něm sice vadí, že je to uzavřený formát, nicméně co se týče kompresního poměru, zvládá svoji práci na jedničku, a to není jeho jediná přednost.

[pavlix]

A to by mě zrovna zajímaly důvody. Mně na něm sice vadí, že je to uzavřený formát, nicméně co se týče kompresního poměru, zvládá svoji práci na jedničku, a to není jeho jediná přednost.

V podstatě asi hlavně praktické důsledky toho, co píšeš. Tedy, že v části prostředí, kde se pohybuju, je potřeba software pro rar nejen doinstalovat (s tím bych byl celkem smířený), ale ještě třeba není součástí oficiálních repozitářů... takže jako formát archivu na péčko fajn, ale těžko bych to doporučil na něco pracovního.

[Cohen]

Hlavně proč používat RAR? Kvůli kompresnímu poměru? 7-Zip s LZMA ho pobije. Speciální unixové soubory (linky apod.) neumí ani RAR ani 7-Zip, ale 7-Zip je open-source.

[default]

takže jako formát archivu na péčko fajn

Nejlepší formát na péčko je mov či m4v. Nemusíš nic rozbalovat ani shánět kodeky.

[Grunt]

Blbost. Na péčko nejvíc ruluje Matroška s mnohem větší kupou featur a lepším návrhem. MOV je pro lamy co si neumějí udělat v odšťavovači dobrý jablečný mošt.

BTW: Co je to ten m4v. Jsem to zahlédl u Silverlightu. To asi nebude nic Applího, když v tom má prsty i Microsoft, že?

[default]

Blbost. Na péčko nejvíc ruluje Matroška s mnohem větší kupou featur a lepším návrhem.

A k čemu ti tady v tomto případě ty features jsou? To jako že si s tím videem stáhneš i lubrikační gel či co?

BTW: Co je to ten m4v. Jsem to zahlédl u Silverlightu. To asi nebude nic Applího, když v tom má prsty i Microsoft, že?

Dovzdělej se.

[Grunt]

A k čemu ti tady v tomto případě ty features jsou? To jako že si s tím videem stáhneš i lubrikační gel či co?

Třeba na to abych vypnul ty debilní komentáře režiséra.

[default]

Nebo aby sis mohl poslechnout alternativní dubbing v Polštině, popřípadě zapnul čínský titulky. To kdyby ti ta scéna připadala nejasná, že?

[Nicky726]

Rdiff-backup je fajn, nějakou dobu používám na zálohování pro případ, kdybych si něco náhodou smazal. Jinak vzhledem k více počítačům používám rsync pro synchronizaci/zálohování, tkaže bych měl mít vždy na více strojích relativně aktuální data.

[Cohen]

BTW, Unison znáš? Na synchronizaci dat (ne jen obyčejný mirror) skvělá věc.

[Nicky726]

Neznám, díky ti.

[pic]

+ jeden geniální prográmek

a je to dokonalý - jeden pak může procházet zálohy podle data v adresářové struktuře - kždý snapshot má svůj adresář

[mimi.vx]

omezeni zipu zale6i na verzi .... puvodne byl problem i 2 giga

[otula]

Ke spokojenosti s rdiff-backup se přidávám - naprosto geniálně jednoduchý a funkční nástroj.

[the.max]

rdiff-backup pouzivam, uz mi jednou zachranil pr*el. je to fakt jednoduchej, ale ucinnej nastroj.

[chrono]

Program zip podporuje (nechce sa mi hľadať od koľkej verzie) aj rozšírenia Zip64, takže dokáže vytvárať archív, ktorý má viac ako 4GB. Je ale otázne, ktoré programy si s takým archívom poradia (ak programy tie rozšírenia nepodporujú, tak minimálne neprečítajú súbory nad tou hranicou, prípadne môžu hlásiť nekompletný archív).

[R]

Tiez som sa s tymto problemom ZIPu stretol (zdedeny zalohovaci skript). Rychle riesenie bolo nahradit ZIP za ARJ (arj a -i -m4 -va -jykv), ktory robi volume po 2GB. Vedlajsi efekt je, ze takato zaloha moze byt ulozena aj na FAT32.

Inak ten nadrozmerny ZIP sa rozbalit da, len sa s tym clovek trochu narobi. Data su toitz korektne ulozene. Problem je v tom, ze ZIP obsahuje offsety jednotlivych komprimovanych suborov a vsetko su to 32-bitove cisla, takze unzip ich nevie najst. Takze staci si ten velky ZIP rozdelit na mensie na hranici suboru (to sa najde lahko, je tam hlavicka PK) a na kazdy z nich pustit "zip -F".

[chrono]

Unzip od verzie 6.0 podporuje rozšírenia Zip64, takže s veľkými archívmi by nemal byť problém.

[Xerces]

Jak jsem si zrovna včera smazal data. Tak jsem si myslel, že se mi to nemůže stát protože jsem přeci borec Manželka dělala na PC tak jsem se přihlásil vzdáleně z Woken přes FTP a že si jako smažu adresář .wine v ~. Tak kdo to ještě nevíte tak ve .wine jsou symlinky do ~ a do ~/Dokumenty, které si wine při prvním spuštění vytvoří proaktivné samo. Prostě móresy z Woken. No a když to mažete přes FTP tak to FTPko sjede jako normální foldery No ustřelil jsem to asi v polovině. Půlka dokumentů v hajzlu. Poprvé jsem zalitoval že mám tak rychlej SSD disk

[Grunt]

$ roll-back

[Xerces]

Jo a kdo si teď říkáte, to je ale blbec to mě se stát nemůže a nemáte zálohu, tak se vykašlete na sex, spánek nebo práci a fofrem začněte zálohovat!

[misch]

Na rdiff-backupu mě mrzí jediná věc: že nedokáže pracovat se soubory které se během zálohy mění (typicky logy), a výsledkem pak je že takový soubor pro jistotu prostě vůbec nepřenese :(. A ne všude je k dispozici LVM, navíc někdy potřebuje člověk zálohu spuštět z cílového serveru (_kam_ se ukládá), nikoli z toho zdrojového odkud se čte, a pak je řešení s LVM snapshoptem totálně mimo mísu.

Tzn. rdiff-backup je parádní, taky ho na ledacos používám, ale s tímhle chováním mě nedávno opravdu nemile překvapil (přitom přes rsync samozřejmě i logy přenesu bez problémů -- tedy aspoň tu část která se neměnila).

[Cohen]

S tímhle jsem se nesetkal. Jde o soubory, do kterých se přesně v době zálohování zapisuje? Je v logu rdiff-backup nahlášeno, že soubor nezálohoval? Tzn. je v logu vidět, že se to nezálohovalo?

[pavlix]

S tímhle jsem se nesetkal. Jde o soubory, do kterých se přesně v době zálohování zapisuje? Je v logu rdiff-backup nahlášeno, že soubor nezálohoval? Tzn. je v logu vidět, že se to nezálohovalo?

Týká se to jen souborů, které se změní během práce rdiff-backupu. Ano v logu to vidět je.