Dotaz: zaloha tar na dvd

[Gustav]

Dobry den,

potreboval bych zacit s pravidelnym zalohovanim dulezitych dat (ted 25 GB), pro me nejlepsi reseni je asi tar a pak vypalit na dvd (pod windows, mam DVD+/-RW a neumim ji poradne rozchodit...). Pouzil bych prikaz tar -czf /nekde/file001.tar.gz --listed-incremental /var/log/zaloha /co_chci_zalohovat .

Da se nejak zaridit, aby vystupem bylo vice souboru velikosti disku DVD, 4,7GB ?

Odpovědi

[unchallenger]

Pokud jde o rozsekání, dej taru jako výstupní soubor ,-` a pošli to skrz split. Ale budeš nejspíš potřebovat podporu velkých souborů, v níž se moc neorientuji...

[Gustav]

To jsem zase prokazal neznalost :))). Dobra, kdyz to rozdelim SPLITem, spojim CATem, zapisu si md5 soucet a porovnam ho, mam tomu potom verit ?
Filesystem mam ext3, system je MKD 9.2 (ano, hluboce se za to stydim), a o zadnem problemu s velikymi soubory jsem neslysel (krome DUMPu, a ten byl pry jiz odstranen).
Je to dostatecne spolehlive na zalohu ?

[Hynek (Pichi) Vychodil]

Tak na split se můžeš spolehnout. Dokonce to můžeš spojit na widlích (copy /B).

[Stanislav Brabec]

To platí i obecně. Shodný MD5 součet dává 99,9999999999999999999999999999999999997061264123% záruku shodnosti souborů. S nejvyšší pravděpodobností tedy neexistují na Zemi dva různé soubory se stejným MD5 součtem.

[Jiří Svoboda]

Ja teda nevim, ale uvazuju takhle: md5sum je dlouhy 32 nibblu, tedy 128 bitu. Pri delce souboru 128 bitu tedy bude mit "v prumeru" kazdy soubor jednoznacny md5sum. Pokud bude vsak soubor o bajt delsi, bude uz existovat "v prumeru" 256 souboru teto delky se stejnym md5sum, atd. A se zvysujici se delkou je to horsi a horsi. Takze podle me je ta pravdepodobnost nejen vetsi nez vyse uvedena, ale dokonce to ani neni pevne cislo, protoze delka souboru muze rust do nekonecna. Budu rad, kdyz mou uvahu nekdo vyvrati nebo potvrdi. Jinak samozrejme sam md5sum povazuju za dostatecnou zaruku shodnosti . A male P.S.: Vypalovani DVD pod Linuxem je easy, premejslim, ze o tom napisu clanek.

[Michal Čihař]

No mám pocit, že zmiňovaná pravděpodobnost je pro "reálné" texty...

[Stanislav Brabec]

Máte pravdu, pro soubor délky 128 bitů (16 bajtů) dává MD5 sum 100% záruku. Pro soubor delky 17 bajtů pak existuje 256 souborů se stejným MD5 součtem. A když si vezmete počet všech možných 17bajtových souborů a porovnáte to s těmi možnými 256 chybami, dostanete výše uvedenou pravděpodobnost.

[David Jež]

zdravim,
To neni tak uplne pravda. Na zemi muze existovat opravdu hodne souboru se stejnym MD5sumem, dokonce kamarad ma na disku dokumenty (nejake skolni protokoly) jeden .doc a druhy .xls uplne ruzne a maji stejny checksum... Dale, MD5 ma zarucenou kolizi kompresni funkce, kolize se da nalezt zhruba za pul dne az den na prumerne PeCce. Neplati to tedy pro celou funkci, ale i tak. S temi procenty bych nejak prilis neprehanel :). Jinak ale obecne pokud bude sedet delka a hash, nejlepe vice algoritmu (osobne pouzivam sha1 a ripemd delky 320) tak si uz muzes byt jisty, ze soubor je OK.
-djz

[Filip Hesse]

Mám podotázku. Jak se zachází s SHA1?
1) vytvoření kontrolní "kaše" ze souboru,
2) zkontrolování původního souboru.

Předem díky.

[unchallenger]

1) 2) sha1sum --help by nepomohlo? IMHO je to tam jasně napsáno (až na to, že netuším, co je to ,kaše` ze souboru...)

[Filip Hesse]

Man jde používat pouze pokud znáš příkaz. Sha1sum je logické, ale nedošlo mi to. Díky za pošťouchnutí.

V časopise Chip 99/03 vyšel článek o samotném výpočtu. Autor přirovnává složitou matematickou funkci míchání bitů k mletí mlýnkem, kde výstupem je jakási "haše". A já si po té době vybavil pouze obrázek mlýnku na maso (ten obrázek v článku je) a vylezlo ze mně "kaše"

