Snapshots are not backups
Maintaining backups of business-critical data is one of IT’s most crucial roles in an organization. While other departments are tasked with the creation or generation of that data, IT’s job is to make sure that data is available and preserved at all times. Businesses executives decide the company’s appropriate RPOs and RTOs, and it’s up to IT to make that design a reality.
Snapshots are a widely available tool that seems to promise incredibly near-line RPOs and nearly instantaneous RTOs. Every major SAN vendor has a snapshot technology available, and even operating systems like VMware and Microsoft have their snapshot stories. The truth is that snapshots aren’t really backups, and they cannot be relied upon as a backup.
What’s a backup anyway?
In order for a tool to be a true backup solution, the backed-up data must be:
On separate offsite media
Completely self-contained copy
Immutable
If you back your SQL databases up to simple *.bak files on the same drive as the database, you haven’t created a backup, but rather you’ve created an archive. An archive is a copy of your data as it exists at a point in time that doesn’t meet all of the requirements to be a true backup. Archives can be very useful for quick restores and solving minor issues, but only backups truly protect your company’s data. Backups can be sent to external media, like portable hard drives and tape, or remote storage, like a NAS, SAN, or server at another site. A server’s RAID array does not count, as a backup must be able to survive a total failure of the source, not just a single hard drive failure.
A true backup must not be reliant on the original data. VMware snapshots and Microsoft shadow copies both rely on the original source information in order to restore to that point in time. A new copy of the data isn’t created. The original file is preserved and required, which means that if it is lost, then the snapshots are worthless. You must be able to restore all of your data with nothing but the backup itself.
If you’re using a mirroring strategy like NetApp’s SnapMirror technology, you’ve created a highly-available copy of your data, but not a backup. Any corruption on the source data is replicated at a block-level to your destination, which means that you are always at risk of losing the second copy of the data to an error or attack. The destination side of a backup must be completely immutable, so that any corruption or errors on the source can’t affect the destination.
Snapshots are awesome
While snapshots aren’t true backups, they do provide a lot of value. They can allow administrators to quickly fix minor issues and restore data in most scenarios. They can also be used for testing, development, and cloning. Snapshots reduce the amount of labor needed to manage an environment and are generally good enough for daily use. The issue is simply that they can’t be relied upon in a major disaster, and any true backup strategy must go beyond snapshots.
SnapVault is the best of both worlds
NetApp’s SnapVault technology allows companies to leverage snapshots for both quick management and backup purposes. A SnapVault relationship between NetApp filers creates a separate copy of the source data on the destination filer. The destination copy is completely self-contained and isn’t reliant on the source filer for anything after synchronization. The destination copy is completely immutable and uses its own file table and metadata to ensure that corruption in the source is prevented from affecting backups on the destination. The destination can be regularly updated via automatic replication.
By meeting all of the requirements of a true backup solution, SnapVault allows companies to be sure that their data is secure. Without a solution that includes all of the requirements of a true backup, a company’s data is at risk of being lost.