Restoring an ersthwhile cooked File to an existing File that's a link to a RAW Device.

[Alzhy]

Say I have an existing file that's a link:

/oradata/master_tb01.dbf -> /dev/vx/rdsk/oradg/master_tb01

And on Tape/backup I have master_tb01.dbf as a file from an earlier backup made when it was stored on cooked storage -- will my restore actually overwrite the link and restore the cooked file? Or will it obey the link and restore to the linked raw device?

Or it depends on the backup software/utility used?

[A. Clay Stephenson · Accepted solution]

You can more or less convince yourself of the right answer by creating a small raw LVOL and creating a soft link to it and then trying conventional UNIX commands such as cp or cat. I think that you are going to find that the only way you are going to be able to restore this is to restore it as a fully cooked file and then dd the cooked file to your raw device.

[Alzhy]

Thanks A. Clay, I should have gone that route...

It appears, tar, cpio, legato and netbackup DO NOT follow the link... It wipes off the link and restore the cooked file...

I guess we'll simply just have dd backups of our existing cooked files then...

[Hein van den Heuvel]

Last time I did that, albeit under Tru64, I piped the restore output into dd to the softlink pointing to the raw device.

I also have a vague memory of needing an oseek on the dd to skip the first 64kb or so, but that may have been platfor dependent.

fwiw,
Hein.

[TwoProc]

Nelson/A.Clay:

Suggestion 1:
Maybe via a named pipe instead of a link?
I'd think the following has a reasonable chance of working...

# mknod -p /oradata/master_tb01.dbf

# dd if=/oradata/master_tb01.dbf of=/dev/vx/rdsk/oradb/master_tb01 &

-> run your restore if you got your tar to a stream and sent that to the file:

# tar xvf /dev/rmt/0m "/ordata/master_tb01.dbf"

(restores to the location).


If THAT doesn't work: there's possibly another way...
-> restore the file to a stream and redirect it to the /dev/xxxdevicexxxx

-> Let's say as a bad example the file was the the only thing on the tape:

# dd if=/dev/rmt/0m | tar xvf - "/oradata/master_tb01.dbf" > /dev/vx/rdsk/oradg/master_tb01

I'd think one of the two above suggestions should work - maybe :-)

Re: "I guess we'll simply just have dd backups of our existing cooked files then..."

-> That's funny, because "way back when" the only people who did "dd" backups of data were those using raw databases, now for you, everything is backwards...

[A. Clay Stephenson]

Under HP-UX (and any flavor of UNIX) no offset is required. You dd starting from the beginning of the file.

[TwoProc]

Nelson/A.Clay:

Suggestion 1:
Maybe via a named pipe instead of a link?
I'd think the following has a reasonable chance of working...

# mknod -p /oradata/master_tb01.dbf

# dd if=/oradata/master_tb01.dbf of=/dev/vx/rdsk/oradg/master_tb01 &

-> run your restore if you got your tar to a stream and sent that to the file:

# tar xvf /dev/rmt/0m "/oradata/master_tb01.dbf"

(restores to the location).

Suggestion 2:
If THAT doesn't work: there's possibly another way...
-> restore the file to a stream and redirect it to the /dev/xxxdevicexxxx

# dd if=/dev/rmt/0m | tar xvf - "/oradata/master_tb01.dbf" > /dev/vx/rdsk/oradg/master_tb01

I'd think one of the two above suggestions should work - maybe :-)

Re: "I guess we'll simply just have dd backups of our existing cooked files then..."
-> That's funny, because "way back when" the only people who did "dd" backups of data were those using raw databases, now for you, everything is backwards...

[TwoProc]

Crud, please ignore first posting - I'm having trouble with posting today - it seems to at times return an error, and when it failed (but apparently not enough), I edited it a bit more. Please excuse the mess.