>>The painful part is disk1 failed. The backup ran in cron
>>and the only thing on my tape is a ufsdump of disk3. Disk3
>>appears to be the first thing on the tape? The bus must of
>>had errors and aborted the /, disk1, disk2 dumps.
> it is more likely that you used the "rewind on close" tape
> devices for the dumps instead of the "no rewind on close"
> tape devices.
This is certainly possible, but I have seen situations where
a tape drive will rewind after some sort of error has occurred,
even when you use the no-rewind device.
It's been a while since I've seen it, but I believe the
scenario goes something like this:
1. write some data to the tape.
2. error occurs.
3. close tape device; device is left in error state.
4. backup script doesn't check status of tape; opens
tape device again despite error. driver or drive's
firmware responds by rewinding tape, then proceeding
as normal.
As I recall the situation, the rewinding doesn't happen
until the device is opened again, but it might be the
other way around. (The device might rewind when you close,
if there's an error.)
Also, I can't remember the type of error that causes this,
but I believe it's either a full tape or a "Media Error".
(I've seen enough of both that they sort of bleed together
in my mind...)
Anyway, the point is that my experience indicates that
sometimes it is possible to have an error cause your
tape start over at the beginning.
Quote:>>I need to get to the data on the tape for disk1 from the
>>previous nights backup. The ufsdump of disk3 should only
>>be about 30MB. A normal usfdump of "/" is serveral GBs.
> whether or not you can get the tape drive to read past
> the end-of-tape marker depends on the mechanism. software
> tools alone may not help. you will also need to know how
> large the disk2 dump is, if it is large then there may
> not be much of disk1 left on that tape.
Yes, this is going to be tricky stuff. The way that it
works is possibly going to depend on the type of tape
drive. If you "man mtio", you'll see stuff about different
types of tape drive handling end-of-file markers differently.
One possible thing to try would be a "mt eom" followed by
an "mt fsf 1". Also, this little bit from "man mtio" looks
interesting:
MTIOCREADIGNOREEOFS
enables/disable support for reading past two EOF marks
which otherwise indicate End-Of-recording-Media (EOM)
in the case of 1/2" reel tape drives
Whether that would work on various types of tape drive
is a whole other question. (Somehow I doubt the original
poster is using nine-track tapes...)
- Logan
by