[unchallenger]

já jsem sha1sum neznal ;-) i když jsem předpokládal jeho existenci ;-) prostě jsem napsal apropos sha1 -- a hele, co na mě vypadlo... nebo bych zkusil napsat v shellu sha (nebo sha1) a stisknout tabelátor, jestlipak se mi něco doplní -- a hele, co by se doplnilo...

[Gustav]

Mockrat dekuju za odpovedi. Presne to jsem chtel slyset :)))
Clanek o paleni DVD si rad prectu.
BTW: Ta moje mrcha (Sony DRX510 - nebo tak nejak), je externi pres USB/Fi-Wi (v tom by nebyl problem), ale zkousel jsem v ni vypalit CD-RW, a na "generic" ovladac to spadne.
Nicmene novy k3b 1.0x ma v sobe misto patchovaneho cdrecordu dvd-r tools (nebo tak nejak, nevim jak se to pise) a na homepage projektu pisou, ze ta moje mech. je podporovana. Jenom nemam DVD-RAM / DVD-RW (podporuje oba formaty), abych to vyzkousel. (pri cene DVD se mi to "naslepo" zkouset nechce). POINT : mozna nebudu muset instalovat widle ! :)))

[Zdeněk Štěpánek]

jen detail: je to USB/FireWire WiFi je neco jineho... Muj teoreticky nazor: tar.bz zabalis adresar a potom ho rozsplitujes a ty casti vysmazis tak na obnovu budes potrebovat vsechny ty casti zase spojit dohromady a pak teprve rozbalit. nebylo by lepsi nechat nejaky balici program automaticky vytvaret 4.7GB archivy? podobne jako to umi RAR? Nevim ale jestli to nejaky linuxovy balic umi. Zdenek

[Gustav]

Tak jsem to zkusil a skonci mi to chybovou hlaskou: broken pipe (asi prerusena roura - | ?), pribyde soubor corexxxx s chybovym vystupem. Archiv konci na 2,0 GB (2 147 483 647 B). Zprvu jsem to nechapal, ale dle clanku http://abclinuxu.cz/clanky/ViewRelation?rid=11662 je limit ve fs 2,0 GB. Takze to budu muset zalohovat po jednotlivych adresarich, a budu v tom mit zmatek :(((

Proc to sem pisu: nikdo z nas (ze ja ne, neni prekvapenim), kteri jsme sem prispeli, si neuvedomil, ze tohle tema je NESMYSL hned od zacatku ...

BTW DVD uz palim.

[Gustav]

Nebo by se to dalo napsat jeste jinak - dostali jsme se zpatky na zacatek diskuze.
Reseni "udelam si 25GB (trochu mensi po komprimaci) soubor, ktery pak rozdelim, vypalim, a pri pripadne obnove slozim", nejde. Bez prechodu na jiny fs (pri kterem se ovsem durazne doporucuje zaloha...), nevim, jak se s tim vyporadat.
Ty data jsou vsechna ve strukture v jednom adresari, proto jsem ho chtel zalohovat cely najednou, abych nehledal "odkud" a "kam az" to mam zalohovat.

Tar (alespon co vim) neumi vytvorit vice souboru archivu. Da se pouzit neco jineho (pro inkrementacni zalohu, ja do te struktury neustale pridavam dalsi data)?

[unchallenger]

Mě tedy jako dlouholetého uživatele ReiserFS nenapadlo, že někdo na 25GB+ disku používá takový obstarožní filesytém... Kromě podpory ze strany filesystému je nicméně s velkou pravděpodobností zapotřebí podpora ze strany aplikace (largefile), protože jinak jsou velikosti a offsety v souborech jen 32bitové -- což jsem psal na začátku, ale bohužel nevím, jak to vypadá, protože jsem to zatím nikdy nepotřeboval.

[Michal Čihař]

To není problém filesystému, ale aplikací, limit ve fs už určitě pěkně dlouho není 2GB.

# dd if=/dev/zero of=tmp/test bs=1M count=3k
3072+0 records in
3072+0 records out
3221225472 bytes transferred in 147.578402 seconds (21827215 bytes/sec)
# ls -lh tmp/test 
-rw-r--r--    1 root     root         3.0G Dec  8 22:37 tmp/test

Je to na ext3...

[Gustav]

Jsem pitomej, protoze data mam na EXT3, ale volne misto (kam jsem se to pokousel zapsat) na vfat (FAT32). :)
Dle http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/prkc_fil_tdrn.asp (omluvte prosim odkaz na M$), je limit 4GB.
Takze chyba je zrejme v TARu.

BTW: zajimava je tahle veta:
Windows XP Professional can format FAT32 volumes up to 32 GB, but it can mount larger FAT32 volumes created by other operating systems. - ja mam 69GB partition (ale nebude mit dlouhy zivot).