Hidden within the jumble of a mixed platform datacenter is a secret. All those virtual resources can actually be used for more than simply virtual machine recovery. One wonderful thing about virtualization is that virtual machines can be used to run many different types of workloads. This flexibility can, and should be applied to disaster recovery. Why not create a virtual recovery platform that can offer protection for all your workloads including physical, virtual, Windows, and Linux.
Virtual recovery plans can simplify and in some cases eliminate a lot of the platform specific headaches of recovering from a disaster.

The typical process to recovery a physical server could be:
1. Find or buy equivalent or compatible physical server
2. Install operating system
3. Install patches and updates
4. Install applicable application
5. Install patches and updates
6. Upload backup data
7. Pray
8. Pray some more to a god of a different denomination, just in case

Using virtual recovery almost all those steps can be made a thing of the past.
The process to recover a physical server can be as simple as:
1. Power on virtual equivalent
2. Be thankful you no longer have to deal with physical servers any more

A far more elegant approach to disaster recovery and ultimately can save a great deal of time as well.

I explore the challenges of designing an effective disaster recovery plan for the modern multi-platform data center in a webcast next month:The Changing Face of Disaster Recovery – Update Your Disaster Recovery Plans with Virtualization. It’s the second of a four part series on disaster recovery.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • FlyingGuy says:

    A more realistic list when recovering from a VS SNAFU

    1. Pray that they still have an image for the particular VM you were using ( as an example a base EC2 image from Amazon ).
    2. Pray that even if they do that their TOS has not changed and they no longer support that image.
    3. Start up a new VM
    3a. Install all system modifications you had to make to make the cookie cutter VS work correctly and pray that their TOS has not changed and you can still do this.
    4. Install applicable application
    5. Install patches and updates
    6. Upload backup data
    7. Pray to whatever gods of software you believe in.
    8. Pray some more to a god of a different profession, just in case

    If you don’t want to own hardware that’s fine it is a perfectly reasonable position. You want to be utterly dependent on 1st, your local phone company and 2nd on your ISP and 3rd on whatever VS vendor just to be able to use your application that is also a position you can take if you think the risk/benefit analysis is ok.

    But PLEASE Jason don’t blow sunshine about how trivial it will be to recover from a VS failure because there is nothing trivial about it. Most of the same issues will still be there if not more.

    • jasondea says:

      Hi FlyingGuy

      You are correct. Disaster Recovery is never trivial, whether in a physical world, or in a virtual world.

      There are however products on the market that can greatly streamline and simplify the recovery process however. Specifically a lot of the processes that you outline.

      PlateSpin Forge and PlateSpin Protect two of the products that I manage can help make the recovery process easier by not only creating virtual copies of whatever workloads you’re looking to protect (physical to virtual, or virtual to virtual), but during the job configuration process we will also pre-prepare all the operating system personalization attributes, such as IP, SID, etc… so that when we do initiate the boot sequence either for recovery or for testing purposes the VM will not only boot, but will be placed in to whatever network location is applicable. We maintain currentness on the VMs via scheduled block level replication also, to try to maintain as up to date as possible the backup VM.

      Granted there are a million other tasks you probably still have to complete to recovery fully, such as any application level dependencies, however we feel that removing “many” of the manual steps associated with traditional image based recovery can help.

      Please take a look and I’d love to hear any feedback you may have. Feedback from our users is invaluable in our own planning processes


By: jasondea
Jul 21, 2011
12:26 pm
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow