Why Snapshots Are Not Backups
You are likely one of those too. You want terabytes of data accessible anywhere on any device. The same is true of your most critical applications. If you inadvertently delete something, you want the information restored in just a few minutes.
That magic is called a snapshot. For a Storage Area Network (SAN) that holds your data and has regularly scheduled snapshots, a previous copy of your data is available and can be rolled back to that point in time. However, there are some important aspects to understand about snapshots and these are the key take-aways:
- Without the current copy of your data, snapshots are worthless as they are dependent upon the differences between the original information.
- Snapshots for virtual machines allow rollback for any changes, but cannot be used by themselves as a functional virtual image.
- Snapshots are not a backup of server system state, especially for critical roles like domain controllers.
- Snapshots do not clear the transaction logs of Exchange databases.
- For all of the above reasons, online backup should backup system states and databases independent of server incremental snapshots.
This post was inspired by a customer who recently and painfully experienced why snapshots are not backups. The customer was updating an application on their main domain controller (not a good practice either and a topic for another time) which went awry. After restart, the NETLOGON service would not remain started and Active Directory would not replicate with the secondary domain controller.
The customer lamented that they had performed the application update on several servers with no issues and had not taken a snapshot of the virtual machine. It wouldn’t have mattered. The problem is known as USN rollback where the server was no longer recognized as the master security database for the network. With a system state backup, the issue could have been resolved in a few minutes with an authoritative restore.
Instead an emergency project was required to:
- Create a new virtual server
- Export DHCP scopes
- Manually remove the errant server from Active Directory
- Seize the FSMO roles on the secondary domain controller
- Shutdown and destroy the errant server
- Promote the new server as a domain controller
- Change the IP address of the new server to the previously errant server
- Broadcast to users to shutdown workstations for cutover
- Import DHCP scopes
- Verify Active Directory replication
Fortunately, the secondary domain controller processed user logons during this scenario, even though no changes could be made to any Active Directory accounts. If the customer had not had a secondary domain controller, they would have had the ugly prospect of building a new domain controller and rejoining every user and device to the domain with weeks of profile and application hell.
When asked about other backup scenarios like Exchange, the customer said they used Symantec Backupexec as it was easier to restore than using their current online backup. More likely, someone on their staff discovered the Exchange logs weren’t being cleared and they had no way of restoring an individual mailbox using a server snapshot.
If you’re depending on snapshots only, then heed the warnings above and know you’re operating under high risk of downtime and data loss. The simple fact is snapshots are not backups.
