Need to Recover lvol from disk w/out tape backup

[shirtcollar]

On an HP-UX 10.20 system SAM was used to remove a logical volume. The associated subdirectory was subsequently removed. This data needs to be restored. Backup tapes of no data are available.

The machine shows a grouping of free PEs (1619 through 1668) that total 200Mb, the specific size previously allocated to the deleted data. Our hope is that this is the data we wish to recover. We may know the physical address of logical volume to have been c1t2d0 before removal, but let's presume we don't.

The lost "lvol23" was recreated with SAM and made 50Mb larger than the initial 200Mb "lvol23" and the directory "/oboe" was recreated, in hopes of performing a restore. The backup tapes were then discovered to be useless. Don't ask.

With only this much information can one recover the filesystem tree either by using the PE numbers referenced, the physical address, or by any other method? Can the data be recovered if the physical location is unknown?

 

[Guest_imported]

I presume then that you have not quite finished it off.

I suppose once you have created the new logical volume from the old and you are using the same PE's, you could then run fsck, File System Check, before mounting it to try and get it to fix all of your inode mapping stuff.

I would check the man pages to find something suitable for yourselves (remember the special file is a raw device not character).

I would be very interested to see hear how you go this to work if you manage it.

I take no responisibility for this information, playing with data is a dangerous affair.

Best of luck

 

[skyl1nev6]

Hey,



Run an lvcreate -L 200, specify the size. Do not do any formatting while you creating this!!! Then do your fsck and as long as the extents haven't changed the data should be there..... Matt
Sr. Systems Administrator

 

[shirtcollar]

Friends: I'm embarassed at my inability to take the ball and run. I've no previous lvdisplay output, only a space report and the PE numbers I believe are of import. My creativity drains as I attempt to ensure that I am using the correct PEs. I don't think I went so far as to create a new file system. The lvcreate gets me the filesystems back, but they are devoid of files. When fsck is run against lvol23 it reports no problems. When I run it against the unmounted filesystem /oboe,(lvol23) I get an error at Block 8. I can't determine how to use lvcreate or any other cmd to incorporate the specific PEs I want. inode mapping is where my focus is today. Thanks to everyone. This forum is amazing.

Terry

 

[Guest_imported]

Here is my experience with something similiar, for what it is worth. It happened under HP-UX 9.07 on an 800 series box with LVM, as I recall.

We had a disk fail, and although it was well backed up to tape, it took a couple of days to get a replacement disk (different manufacturer). In the heat of trying to get it on-line so that I could do the restores, due to the tremendous management bullying to get up again ASAP, I ended up using the "force" option with LVM -- basically forcing the disk to be accepted into LVM in lieu of the previous one. I restored from the backups onto the new disk, and everything worked great.

That is, until the next re-boot, which fortunately was during off hours (so the management heat was not so intense). Suddenly, the disk was a big problem again, and working with HP hot-line support, I was able to the disk accepted, but everything that had been on it was "lost". I fully expected to have to bite the bullet and once again restore from tapes!

But, I went ahead and did the following, using SAM, which is how the previous disk had been implemented: I carefully went through my documentation on how the disk had been created via SAM, and essentially re-did all the logical volume partitions, identical to what had been there before. Sure enough, at the end, everything was back to normal -- the file systems within those logical partitions were never really lost, everything was there and intact, though one mis-step in the re-do process would have resulted in big problems.

I hope this might be of some value, here....