lvm breaks when restoring from backup

[Les A. Buettner]

It has been quite a while since I have used LVM so please bear with me. Not much stick-time on HPUX since 10.20

I have a customer with a system that died. Come to find out they have been doing backups using veritas. That is it.

Now they are rebuilding the system doing a basic install, then trying to restore the entire system from the veritas backup. This works fine. Everything is there, system restored.

Works fine until they reboot the system. Now all hell breaks loose. LVM loses all the the logical volumes with the exception of root and swap. Says it can not find the info on the phisical volumes. Everything is gone but those two LVs.

So the question is, how can I keep the restore from over writing the LVM info since the logical volumes exist (just probably not the same phisical layout as the original) and work just fine.

Does that make sense?

HP-UX 11.11 with two 36G disks, 11 lvols across the two disks.

Thanks in advance.

Les

[John Poff]

Hi Les,

That sounds about right. See, you did a backup of your old system and you are restoring it to a freshly installed system, so the devices probably aren't the same. Your restore puts down the LVM files that expect the physical disks to be addressed one way, and they are probably addressed differently on the box that has been reloaded.

Probably what you need to do is do the fresh install, make new volume groups, logical volumes and filesystems to match the LVM layout of the dead system, and then do your restore on just those non-root [everything but vg00] filesystems.

The easier way to do this kind of stuff is to do a system backup using Ignite-UX, and then use Ignite to put the operating system back. Then you could do the restore of the application data.

JP

[Pete Randall]

Les,

Exactly what are they specifying to be restored. It sounds like they're just restoring everything over the top of the fresh install. I would think you would want to leave all your "root lvols" (/, /stand, /var, /usr, /tmp, /opt) out of the restore and just restore /home and any data.


Pete

[Ross Zubritski · Accepted solution]

Les,

What we usually do is use an ignite image to build the os, then use veritas to restore the user files. Remember not to restore to 7 deadly files.

/etc/lvmtab
/etc/lvmconf
/etc/mnttab
Anything in /stand

Am I forgetting any?

Regards,

RZ

[Helen French]

I assume you only one VG defined in the system - /dev/vg00. If you are doing a complete recovery from your old tapes and if the layout is different from the old one, that would fail. I would do this:
1) Install OS and recreate all logical volumes with required sizes.
2) Restore from backup selectively. Do not over write any root file systems such as /, /stand, /opt, /var, /usr etc. Restore additional LVs defined on the old system. Since this contains data and doesn't overwrite the critical file systems, it won't fail.
3) If you want to take a look at old configuration files (in /etc or any other directories), restore it to a different place and reconfigure the system.
4) If you have a old recovery tape, that will do all these just safely (since you had only one vg).

[Les A. Buettner]

John,

That is pretty much it.
However, they are standardized on Veritas for backups. This is the only HP-UX box in the place. They do not want to use Ignite for the backups since this requires setting up special requirements for one system out of hundreds.
Also, there is only one VG on the system. vg00.

Pete,
This server runs their entire openview suite. It also has other monitoring and reporting Apps on it. To rebuild this system from scratch will take months as it has been in production for years and has a LOT of modifications and history. So this is not an option. We really need to rebuild this system from the backups.

Shiju,
See note to Pete.

Ross,

That is EXACTLY the info I am looking for. I suspect since it is the same box the backup came off, I should be able to not restore the LVM data and be just fine. I am going to try that out. As such, I'm gonna hold on the points for a bit until I try this.

Since the sequence to rebuild this takes a lot of time, and a retry is about half a day, can you think of any other files I should protect other than /etc/lvmtab, /etc/lvmconf, /etc/mnttab, and Anything in /stand?

[Ross Zubritski]

Exclude the following:

/etc/lvmtab
/etc/checklist
/etc/inittab
/etc/ioconfig
/etc/lvmconf
/etc/lvmpvg
/etc/mnttab
/etc/utmp
/etc/lvmrc
/dev
/stand

[Pete Randall]

Les,

I don't suppose you have enough spare disk space to restore the old filesystems elsewhere, do you - at least /etc, and /usr?

In any case, good luck,

Pete

[Les A. Buettner]

Ross,

Thanks a million. That did the trick. I now have a couple small problems. But they can be easily tracked down and fixed.

Pete,

Interesting idea. I have plenty of disk space for that. I put a 10 because it was a very good next step. As a matter of fact I am going to use a variation of it to help fix the last couple little things I have wrong.

To all,

Thanks for the very fast reply and thought you put in.

See ya again soon in ITRC

[Helen French]

Once you finished reconfigurinhg the system and when all working fine, make sure you create a system recovery tape. You can download the latest Ignite recovery software from HP and that will help you make your system recovery tape.

The recovery tapes are normally for backing up your system root disk (/dev/vg00) with this command:

# make_tape_recovery -I -v -x inc_entire=vg00 -a /dev/rmt/tape_dev_name

This way, incase of a failure you can rebuild your system to the old state without worrying about all these manual processes. Update your recovery tape each time you change your system/kernel settings.

Just thought of adding this ...

[A. Clay Stephenson]

Hi Les:

I've got to tell you that this scheme is fraught with peril. There are very good reasons why even if you exclude the files alist you could still be in trouble. As an example, let's suppose that your customer for some reason installs an additional SCSI controller; it's possible that when a new OS is loaded the controllers will be "discovered" in a new order so that what was once c1 is now c2. You then restore using your backup media and now all your device nodes are wrong.

I would think that one of your responsibilities to your customer is to point out better ways to do things. In your case, a much better configuration would be 2 smaller disks (mirrored) for vg00 just for the OS and then additional disks (also mirrored or arrayed) for the applications. You would then have a virtually bullet-proof
box and (assuming hot-plug disks) downtime for disk failures and replacements would be zero.

The best backup is the one you never need.

[Les A. Buettner]

Shiju,

That is exactly what I am recommending this customer create. They have to have a way to return / to it's original upright possition before restoring from backups. They will be generating this tape next week after we get this mess cleaned up.

Thanks


Clay,

In part, see above. As for the mirroring, that is exactly what I recommended. They are looking at quotes I got them for both a h/w and s/w solution. They wanted both. My recommendation is the H/W solution for obvious reasons.

Thanks also.

Les