I need some ideas on how I can access some lost data.
I have a tape backup using ufsdump of several disks.

The tape originally had the following file systems
usfdumped to the tape:

/
disk1
disk2
disk3

the next night..
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.

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.

I'm hoping with dd or some other utility I can still get to
the ufsdump for disk1.  I don't believe its been overwritten.
Ufsrestore and the "mt -f /dev/rmt/0n fsf 1" commands fail to 
get me to past the first dump.

System is a Solaris8 x86

Hope I've explained that ok?
thanks,

In <3bd2e015.0309211948.35d69693@posting.google.com> joedietzjr@is-s.com (Joe Dietz) writes:
>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.  the result would be that the tape would
be rewound after every dump and every dump over-writing the
ones that came before it.

>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.

ultrasparc3@hotmail.com wrote:

> In <3bd2e015.0309211948.35d69693@posting.google.com> joedietzjr@is-s.com (Joe Dietz) writes:
> 
>>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.

>>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

Joe Dietz <joedietzjr@is-s.com> wrote:
> I'm hoping with dd or some other utility I can still get to
> the ufsdump for disk1.  I don't believe its been overwritten.
> Ufsrestore and the "mt -f /dev/rmt/0n fsf 1" commands fail to 
> get me to past the first dump.

Most tape drives (8mm, DLT, ...) will refuse to return any data past the
last write.  This is a drive enforcement.  I don't know any way to
override it.

There have been some reports of users overwriting the EOT past the last
write, then powering down the drive to prevent it writing another one,
then rewinding and trying to get past it.  I've tried that method twice
(once on 8mm, once on DLT) and it didn't work for me either time.  I
don't recommend it.

If you *really* think the data is on there, and its worth something to
retrieve it, send the tape to one of the recover houses.  They can do
some remarkable things with tapes for a lot of money.  Call them first
and get a quote.

-- 
Darren Dunham                                           ddunham@taos.com
Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Thanks everyone.  I'm not sure its worth the big $s to try and get the
data from the tape.  I was just exploring to see if there were some
cool utilities I could try...I'm going to bet these revovery houses
have custom drivers and software written.  I wanted to check with the
net to see if there were any options before getting a quote.


Darren Dunham <ddunham@redwood.taos.com> wrote in message news:<G1Fbb.5325$A5.4766@newssvr27.news.prodigy.com>...
> Joe Dietz <joedietzjr@is-s.com> wrote:
> > I'm hoping with dd or some other utility I can still get to
> > the ufsdump for disk1.  I don't believe its been overwritten.
> > Ufsrestore and the "mt -f /dev/rmt/0n fsf 1" commands fail to 
> > get me to past the first dump.
> 
> Most tape drives (8mm, DLT, ...) will refuse to return any data past the
> last write.  This is a drive enforcement.  I don't know any way to
> override it.
> 
> There have been some reports of users overwriting the EOT past the last
> write, then powering down the drive to prevent it writing another one,
> then rewinding and trying to get past it.  I've tried that method twice
> (once on 8mm, once on DLT) and it didn't work for me either time.  I
> don't recommend it.
> 
> If you *really* think the data is on there, and its worth something to
> retrieve it, send the tape to one of the recover houses.  They can do
> some remarkable things with tapes for a lot of money.  Call them first
> and get a quote.