Disaster Recovery is one of the most important components to Mainframe.
While most companies have some kind of disaster recovery (DR) plan in place, a shocking number end up being ineffective in real life scenarios.
When disaster strikes – in the form of catastrophic weather events, floods or earthquakes, or even a power outage or fire at a data center – servers and storage devices may be knocked offline. Databases and websites may then become completely unavailable to potential users – and some will suffer permanent damage. There can be catastrophic economic consequences as well as headaches when this happens. A good disaster recovery plan is an important part of doing business in the digital era. What we often see at Calance is that while most company DR plans look very good on paper, when something really happens and the time comes to implement it, most of the time these plans fail. When a DR plan is being written there are components that people tend to forget about.
We’ve found that companies or clients who rely on automated processes, which have been defined in white papers or in PDF files, don’t test these in an actual disaster scenario. At Calance we understand that every client’s scenario is different. That’s why we recommend that clients keep testing solutions in the real time environment – that way a DR plan can be modified to meet the client’s specific requirements. In recent months there has been a trend away from traditional DR services that store copies of critical applications at a second physical location.
Because more and more companies are turning to cloud-based storage solutions anyway, cloud-based DR services that use data centers that can be located anywhere, and recovery plans that can be triggered from a laptop using a wireless Internet connection, make increasing sense. There are 3 main advantages to doing this:
At Calance, we are now using Amazon Web Services (AWS) to provide our small to medium-size clients with cost effective cloud-based DR recovery services.