make_recovery restore and vg01

[Neil Steurs]

OK, bear with me, this is a little complicated to explain.....

We have a standard VG layout on all our servers (approx 450!) which has most of the usual VG00 on the internal (root) disk, but /var/spool and /etc/opt in VG01 on EMC Symmetrix array disks (for speed, resilience, etc.).

We run make_net_recovery regularly incase of root disk failure. The problem happens when we try to restore the recovery archive.....

At first we cannot restore the archive because Ignite give an error about not having any mountpoints under /sbin or /etc (we have /etc/opt).

To get around this, we remove VG01 from system_cfg before we install the recovery archive. This means that we have to vgimport VG01 manually after Ignite has finished (as VG01 is not in control_cfg "post_config_cmds=vgimport.....")

This is kinda OK if we use the same server to restore to, but we often fail over to standby servers, and ALL the vgimport commands (post_config_cmd= in control_cfg) fail as all the device names cxtxdx will have changed. We get around THIS by vgexport'ing mapfiles in shared mode (-s) each day (on cron) on all our servers, so we can import them on the standby server with vgimport -s should we need to. (BTW - the EMC disks just get represented to the standby server).

However we have found that after the recovery archive is restored, the VGID is removed from those disk devices that were in VG01 so the -s option is no longer working. If there are more than one device in VG01, or unused disks on the server, it gets very confusing trying to figure out which devices are in VG01!!!

Does anyone know a way we can restore a recovery archive, with VG01 removed from system_cfg and WITHOUT Ignite removing the VGID from those disk devices in VG01? That way we can restore the archive and then vgimport VG01 (and other VG's) with -s afterwards and not have to loose/restore any data from tape?????

Get that...??

[Sridhar Bhaskarla]

Neil,

Export the volume groups with -f outfile option.
The outfile will contain the list of all the disks. After the recovery you would just need to replace the cX numbers if the instances get changed and then import using -f option. To be on safer side I export volume groups with all the options.

#vgexport -v -s -m /tmp/vg01.s.map vg01
#vgexport -v -m /tmp/vg01.map -f /tmp/vg01.disks vg01
Copy vg01.s.map, vg01.map and vg01.disks to a remote system.

If -s option does not work, you can import the vg using vg01.map (-m) and vg01.disks (-f) option.

-Sri

[Neil Steurs]

Sri

Thanks for the option, but its not always the case that only the cX numbers are changed so we are no better off than just guessing the device (especially when we also have unused devices attached as well).

I would like to know why the VGID is removed by Ignite in the first place.

Any ideas?

[Bernhard Mueller]

Hi,

I guess what you really want do to is have a customized mnr_essentials file which does NOT specify to archive the entire /etc (plus any filesystems mounted underneath).

Then you can archive using: -x inc_entire=vg00
and upon restore Ignite should only pvcreate the disks that belong to vg00.

Hope this is what you need....

Regards,
Bernhard

[Carlos Fernandez Riera]

A well done ignite backup will clone your system.. if ignite found exactly the same hardware configuration. SO if there are not new EMC's disks ( or new configured disks) ignite should maintain Cx for all disks/devices.


To restore the instance numbers, you must use the ioinit command. You can find many samples about ioinit and /etc/ioconfig in the forums. What i dont know is if you can specify any ioconfig with Ignite.


About to find the correct disks into the EMC I provide you a script to list all VG ID on you system ( even it not belong to it). Hope it helps you. Please check Directories needed and what it do.