Failback: A key to disaster recovery
What is the most important method to recover from a failover?
While there are many aspects of a quality business continuity plan, let's focus on failback. Failback is the term for moving your IT environment back to primary production after a disaster. It's essential to know your failback options, because failover is not a permanent state. Here are a few issues to consider:
First, your company likely has to adhere to compliance regulations, so take these into account when designing your failover site. PCI DSS, for example, no longer allows a customer to run applications in a disaster recovery environment that doesn't have an identical level of security as the normal infrastructure. You may need to add security measures to the DR site (like file integrity scanning and security event long management) in order to resume processing cardholder data.
The next issue is the application stack. Many software products, such as Microsoft's SQL Server, have licensing limits to address prior to running production workloads for an extended time.
The third issue is capacity. Suppose your IT business continuity plan was designed to operate at 20% of your production capacity. The longer you remain in your failover site, the greater the chance that you will run up against your resource limit.
Finally, there are limitations if you leverage a third-party company to assist in your data backup and recovery plan. Most restrict how long you can occupy the space they provide before you must either transition your environment back to its original site, or convert your contract with the vendor to make the site permanent.
In addition, consider:
- The time needed to acquire replacement hardware
- The method used to failover to your disaster recovery (DR) site ( typically be the same process followed to failback)
- Costs (hardware, software, facility, failover declaration fees and fees) associated with turning your DR site to a permanent site
- Your recovery time objective, or how long the failback method will take ‑ this can sometimes be more painful than the actual failover event
Failover site selection and failback capability
Your choice of a failover site will also affect the capabilities of your failback, whether it entails restoring existing infrastructure, buying new infrastructure or moving to a production cloud.
Using colocation services, with failback to existing infrastructure, is relatively inexpensive, but it can be labor- and time-intensive. Restoring large amounts of data (more than five or 10 terabytes) can take days when restoring it from tape.
This strategy becomes less effective when new infrastructure is required. Capital expenditure costs run high, as do labor costs. Buying and configuring new hardware while simultaneously restoring five to 10 terabytes of data, all within a tight recovery window, is going to be a serious challenge.
A public cloud service offers an easy option for storing data during a DR event. With low front-end costs, it's great for small businesses with limited IT staff or that lack in-house data-protection services.
But if you're a mid-sized company facing a disaster, prepare yourself. Back-end costs can run very high here. Retrieving data is expensive, given the scope and scale of what you likely have stored there. You will pay for every gigabyte you take out.
With a Disaster Recovery as a Service solution, you failover to a predesignated DR cloud. Failover is smooth, because your DRaaS provider helped design the solution and tested it to ensure any issues were worked out.
DRaaS solutions typically leverage continuous data protection technologies that offer low levels of data loss by replicating production data. Mission-critical production can operate throughout the recovery period, as server security configurations and network services are duplicated at the DR site.
The failback options for DRaaS are the same as for colocation and public cloud services: restoring existing infrastructure, buying new infrastructure, or moving to a production cloud. In any of these cases, the labor involved for failback falls on the service provider, saving you time when you need it most.
The failback event itself is simpler too. It requires only three steps:
- Recover your infrastructure (or keep production in the cloud)
- Reload your hypervisor
- Install one virtual machine
From here, your DRaaS provider can take over the replication and eventual failback into your production environment.
Additional benefits include:
- Minimized downtime, protecting your company from financial losses
- Lessened risk of compliance penalties
- Stronger security against breaches. Oftentimes, a company's DR site holds all its data, but without the security in place to protect it, the DR servers are often neglected and lack critical security patches. With a DRaaS solution, the DR VMs stay in sync ‑ typically in a powered-off state, so the data is not even accessible until the time of declaration
However, not all disaster recovery companies are created equal. Some have production capacity, while others do not. Ask in advance.
Your failback process as important as your failover strategy. The issues — how long your methodology will take, the labor involved, the ease of transport, the costs of returning to or finding a new production site — should not be left to resolve during the recovery period. That's when company resources will be tight and your energy diminished. Address these things now, to prevent disaster later. If you'd like assistance in developing your failover strategy and process, contact us at www.flexential.com or call (888) 5523-FLEX.