Business requirements to consider when putting disaster recovery in the Cloud
One of the greatest benefits of using public Cloud services is the reduced need for capital expenditures. There is no need to argue for large server budgets, slog through budget negotiations, and find room in your operating budget to maintain your new servers once they are in. If ever there were a case for hard to justify expenditures it would be for disaster recovery. Why should a business invest in substantial infrastructure that might be rarely used? It would seem that using public Cloud providers as disaster recovery sites would be an ideal match: you have access to the infrastructure you need when you need it without significant capital expenditures. On the surface it looks like a good match, and it is, if you understand and plan around 5 key success factors.
Success Factor 1: Data in the Right Place at the Right Time
A disaster recovery site must have infrastructure, applications, and data in place to carry on business activities. A public Cloud provider has the infrastructure and many of the applications but it is your responsibility to bring the data. Obviously, in the event of a disaster that throws your entire data center offline, you will not have the option of uploading data to the Cloud – it needs to be there before disaster strikes.
How frequently you replicate data to the Cloud depends on your business requirements. Are you running transaction processing systems that demand real time replication so you do not lose any data in the event of a disaster? Or, are your applications more batch-oriented and depend on data that can be recreated if needed? A data mart which extracts data from an enterprise data warehouse would be an example of such an application. In the former case you will want to ensure you have a replication strategy in place that keeps data in the Cloud updated in real time while in the latter case updates at reasonable intervals, say nightly, may be sufficient. The important point is to match your replication strategy with your application requirements.
Do not overlook identity and access control data. When you are running your business in a disaster recovery site you will want the same level of authentication and authorization controls you have in your production environment. As will application data, identity and access control data should be maintained in a reasonably up to date standard at all times. This will help reduce the effort required to ensure secure controls are in place in a disaster recovery environment.
Success Factor 2: Accurate Configuration Information
In the event of a disaster you do not want to waste time debugging differences in configuration between your production environment and your disaster recovery environment. Software assets in the production environment should be clearly documented and these assets should be available in the Cloud. If your Cloud provider does not provide some component you will have to build an image with the required resource yourself.
Be sure to verify versions and patch levels are the same in the two environments. Using the same set of virtual machine images in your production and disaster recovery environments can help reduce the management overhead of keeping the environments synchronized.
Dan Sullivan is an author, systems architect, and consultant with over 20 years of IT experience with engagements in systems architecture, enterprise security, advanced analytics and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail, gas and oil production, power generation, life sciences, and education. Dan has written 16 books and numerous articles and white papers about topics ranging from data warehousing, Cloud Computing and advanced analytics to security management, collaboration, and text mining.
(Shutterstock cover image credit: Chef)