ignite restore doesn't restore vg02 secondary swap ?

[paul cummings]

I just restored my 2 node 10.20 K460 SG cluster from ignite tapes and noticed after the fact that my vg02 (which is my secondary swap disks) did not get restored. I have seen this before. What's wrong with this picture?

Is this a bug? Do I have to rebuild my secondary swap disks from scratch?

[A. Clay Stephenson]

By default, Ignite only handles vg00 the other VG's are up to you.

[Michael Tully]

This will depend entirely on how your ignite tape was cut ...

We only ever include vg00 in ours, as we have a lot of data.

[paul cummings]

Hmm, but it did restore vg01 OK - which is 'sysadmin' disk of sorts. What do I need to do to include vg02? Haven't done anything to include vg01...

thanx

[Michael Tully]

What was the exact method used for the ignite tape session?

[Steven E. Protter]

Number one:

Its not that big a deal to add some secondary swap. You can do it in sam in five minutes plus a reboot.

2:

As noted, by default Ignite should have picked up all of vg00 without any special options from you. You should check your make_sys_image file for modifcations that mighte exclude secondary swap.

3:

Did you perhaps use an old Ignite backup taken after you added the swap area?

4:

Is your Ignite Version up to date? Is it possible that there is a bug that causes secondary swap to be excluded? I would not put that outside the realm of possibility.

swlist -l product | grep -i ignite

This output would help.

5:

If there were open databases in vg01, there is no way they tranferred correctly. If they were bigger than 2 GB, they were excluded.

For Ignite to get a database right, it must be a cold backup.

6:

See point 5. If the swap area was bigger than 2 GB we have our explanation. Ignite uses pax to pack up all those nasty little file critters. The standard version of pax simply skips files bigger than 2 GB. If the patch to handle files up to 8 GB even exists in the 10.20 world, it will break Ignite. pax_iux can't UNPACK files bigger than 2 GB.

Hope this was helpful.

Please consider giving Michael and I a point for our efforts.

OT: I owe mike some points. Was in a pissy mood, but his CD-ROM answer was dead on. If he posts back that thread, its worth another 5 plus 3 to give the bunny that is owed.

SEP

SEP

[paul cummings]

the command used was:

/opt/ignite/bin/make_recovery -v -A

[Jeff Schussele]

Hi Paul,

Depends on the command used:

make_tape_recovery -Ivx inc_entire=vg00 -x inc_entire=vg02 # -x inc_entire= for *every* VG you want

make_recovery => No way to backup non-vg00 VGs
best you can do is
make_recovery -Aiv
to get all vg00 & interactive restore. You'd have to make sure you exported the vg02 map & reimport it post-restore.

HTH.
Jeff

[Patrick Wallek]

Since you used 'make_recovery -A' to do create your tape and you had part of VG01 included in your tape, that leads me to believe that you have /usr in vg01. See the following excerpt from the make_recovery man page:

"When a system has a logical volume layout, the recovery tape will only include data from the root volume group, plus data from any Non-root volume group containing /usr."

So, if you /usr was in vg01, then the ENTIRE vg01 would have been included on the tape. This is by design since /usr has important things like /usr/bin and whatnot.

So your vg02 not being included is absolutely normal and to be expected. As suggest by someone above, just recreate your other swap via SAM. Also note that CREATING a new swap area does NOT require a reboot, but REMOVING a swap area does.

[Jeff Schussele]

Hey Patrick -

Real men don't use SAM.....!!
They use vgimport/vgchange/swapon ;~))

Just Teasin,
Jeff