P2V as a DR strategy

[Greg_Garvin]

I want to test some DR scenarios….

Our development servers are both physical boxes…testonbas01 and testonbas02.

We’re going to virtualize both of them eventually…but for  now I want to test a P2V DR scenario.

• P2V testonbas01 which is the app, db, web and DDS server…have that virtual copy on standby.
• Shut down the physical devonbas01 to mimic an actual hardware failure and activate the VM copy of devonbas01.

 Now if the VM copy is a few days (or a few weeks) out of date what are our implications?...db out of current, system files not current…can we do a restore from a point in time to bring it current?

The long term goal here is to develop a viable DR plan for the prod OnBase app server (prodonbas01 which is physical)…I was hoping we could P2V that box monthly…have that copy on standby and in the event of a physical hardware failure plug in the VM….we do this scheme with a few other physical server I’m wondering…is it viable in the OnBase world?

In prod the db is on another SQL 2008 server…in Dev the db is all on one box…

any insight is appreciated

[Jon_Squires]

Hi Greg,

P2Ving your server may generate a few new concerns that performing a backup will not. 

You will want to make sure to stop the databases before performing the P2V.  Performing the transfer while the database is live can result in data inconsistency.  There is a TechNet blog post about P2Ving transactional databases (a domain controller) here : http://blogs.technet.com/b/jonjor/archive/2010/11/10/p2v-of-domain-controllers-online-or-offline.asp...

You may run into some issues with the machine password changing.  What can occur is you take the P2V of the physical machine, the physical machine then changes it's machine password, then you bring up the VM with an incorrect machine password. You may get an error about a trust relationship failing.  This can be resolved by resetting the machine password or rejoining the machine to the domain.  Alternatively you can turn off the machine password change by following these instructions: http://support.microsoft.com/kb/154501

Apart from these issues, you will be reverting your disk groups and database to the point in time of the P2V.  In Stage, this may not be a critical issue.  In Production, i would assume that the disk groups will not be on the Web & Application server, and you have stated the DB is not on this box, which means this will be a non-issue.

[Greg_Garvin]

Thanks Jon...

I will take your 'gotchas' into consideration..

Do you consider this a valid OnBase DR Strategy?  Are you aware of other OnBase Sys Admins who use this scheme?

Greg Garvin

[Jon_Squires]

 This will certainly create a viable DR strategy. I have not heard of any systems that have setup a process like this for DR.  There have been cases that i am aware of where they have used P2V as part of a migration to a virtual environment, but not as DR. 

This would essentially become a repeatable migration to a virtual environment.

[Gregory_Roche2]

Thanks for the post, good information as we start to look at this as well.