[petem]

We are preparing for DR testing in mid 2007. Our current environment includes multiple p-series machines controlled by a single HMC. Our DR scenario includes the recovery of multiple LPARs on multiple physical machines. We regularly backup the HMC to DVD (Critical console data). We also regularly back up both VIO partitions (dual VIO’s) on all physical machines using the backupios command to DVD media. I think we have most of the "gotcha’s" worked out of both processes. NIM is also in the picture, but I think I’ve got that handled also.

The real question:

Our hot DR sight has “like” equipment, not exact hardware matching. I am aware of the need for physical likeness, (Communications, internal disks etc…) But,,, can we use the “Critical Console Data” DVD to restore our profiles to an different model HMC? Likewise, can we use the “backupios” DVD to restore our VIO’s on different hardware? Given the fact that the hardware itself is registered to the HMC, I really don’t see how this will all work. I think I know the answer, and dread the response, but it’s worth asking.

Thanks for your input.....

[power66]

Why do you want to restore your hmc to a different hw?
We have to sites with one hmc per site. The hmcs both manage all p5s in both sites. So loosing one hmc (or site) is not an big issue. Of course you have to extend the management network to both sides. ;-)

[petem]

Hello Power66,

Money! Our hot sight vendor only has different hardware available. This is a once a year test. Keep in mind, we are in the DR development process at this time. Anyone, is the origional question in this thread possible?

[steevojb]

Hi,

How many servers in total are you going to be restoring ? You need a pre DR test to test your theories and procedures without the overlooking eye of management.

It may just be simpler having a specification sent to your DR company requesting these configurations are matched prior to the exercise. You should just be concerned with restoring your NIM environment following that your NIM clients. Get them to do the leg work prior to the test. If they can't provide you with the hardware that matches, they should at least be providing running instances of AIX servers that match your specification prior to the exercise and true DR scenario.

In theory the VIO restore should work as this is a mksysb image created on a DVD with full hardware support. I have though come across instances of restoring AIX on differing hardware and having to boot from an AIX CD (same ML level) before the mksysb is booted. I haven't restored a VIO server (yet) so can't speak from experience. What i'm not sure about are your virtual device mappings follow a restore and whether these will be valid. In addition, what about any client volume groups and logical volumes ? As long as you have enough disk available, you should be able to use restorevgstruct to bring these backup following the VIO server restore.

I'm also not sure about the HMC restore. The profile data will contain information pertaining to paths of I/O cards etc. If this is different there is not point in restoring this information. Depending on the number of servers you are restoring, it may be easier to install and manually add your servers.

These are certainly the things you need to highlight prior to your first test. Expectations should be set, ensuring you let your management know that there may be issues due to the inability to supply like for like hardware.

I don't think I have helped here, but hopefully introduced additional considerations

HTH

Steve

[petem]

Thanks for your input Steve,

We are restoring 3 servers with a total of 12 production lpars. I agree with you, having the vendor setup instances prior to the test. I'll be talking with them in the next month to see how this can be achieved. We've tested the restore of our VIO last week. This process worked flawlessly, with the exception of volume groups (other than rootvg). These needed to be recreated as the backupios did not include them. Understandably so..

I think for now... We are good to go. Thanks for your input.

Pete

[ross.mather]

Hi there,

First of all backing up to DVD is nice if only the local server has a problem. If the server was to be killed in some interesting way - like the roof caving in then the backup wold be gone.

I'd recommend that from another server - I usually use NIM for this:
1. mksysb for the VIOS should be written there. its also a quick way to restore the VIOs.
2. All LPAR profiles should be written there, and active LPAR definitions as well
3. All disk mappings, including LUN ids, pvids etc written away, its also useful to have the WWNs of all the SAN cards known as then in the worst case you can work with storage guys to get everything going again.

This on the basis that if the original mchine has been toasted then a lot more actions will be needed manually.

With regard to local volume groups on the VIOS, you should be able to
extract the vgdata definitions from the mksysb if its the same server.

But please, please, please make sure you have a secure offsite backup of your data just in case :-)

cheers
Ross

[alexisl]

Ross, are you saying that you can't restore from a DVD? What if you don't have a NIM server? While I agree that your approach is the best I would think that anything is better than nothing when it comes to a backup.

[ross.mather]

No I'm not saying you can't restore from a DVD, but a Physical Disaster - fire, flood, roof falling in etc will not be recoverable from a DVD-RAM in the DVD drive of the Server that has been burnt, waterlogged or crushed.

If you don't have a nim server then any other server will do for the creation if the restore data - just preferably not one in the same rack! You can always create a nim server if needed. or burn a DVD with the new image should it be needed.

And yes something is better than nothing, to that I will agree, however backups are not made just for disks being corrupt.

As with all these things it depends on te size of your server park. You take different preventative measures depending on the size of the park, allowable downtime, criticality of servers and so on.

cheers
Ross