Let us say you have a SQL Server Availability Group (AG) in your virtualized data center. This SQL Server AG is hosting many databases serving mission critical applications. There is a total of half a terabyte of mission critical data today but it is growing rapidly. You are worried about this SQL Server’s availability, and that is why you had configured it as an AlwaysOn Availability Group in the first place. And, you are well aware that AG does not protect against software glitches, corruptions and security vulnerabilities so you want to backup that half a terabyte somewhere else, preferably air-gapped away from the production site. In the unfortunate event of data loss, what is the best recovery time objective (RTO) that your backup vendor can offer?
You are likely to hear bricks and blocks backup vendors for on-premises touting the value of “instant recovery” for virtual machines. The RTO being promised is seconds to minutes. But when it comes to recovering a virtual machine (VM) to its production operational level, there is nothing ‘instant’ about the so-called instant recovery.
The so-called instant recovery is to serve the VM disk files from backup system via NFS and let VMware vSphere run the VM from those disk files. It is true that the process to boot up a VM from backup this way will only take a few minutes. It is true that the flash storage on backup systems can act as a caching mechanism for write-I/O. However, in order to make the VM operationally on-par for production use, the VM administrator must carefully plan and execute storage vMotion when the time is right. This process will migrate the VM disks from backup storage onto production storage while the VM is live. This process is often throttled down by vSphere so as not to hinder the live VM. It takes several hours to even a full day before a large VM can be migrated and becomes operationally ready for production level performance. So much for the “instant” in instant recovery!
Thus, for the SQL Server AG example above, the nodes must be served by a single backup storage system which goes against why you have AG. The AG is supposed to be set up with dedicated storage systems at each node for availability. Then, the AG cluster would have a hard time coming up as the synchronization will be extremely slow because I/O-reads are occurring from backup storage. Note that AG is unavailable during this time period and hence there is no ‘instant recovery’ really. To add insult to injury, the AG would limp along while the required storage vMotion needs to occur from overloaded backup storage onto production storage.
El problema de esta recuperación instantánea no termina ahí. La copia de seguridad sigue estando ubicada en el mismo lugar que el entorno de producción y, por lo tanto, es vulnerable a la pérdida del sitio y a las brechas de seguridad. No es posible utilizar el almacenamiento en la nube como destino viable para la copia de seguridad con fines de recuperación operativa desde estas soluciones. Además, la recuperación instantánea resulta inútil si se tiene previsto migrar las cargas de trabajo a VMware Cloud on AWS, ya que no se admite el almacenamiento NFS de terceros.
Clumio Rapid Recovery – Superior Operational RTO
Help to deliver secure backup and recovery for your data – wherever it needs to be. Rapid Recovery is a set of innovations from Clumio that enables fast operational restores from cloud storage even when you are protecting on-premises workloads. Thanks to Rapid Recovery with Clumio SaaS, it took just 5 minutes to recover an active SQL Server AG environment with 500GB of data given in the above example This is the time taken for end-to-end recovery and data restored to a fully operationally state. How did we do this? There are two innovations in Rapid Recovery playing key roles here.
Rehidratación escalable:
Clumio’s scale-out rehydration eliminates the rehydration penalty of traditional bricks and blocks systems altogether. Rehydration is done by Clumio using serverless compute and it takes advantage of the unlimited compute capacity of the cloud while running parallel I/O operations across all blocks of interest for a given request. The result: restore throughput from the Clumio backup service beats that of a traditional deduplication system co-located in the data center.
Seguimiento inverso de bloques modificados:
When you are recovering a VM in production from backup, you are essentially trying to roll back the clock so as to get to a last known good condition. Clumio’s reverse changed block tracking helps you do exactly that without the need to go through a full restore. The Clumio backup service retrieves the changed blocks (regenerated via scale-out rehydration described earlier) and applies them directly into production storage to rollback the VM to the previous point in time. The result: the time it takes to recover a VM from the Clumio backup service to a production operational level is faster than that of recovering from local storage!
Estas dos funciones de Recovery rápido de Clumio eliminan TODAS las limitaciones de la recuperación instantánea que ofrecen los proveedores tradicionales.
Let’s summarize the key customer benefits of Rapid Recovery from Clumio:
- No human intervention required: The backup admin or VM admin does not need to do anything during backup or recovery to take advantage of Rapid Recovery. Clumio SaaS automatically detects if the requested restore point in time meets rollback criteria and initiates it automatically during recovery.
- RTO is superior to that of instant recovery: You are bringing just the data required to roll back the VM and your recovery is complete. The time it takes to do this is better than the overall time it takes to perform instant recovery followed by storage vMotion.
- Protect against data loss and ransomware: Unlike co-located bricks and blocks based backup solutions needed for instant recovery, Clumio backups are air-gapped from your production datacenter. Clumio helps protect you against site loss and site-level vulnerabilities.
- Gets you ready for VMware Cloud on AWS: Instant recovery does not work in VMware Cloud on AWS environments because of its dependency on NFS. Rapid Recovery has you covered when you are migrating to VMware Cloud on AWS.
Want to try Rapid Recovery? Contact us.
