Home Virtualization A Look at Site Recovery Manager 6.0 – Part Five – Running a Test Recovery

A Look at Site Recovery Manager 6.0 – Part Five – Running a Test Recovery

by admin

If you’ve checked out the other pages in this series you’ll know that I’ve been setting up an SRM 6 lab, and following the last post on creating recovery plans, it’s now ready to test a failover.  Looking at the summary tab in ‘Site Recovery’, it shows that all the configuration tasks have been completed meaning that there is a recovery plan ready to be tested:

srm-6-configuration-tasks

Running a Test Recovery

To run a test recovery, browse to the recovery plan in ‘Site Recovery’. Here you will see an overview of the steps that will be carried out:

srm-6-test-recovery-steps

A test recovery doesn’t interrupt production workloads. A snapshot of the replicated storage will be created and mounted to hosts at the recovery site, and the virtual machines will be brought up in a different (isolated) network. To start the test recovery, click the green ‘play’ button.

A confirmation dialog box will open, detailing what will happen:

srm-6-test-rp

When you click ‘Finish’ the test recovery will start. Once complete, you should see the ‘Test Complete’ status along with a ‘Success’ next to each task, if all has gone well:

running-a-test-recovery

Checking my storage management, I can see that a new snapshot has been created, as indicated by SRM:

hp-vsa-clone-snapshot

Looking at vCenter in my recovery site, I can see my test VM has been registered and powered on:

srm-recovered-vm

Once satisfied with whatever testing has taken place, click the clean up button, to revert the environment back to it’s previous state, deleting the storage snapshot in the process.

srm-6-recovery-plan-cleanup

Again, you’ll be prompted for confirmation:

srm-6-recovery-plan-cleanup-confirmation

Once the cleanup is complete, the recovery plan will be ready for use once again:

srm-6-recovery-plans

I think the test functionality in SRM is great. The ability to ‘run’ a test plan gives a lot of confidence that the process will work in the event of DR, all whilst not affecting production workloads. That’s it for this post, next up I’ll look at carrying out an actual failover.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More