is my cpio backup to tape recoverable?

[itfellow]

Hey all, I'm going to need the advice of a guru on this one:

I had a crucial backup on tape (using a DDS-2 DAT drive) that had been made with the cpio command: "cat /list | cpio -oud -C 1024 -K 4000000 -O /dev/rStp0". We have this same backup scheduled through chron to run nightly.

Well, because I'm an idiot, I left the crucial backup tape in the drive when the last backup kicked off. I realized that this was happening about halfway into the backup job, so I ran to the server and popped the tape out of the drive, hoping to save at least one particular crucial directory before it was overwritten.

Well, today, when I try to read the tape, to see if my crucial directory survived, using "cpio -ivt -I /dev/rStp0" I get the error "cpio: I/O error on read()" about halfway through (probably about the point where I popped the tape out). The directory I need would have been just after this point.

My question is: is there any way to recover the data that was on this tape after the point at which the read error occurs?

 

[KenCunningham]

Have you tried dd from the tape? Alternatively, try an mt <device> fsf 1 to position the tape where the 'break' is (if it will do so), then try cpio and/or dd on this portion.

 

[motoslide]

I did some checking and it looks like some versions of CPIO support a -R option which is designed to search the media for the next header and process from there. It doesn't look like the SCO version supports that option.

It's a long shot, but if you could clip off the beginning of that tape using "dd", and get the remainder of the tape onto a system which supports the -R option of CPIO, then maybe life would be good.
If that's not an option, and you've got plenty of disk space, follow along...

First, you have to "guess" how much tape to read in order to get past the current over-write. You could get a ballpark figure by restoring the current front-end contents to a temporary directory, wait for the error, and see how much data was written. (I hope the tape is written with relative pathnames. Please don't over-write good contents on your hard drive!!) Then, adding some margin, you could use "dd" to position the tape beyond that point. For instance:

# mkdir /usr/tmp/junko
# cd /usr/tmp/junko
# cpio -icuvdB </dev/nrStp0
(wait for error)
# du -s /usr/tmp/junko
110400 /usr/tmp/junko

Use the resulting number (which happens to be in 512byte blocks) for your "dd" command:
# dd if=/dev/rStp0 of=/usr/tmp/clm bs=512 skip=110500

What's left in "/usr/tmp/clm" should be the rest of the tape, but it doesn't start at a header, and there is no "easy" way to strip off the remaining junk. You can, however, search for a specific filename or directory name just to see if you've got a prayer:
# strings /usr/tmp/clm|grep "filename"

Now, for the hard part:

Use "hd" to examine /usr/tmp/clm. Look for a pattern of "c7 71 00 00". Like this:

16700 6f 64 65 0a c7 71 00 00 13 00 24 81 02 00 02 00 ode..q....$.....
16710 01 00 00 00 68 3a 10 43 29 00 23 00 00 ec 76 69 ....h:.C).#...vi
16720 73 69 6f 6e 2f 70 61 74 63 68 2f 70 61 74 63 68 sion/patch/patch
16730 2d 76 66 73 2d 69 33 73 63 30 33 32 35 2d 33 2e -vfs-i3sc0325-3.
16740 31 30 2e 39 31 31 00 00 62 69 6e 2f 00 00 00 00 10.911..bin/....

In this example, my first "newfile" in /usr/tmp/clm starts at 16704(hex), which is 91908(dec). Now, I use "dd" to chip off the leading bytes:

# dd if=/usr/tmp/clm of=/usr/tmp/clm2 bs=1 skip=91908

At this point, /usr/tmp/clm2 is extractable with CPIO.

By the way, "clm" stands for "Career Limiting Move". Good Luck!

 

[motoslide]

A correction on the above. On the first "cpio" command which specified /dev/nrStp0, that command should cause the tape to stop at the error (no rewind). Then, you should be able to use the "dd if=/dev/rStp0 ..." command without the "skip=110500" modifier.

If that fails, go ahead and eject/reload the tape and try the "dd" command with the "skip=110500" modifier.

Keep in mind that 110500 is just a sample. Your number would depend upon how much tape you need to read past to get to the prior backup. You can also try to position the tape as Ken says, but I don't expect the tape would have a file marker if you just ejected it to cancel the active job.

 

[itfellow]

I appreciate the responses, guys. Here's what I got:

Since any cpio command that I run on this tape always errors out at the same spot, I ran the command "cpio -ivt -I /dev/rStp0 | du -s", figuring that it would stop at the same spot as usual. It returned a number of blocks - 4422862.

I tried running the command "dd if=/dev/rStp0 of=/restore/blah bs=512 skip=4422962" and, after a while, I get the error "dd read error during skip: I/O error (error 5)". I get a 0kb blah file. The corresponding error in the messages log is "Stp: Error on SCSI tape 0 (ha=0 bus=0 id=2 lun=0) Hardware error: Unexpected internal error". Usually at this point the tape drive goes offline (if anyone knows an easier way to bring it online again than re-powering it, I'd love to know). I also tried using a skip value of 4422062, just to see if I'd get soem data before it errored out - same result.

Does this mean my tape is so fried at that point that it causes a physical drive error? How could that be?

 

[motoslide]

I'm afraid you may be out of luck on this one. I've had better luck with the old QIC-24 tapes allowing you to get past a bad spot with a combination of "dd" and the NoRewind device. With DAT's, once they think there is something bad with the media, they will give a bad result to any additional commands without even moving tape.

Another issue you might face is the 2GB file limit. My idea was to pull in the remainder of that tape (assuming you could do so), and work with that file until CPIO liked it again. If the rest of the tape exceeds 2GB, you wouldn't be able to keep it on the filesystem as a single file. I don't think the 2GB limit would apply to your "dd skip" command, but you might do it in smaller chunks just in case some counter is hitting a binary wall.

Best of luck. Sorry about lack of new advice.

 

[KenCunningham]

If the data is so crucial, you might consider one of the commercial data recovery companies. Perhaps they could at least offer advice as to whether they might be able to dig you out of the hole. Good luck.