PDA

View Full Version : Corrupt splitted tar archive on DVD media



fedusr
27th November 2007, 12:39 PM
I upgraded from fedora 7 to fedora 8. I started backing up the entire »/home« directory using Red Hat Magazine's Tips and Tricks: 'Splitting tar archives on the fly', because I use 4.7GB DVD+R medias and my »/home« size is over 5.5 GB.

Following the tip above:

»tar -czf /dev/stdout /home | split -d -b 4000 m - backupPART«

It produced two files: »backupPART00« and »backupPART01«.

I burned each on a DVD+R using Gnome's 'Burn folder mechanism'.

Then I upgraded to fedora 8 and tried to unsplit (»cat«) and to extract the tar archive file.

»cat backupPART* >> /dev/stdout | tar -xzf /dev/stdin«


But, I get an error:

»gzip: stdin: not in gzip format
tar: Child died with signal 13
...«

The (first) splited »backupPART01« files seems to be corrupt.

I don't know, what's going wrong. Tar creating, splitting, burning to DVD+R?

Do you know any 'recovering' tools for corrupt TAR files? May be, I can recover at least a few Gigabytes of my 'the one and only' backup.

Thank you.

HaydnH
27th November 2007, 03:00 PM
Have you got a link to the article - or was it paper based only?

I'm not going to be able to provide any advice on a fix until I've played around with the commands (I'll look in a few minutes). But for future reference, here's a few tips that would be useful to remember:

1) When ever backing up to media, CHECK & RECHECK the data is ok before removing the original data (e.g: tar -t)

2) If you had /home on it's own partition you would have been able to do a clean install without formatting /home so it would have still been there and usable. This could be worth considering while you have a fresh install!

Will have a look at the commands after a cig.

HaydnH
27th November 2007, 03:23 PM
Will have a look at the commands after a cig.


Somethings blown up at work so will have to look later if nobody has looked in to this first... sorry for the delay...

fedusr
27th November 2007, 04:02 PM
Article's URL is: http://www.redhatmagazine.com/2007/10/24/tips-from-an-rhce-splitting-tar-archives-on-the-fly/

1) Yes, guilty. I did not check either the tar file nor the splited files. But, how can i check a tar file. »tar -t « lists 'only' the contents entry of a tar file and doesn't check the 'data' or compression, i think. However, i can untar and do compare (if there are enough disk space/quota). 'Split' has also no (direct) check option.

2) Yes, guilty again. I re-partioned the entire disk due to wipe out WinXP (dual boot). But I should keeped the home partion - mindless:-(

---

Is untaring an zipped archive the same as unzpping an zipped tar-file and then untaring it?

-> «tar -czf data.tar.gz data»
-> »tar -xzf data.tar.gz« equal to »gunzp data.tgz && tar -xf data.tar« ??

HaydnH
27th November 2007, 04:42 PM
»tar -t « lists 'only' the contents entry of a tar file and doesn't check the 'data' or compression


You're correct, tar -t will only work on the tar. As you have a split, gzipped & tar'ed file you'd probably have to use gzcat along with tar -t, the split is just an ascii split so redirecting the files should be fine to check still. I don't have the time to check the actual command atm.



Is untaring an zipped archive the same as unzpping an zipped tar-file and then untaring it?

-> «tar -czf data.tar.gz data»
-> »tar -xzf data.tar.gz« equal to »gunzp data.tgz && tar -xf data.tar« ??


Yes, tar xfz is the same and gunzip file.tgz followed by tar xf.


I might not be able to check the original question til the morning...

eberta
28th November 2007, 12:21 AM
My guess looking at your command line is the /dev/stdout stuff messed you up. It is very unsafe to do:
tar -czf /dev/stdout /home | split -d -b 40000 - backupPART

What if tar outputed an error message or warning? It would also go to stdout and mess up the binary bits.

You can try:
tar -vztf backupPART00
to see if it tells you anything.
Other than that all you can do is manually hack backupPART00.
Open it up in emacs binary mode or simply vi it to look for hints.
Since gzip looks at I think just a first few bytes to determine if the file is a gzip file, that means the problem is at the top of the file.
You might find a warning like:
"tar: Removing leading `/' from member names"
Just remove "tar: Removing leading `/' from member names" and you might get lucky assuming nothing else got written to stdout that messed up tar or the compression.

HaydnH
28th November 2007, 02:09 PM
OK - finally had a chance to look. I've done a bit of testing with my system by doing the following:



[haydn@localhost test]$ dd if=/dev/urandom of=./bigfile.txt bs=1024k count=55+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 1.5257 s, 3.4 MB/s
[haydn@localhost test]$ tar -czf /dev/stdout ./bigfile.txt |split -d -b 3m - part
[haydn@localhost test]$ rm -f bigfile.txt
[haydn@localhost test]$ ls -lh
total 5.1M
-rw-rw-r-- 1 haydn haydn 3.0M 2007-11-28 13:07 part00
-rw-rw-r-- 1 haydn haydn 2.1M 2007-11-28 13:07 part01
[haydn@localhost test]$ cat part* >> /dev/stdout | tar -xzf /dev/stdin
[haydn@localhost test]$ ls -lh
total 11M
-rw-rw-r-- 1 haydn haydn 5.0M 2007-11-28 13:07 bigfile.txt
-rw-rw-r-- 1 haydn haydn 3.0M 2007-11-28 13:07 part00
-rw-rw-r-- 1 haydn haydn 2.1M 2007-11-28 13:07 part01
[haydn@localhost test]$ file part00
part00: gzip compressed data, from Unix, last modified: Wed Nov 28 13:07:50 2007
[haydn@localhost test]$


So we know the commands work, what happens when you run "file backupPART00"?