Skip to main content

If You Have a Problem, Perhaps Someone Already Solved It

Rob McNelly makes the point that if you run into an issue, in many cases the solution to your problem–or at least a solution to a problem similar to yours–is only a web search away.

sketched out chess pieces over a green background

Here's an interesting question: Suppose you make a copy of your datavg using the savevg command. Can you restore that backup to another machine with a different number and/or size of LUNs available? Or do you need to restore your system with a like for like number and size of disks?
Sometimes in a disaster recovery (DR) or cloning situation, we don't have access to the same sizes or numbers of disks that our source machines had. What to do then? Use mkvgdata and restvg.
It is useful to run the following commands before you create your (at least) weekly mksysb image:
            # lsvg -o | xargs -i mkvgdata {}
            # tar -cvf /sysadm/vgdata.tar /tmp/vgdata
Add these commands to your mksysb script, just before running the mksysb command. What this does is to run the mkvgdata command for each online volume group. This will generate output for a volume group in /tmp/vgdata. The resulting output is then tar'd and stored in the /sysadm folder or file system. This allows information regarding your volume groups, logical volumes, and file systems to be included in your mksysb image.
To recreate the volume groups, logical volumes and file systems:
Run: # tar -xvf /sysadm/vgdata.tar
Now edit /tmp/vgdata/{volume group name}/{volume group name}.data file and look for the line with "VG_SOURCE_DISK_LIST=". Change the line to have the hdisks, vpaths or hdiskpowers as needed.
Run: # restvg -r -d /tmp/vgdata/{volume group name}/{volume group name}.data
Make sure to remove file systems with the rmfs command before running restvg, or it will not run correctly. Or, you can just run it once, run the exportvg command for the same volume group, and run the restvg command again. There is also a "-s" flag for restvg that lets you shrink the file system to its minimum size needed, but depending on when the vgdata was created, you could run out of space, when restoring the contents of the file system...
This older post deals with the same concept, though the subject is using a script to automate the process with mirrored mksysb images.

The below script does the following:
1. Modifies the source_disk_data stanza to a single entry.
2. Modifies the VG_SOURCE_DISK_LIST stanza to the disk set by the -d paramater.
3. Modifies the LV_SOURCE_DISK_LIST stanza to the disk set by the -d paramater.
4. Modifies the COPIES stanza to 1.
5. Modifies the PP stanza to match the LP’s value.
The script takes two values, the resulting hdisk on the other node (In my case, hdisk0 for rootvg, and hdisk1 for datavg), and the location of the or file.
A lot of what we need to do may be new to us, but chances are it's been done before. It certainly makes things easier when you can do a quick search and find proven solutions. And frequently, even if you can't find an explanation of your specific problem, there's some tip out there that can still be readily applied to your situation.
IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →