tar.gz/tar.bz2 bug?

A minap mentést kellett csinálnom egy gépről. Mivel a gépen elég sok adat van (~80GB), és annyi helyem egybe nincs, ezért tar.bz2-be backupoltam le... Tegnap reggel 10-től ma hajnal 1-ig ment, lett egy ~50GB-os tar.bz2. A biztonság kedvéért ráengedtem egy 'bzip2 -t file.tar.bz2' este. Reggel megnézem, CRC error...
Korábban is csináltam már mentést ilyen tar.bz2/tar.gz-be, akkor egy kb. 35GB-os archívum lett. Akkor nem teszteltem, meg se fordult a fejemben, hogy hibás lehet, tömörítéskor semmi hibát nem dobott. Hálistennek arra a backupra nem volt szükség, utólag derult ki, hogy az is hibás, kitömörítéskor valami error, unexpected end of file stb, leállt.
Szintén nem régen egy kb. 10GB tartalomról csináltam mentést hasonlóképp, az is csak második nekifutásra sikerült neki jól.
(A mentés körülményei: valamilyen live cd-ről, illetve systemrescue cdről bootolva, ntfs-3g-vel felcsatolva ro-ként, a cél pedig samba, nfs vagy sshfs-en egy másik gép)
Egyik helyen a levelek mentésére a napi rdiff-backup mellett havi full mentés történik tar.gz-vel, a mérete ~15GB.
A ma reggelit látva felbuzdultam, nézzünk már meg egy mentés... mail-2009-05-01.tar.gz kitömörít...
gzip: stdin: unexpected end of file
tar: Váratlan EOF az archívumban
tar: Váratlan EOF az archívumban
tar: A hiba nem hozható helyre: kilépés
Itt a mentés először helyi gépre történik, majd scp-vel átmásolja egy másik gépre is. Mindkét helyen leáll ezzel a hibával.

A tar/gzip/bzip2 nem tud kezelni ekkora fájlokat? Lehet mégse olyan jó archiválásra az oldschool eszköz?

Aki szintén ezt használja mentésre, ellenőrizze, mert lehet semmit nem ér a mentés. Akinek van ötlete mitől lehet, az jelezze. Addig én asszem elkezdem nézegetni az rsync-et...

Hozzászólások

Első körben legalább 24 órán át nyomnék egy memtestet a gépen.

A tar elvileg ennél sokkal nagyobb fileok kezelésére is alkalmas, és a fejlesztőit szerencsére nem a Canonical foglalkoztatja...

Csigaa, turul16:
A kliensek, amikről a mentés készült, és leírtam a történetet, 3 teljesen különböző gép. (Sőt, a múltkor 1.1.7-es systemrescue-val csináltam, most 1.2.0-val a mentést)
A cél tény, hogy mindig ugyanaz volt.
De mail szerver illetve amire átmásolja a mentést megint két különböző gép, egyébként szerverteremben.
Mindegyik gép hibátlanul, atomstabilan megy. Mással soha nem volt még gond, soha nem halt el service, nem volt kernel panic.
--
Discover It - Have a lot of fun!

Nekem a hálózati átvitel bűzlik. Hasonló dolgot akartam pár éve csinálni, és ott is hasonló hibák jöttek elő, de ott csak csak smb-n, mivel wines környezet volt. Ha helyben létrehoztam a file-t, jó volt. Áttettem sambán, ott már nem volt jó. Feltoltam ftp-n serverre, majd onnan ftp-n le a backup tárhelyként funkcionáló gépre, és úgy meg jó volt... Ma sem értem, hogy miért. Sysrcd-ről ugyanezen a terepen ftp-re ment a gparteddel a backup, smb-n hibás volt.

Nekem csak az smb-re készítettekkel volt bajom. NFS-en nem tesztelhettem, mert wines környezet volt, a server fele meg sshfs-en nem backupoltam, mert lassabb volt, mint 2szer ftpzni :-) De most hogy mondod, gparteddel ssh-n nem ment a backup. De azt hiszem, hogy ott más baj volt, csak már nemnagyon emlékszem, az smb szívás maradt meg.

Ettől még lehet memória hiba.

Megtörtént eset: 3 GB RAM volt a serverben, nem végzett különleges feladatokat, inkább CPU terhelés volt mint memóriafoglalás, ment is szépen és stabilan, kivéve egy dolgot: a két merevlemeze közti másolás során az 500 MB-nál nagyobb fileok MINDIG hibásak lettek. Sokáig ment így, elkerülte a tulaj a "kényes" műveleteket, aztán lecserélték a gépet, szóval lehetett vele kísérletezni.
3 órás memtest után kiderült, hogy a 3000. MB környékéről hülyeségek jönnek vissza a RAMból. A programok soha nem kerültek ilyen magas memóriaterületre, csak a disk cache, így a nagy fileokon végzett műveleteken kívül semmit sem érintett a memória hiba.

Volt eleg szabad hely ? Biztos nem hibas a memoria ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

en megneznek valami mas tar/pax implementaciot (pl libarchive fele, vagy star)

--
When in doubt, use brute force.

Mindig ugyanolyan hibat csinal (==md5sum egyezik)?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!