SRM is a tool, not a goal

“Technically almost everything is possible.” One of the first things I will say to a customer when they ask advice about IT related stuff. This is also true with Site Recovery Manager (SRM), an excellent tool for enabling Disaster Recovery within your vSphere environment.

And the focus here is on “for enabling”. SRM is a means to an end. SRM is a tool and not a goal. It al starts with the definition what needs to be protected. Most of the times SRM is already bought and paid for, but during the implementation the question comes up : “What do we need to protect?”.

This is the other way around. It the same as building a house, but you don’t know how many people need to live in it. It must start with a definition what needs to be protected. What do you want to be failed over in case of disaster. In what time do you want this to happen? And how much data loss do you consider acceptable?

These are just a few questions that need to be answered before building your Disaster Recovery solution. Thankfully VMware has created a book on this topic with the title “A Practical Guide To Business Continuity & Disaster Recovery”.

The picture above is from this book and defines the process that needs to be followed when implementing a DR solution. In companies where IT processes have been defined, for example by using ITIL, “Business Process” most of the times is already there. You can find the answers to you questions in Service Level Agreements (SLA) or other documents that define the agreements between the business and the IT department with regards to application requirements.

Next is to define the applications that need to be protected by your DR solution. And especially insight needs to be created in the application chain. Most applications are depended on other applications for doing their job. So in case of a disaster it would be nice to have the complete application chain, in stead of just the web frontend. Products like VMware Infrastructure Navigator are nice tools to show these applications dependencies and to give you an overview of your applications chains.

After gathering this information the implementation of SRM is pretty straight forward. You can easily define your recovery plans and make sure that all virtual machines that need to be protected are identified and replicated to the recovery site.

Think first, build later… That’s what it all comes down to with SRM!