A solid disaster recovery (DR) strategy is crucial for minimizing the impact of data loss for any business. Many businesses struggle to establish a DR plan that balances their needs for fast recovery times, recent recovery points, and minimal budget impact.
Generally speaking, the faster the recovery time objective (RTO) and the more recent the recovery point objective (RPO), the costlier a disaster recovery solution will be.
This sometimes leads businesses to try and find creative solutions to their DR needs—such as trying to use their virtualization software’s snapshot feature for disaster recovery.
However, using snapshots for disaster recovery is something that businesses really shouldn’t do. Here are the top three reasons why:
#1: System Stability Issues
Snapshots are designed primarily for use in test & dev applications. Basically, snapshots create an image of the virtual machine that the machine can be rolled back to later. Companies use this all the time before making a major modification to the system so that, if the alteration causes some kind of fatal crash or error, the system can be quickly restored to normal.
The issue here is that snapshots are built for short-term recovery—they don’t create physical copies of memory blocks; they simply point to where the blocks existed when the snapshot was created.
Depending on how your snapshots are handled, keeping a snapshot on the drive for a prolonged period of time can create performance and stability issues.
For example, a copy-on-write-based snapshot will cause the first write operation to a database block to translate into two storage writes: one for the copy of the original block to the snapshot storage location, and one to the write of the new block over the original.
This effectively doubles the I/O load for each write operation, which means only half as many simultaneous I/O operations can happen at once.
Additionally, if you revert to a previous snapshot, the now-active memory blocks will have references to the fragmented snapshot blocks, which slows down data retrieval.
#2: Cumbersome Management of Production Backups
Snapshots are often cumbersome to use as a DR tool. Generally speaking, snapshot tools are designed to be manually triggered prior to making major modifications to a production environment. They’re not designed to continuously update the backup like a true disaster recovery solution.
So, if you want to keep a recent recovery point, you’ll have to continuously remake the snapshot, which is time-consuming and a major drain on computing resources.
At best, your recovery points will be infrequent enough that there may be significant data loss in case of a data loss event (such as accidental erasure, ransomware attacks, etc.). At worst, your snapshot will be too old to be particularly useful.
#3: Some Data Loss Events Will Affect the Snapshot Too
A snapshot merely points to data blocks on the same storage environment so that they can be restored if something goes wrong. While great for a temporary solution that allows users to roll back the VM to a previous state if an update or new piece of software causes issues, it’s not so great if the storage volume that the pointers exist on becomes irreparably corrupted, or if the server running the VM becomes unavailable.
True disaster recovery solutions will have a complete replica of the production environment on a remote server. So, if the worst happens and the whole production environment becomes irretrievable, you can redeploy from the replica environment, minimizing data loss and delays.
Disaster recovery takes more than just a local copy of data files or the ability to roll a single virtual machine back to a previous state. True DR plans need to take into account all the different potential failures in a system and create contingencies for ensuring business continuity in the worst-case scenario.
Learn more about creating a comprehensive business continuity plan with a solid disaster recovery framework today!