Server recovery from backup typically means copying data from the backup device over the network back to a production storage system or server. In addition to copying the data across the network, the backup software has to extract it from its backup format and send it in a native format. Especially for larger servers, the time to extract and transfer this data can take most of the recovery time objective (RTO) window. A common answer to the server recovery problem is using a feature like in-place recovery, which instantiates the server’s data on the backup storage devices. Instant recovery while solving one challenge, RTO, creates several others.
The Problems with In-Place Recovery
The first problem with in-place recovery is that when a backup is instantiated on the backup device, that recovery device becomes, at least temporarily, production storage. Production storage needs to perform well and needs to have high-availability capabilities, which most backup storage systems can’t deliver.
The second challenge with in-place recovery is that a server is still required to attach to the backup storage instantiated volume. If the cause of the recovery impacts both the production server on which an application is running, as well as its storage, then even if the volume is instantiated, the organization is still lacking a server to run the application and attach to the data.
A third challenge with in-place recovery is how does the organization fail-back to normal operations? If it’s possible to circumvent the first two challenges, and the application is able to leverage the instantiated volume, then changes are going to be made to that volume as the users access the application. The instantiated data volume is now the production copy. It is necessary to protect it and the organization needs a way to move that volume back onto production storage. There are tools to execute these moves but too often, they are lacking in the backup application. These tools also typically require application downtime while making the transfer.
IT professionals need to plan and compensate for all of these challenges. One approach is to use high quality storage to ensure proper protection of the recovered application but this approach raises the price of the backup infrastructure. Disaster Recovery as a Service (DRaas) features can overcome the second challenge by instantiating the application in addition to its data. However, many backup solutions don’t have an integrated DRaaS capability. The third challenge is almost completely unavoidable; organizations just need to work through it if they are going to leverage a recovery in-place product.
Overcoming Recovery In-Place Challenges with Streaming Recoveries
An alternative to recovery in-place is streaming recovery. Streaming recovery instantiates the application and its data directly on the production device intended for their use. The application is immediately available with data streaming to its storage location in real-time. If data isn’t available at the moment of access, it is served from the backup store until the entire data set is recovered. The result of data streaming is that data is on the right server and the right storage as soon as the restore completes but it is also instantly available. The only trade off might be a slowdown in performance if a user requests data that isn’t yet recovered.
Both in-place and streaming recovery are technologies that every IT professional should explore. The ability to recover quickly from a backup instead using a more expensive high availability solution enables the organization to bring rapid recovery to more applications, an imperative, since organizations are seeing such growth in the number of applications they support.
To learn more about the different types of recovery, check out our on demand webinar “Ransomware, Rapid Restoration and Disasters – Recovering from Backup’s Big Three.” In the rapid restoration section, we focus on the various rapid recovery options that are available.