Root disk duplication

[sbrews]

Other than doing a mksysb and restoring it to a DR system, is there any other tried and proven process for keeping the rootvg sync'ed on a DR box? Something that could be automated - or automated as much as possible?

The powers that be at my current place of employment are looking for a different solution than the usual mksysb process. Other than the above, I have no ideas on how this might be done. Any ideas/pointers will be appreciated.






Add a little color to your PUTTY terminal: faq52-6627

 

[khalidaaa]

well, i can say that you can use NIM for your mksysbs or TSM or even mirroring your rootvg. Another way is to have an identical standby machine that you can utilize on crisis.

But at the end of the day, you will have to backup your system to provide a last resort to system crashes!

Regards,
Khalid

 

[khalidaaa]

you can use alt_disk_install as well!

or use this:

Multiple instances of AIX on a single root volume group (multibos)

This feature allows the user to create a new instance of the AIX Base Operating System (BOS) within the running rootvg. This new instance, based on the running rootvg, contains private and shared data. A similar offering already available is Alternate Disk Installation. While somewhat similar, multibos varies in a few very important aspects: 

The new instance is built from the running root volume group (similar to the alt_disk_install clone operation). 
The new instance is housed within the current root volume group (for example, the same disks). 
Certain data within the rootvg might be shared between the instances. 

In the 5300-05 Technology Level, released in August 2006, this feature has been made more robust and user-friendly. Enhancements have been made in the area of setup, customize, and verify operations through script controls. Improvements have been made to secure hard links and filesystem stub permissions.

All of the above won't eliminate the mksysb!!

http://www.ibm.com/developerworks/aix/library/au-aix5l-lvm.html

Regards,
Khalid

 

[ogniemi]

I don't know if it was already mentioned, but you can easily copy LV from VG1 to VG2 using cplv command (of course it is better on unmounted filesystem).

To Copy to a New Logical Volume
cplv [ -v VolumeGroup ] [ -y NewLogicalVolume | -Y Prefix ] SourceLogicalVolume

when you copy the LV to new VG is will be exactly the same data and using chfs command you can switch you original fs to new LV (and of course to new jfslog on new VG)

it will probably not work if you have some raw devices where LVCB is owerwritten....I didn't try it...

Moving a JFS/JFS2 File System to a New Volume Group:

http://www-1.ibm.com/support/docview.wss?uid=isg3T1000167

 

[DukeSSD]

Other than doing a mksysb and restoring it to a DR system, is there any other tried and proven process for keeping the rootvg sync'ed on a DR box? Something that could be automated - or automated as much as possible?"

Isn't that what HACMP does?

http://www-03.ibm.com/systems/p/software/hacmp/

or google for:
site:ibm.com hacmp

HTH

 

[spamly]

I have to agree with the alternate disk install procedure. You can clone your rootvg to a standby disk and use this disk as a backup. I use something like this when I'm applying patches so I always have a disk that I can quickly boot off of if my patches uncover hidden "features". Yes, I have used it and it works. I don't see why you couldn't extend the functionality and move it to a secondary server and boot off of it, if necessary.

As for HACMP, I think that is a good way to go to have a true failover server for your application. There are a couple of gotchas. An application or resource group is typically a collection of logical resources: an IP address, start/stop scripts, and a volume group (typically SAN connected). The rootvg isn't "cloned". Instead, the resources associated with an application are migrated to a secondary server. There are a lot of ways to set this up and it is not free. I encourage you to check out DukeSSD's links.