This is part one of a two-part blog on snapshots.
In the storage world, snapshots are a point-in-time copy of data. They have been around for some time and are increasingly being used by IT to protect stored data. This post recalls some of the popular Nimble Storage blog posts on snapshots. But before I jump into the list of blogs, let me quickly walk you through the different types of storage-based snapshots, including their attributes.
A snapshot copies the metadata (think index) of the data instead of copying the data itself. This means taking a snapshot is almost always instantaneous. This is one of the primary advantages of storage-based snapshots—they eliminate backup windows. In traditional backup deployments, applications either have to be taken off-line or suffer from degraded performance during backups (which is why traditional backups typically happen during off-peak hours).
This means snapshot-based backups can be taken more frequently, improving recovery point objectives. However not all snapshot implementations are created equal, posing different requirements and restrictions on their use (example: reserve space required, how frequently snapshots can be taken, and number of snapshots that can be retained).
In the ‘Copy-on-Write’ (COW) implementation, the address map related metadata is copied whenever a snapshot is taken. None of the actual data is copied at that time—resulting in an instant snapshot. In almost all implementations this copy is taken to a ‘pre-designated’ space on storage (aka a snapshot reserve). When the data is modified through writes, the original data is copied over to the reserve area. The snapshot’s metadata is then updated to point to the copied data. Because of this, ‘COW’ implementation requires two writes and a read when any of the original data is modified for the first time after a snapshot is taken—causing a performance hit when the original data is updated. This gets progressively worse with frequent snapshots. Vendors such as EMC, IBM, and HP have used COW implementations on their traditional storage.
The other major implementation of snapshots is ‘Redirect on Write’ (ROW). Like COW, only the metadata is copied when a snapshot is taken. Unlike COW, whenever original data is being modified after a snapshot, the write is redirected to a new free location on disk. This means ROW snapshots do not suffer the performance impact of COW snapshots as none of the original data is copied.
Nimble snapshots are based on the ROW implementation as the write-optimized data layout in the CASL architecture always redirects writes to new free space. A lightweight, background sweeping process in CASL ensures the continued availability of free space and assures consistent performance, addressing a shortcoming of some older ROW implementations. This efficiency allows IT to think of snapshot + replication in a new light—store weeks/months of history versus mere days of backups with traditional, inefficient implementations. This allows virtually all of the operational recoveries to come from snapshots and dramatically improves RTOs. (Umesh’s blog ‘A Comparison of File System Architectures’ linked below covers this in detail.)
Nimble Storage snapshots are stored (compressed) alongside the primary data on high-capacity disk drives. This allows 1000s of snapshots to be taken and retained on the same system as primary data. A measurement of our install base shows that over 50% of our customers retain their snapshots for over a month.
First is the support of universal inline compression for storing data. This ensures data takes up less space on disk, which as discussed earlier makes replication more efficient and allows for more snapshots to be retained in a given storage space. On average, Nimble’s install base measure compression rates ranging from 30% to 75% for a variety of workloads.
Second is the support of cloning, which is fully functional read/writable copy of the original. Cloning is useful in the cases of VDI and test/development where many copies (clones) of a master data set are needed. In the ROW implementations, clones do not take up any additional space.
Last but not least is the granularity of the snapshot. This determines how small a snapshot can be for a volume. This is relevant when the data volume being protected has a small rate of daily change. When the extent of a data write is smaller than the snapshot granularity, the snapshot wastes considerable space storing a duplicate copy of unchanged data. Snapshots in Nimble’s CASL architecture can be as granular as a single 4K block.
Before going onto the blogs, I wanted to share that Nimble Storage (@NimbleStorage) and CommVault (@CommVault) recently did a joint Twitter Chat on the Nimble Storage integrations through CommVault IntelliSnap Connect Program. The chat featured experts from Nimble Storage (@wensteryu, @schoonycom & @scnmb… me) and CommVault (@gregorydwhite & @liemnguyen). Here is the edited transcript for your reading pleasure.
Leveraging Snapshots for Backup: An Expert View (http://www.nimblestorage.com/blog/technology/leveraging-snapshots-for-backup/): Radhika Krishnan interviews Jason Buffington (@JBuff) who is ESG’s Senior Analyst covering Data Protection. According to ESG’s research 55% of the IT shops are looking at snapshots augmenting their backups.
Snapshots + Backup Management = the Best of Both Worlds (http://www.nimblestorage.com/blog/technology/snapshots-backup-management-the-best-of-both-worlds/): Another blog talking about need for integration between storage systems and their native snapshot capabilities and backup storage delivering rich data management functionality
How Snappy and Skinny Are Your Snapshots? (http://www.nimblestorage.com/blog/technology/how-snappy-and-skinny-are-your-snapshots/): Umesh Maheshwari (our CTO) talks about concept of COW versus ROW and discusses benefits of variable block support.
A Comparison of File System Architectures (http://www.nimblestorage.com/blog/technology/a-comparison-of-filesystem-architectures/): Another blog by Umesh. This one talks about the concept of keeping data optimized on disk–especially applicable if your want to know how should storage handle deleted snapshots. The comments at the bottom are worth reading.
Extended Snapshots and Replication As Backup (http://www.nimblestorage.com/blog/technology/2160/): Ajay Singh discusses using snapshots and replication for deploying Disaster Recovery.
Can you have a backup system based solely on snapshots and replication? (http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/299-snapshots-replication-backups.html/): A W. Curtis Preston special calling it as he sees it.
The Nightmare of Incremental Backup is Over (http://www.nimblestorage.com/blog/technology/the-nightmare-of-incremental-backup-is-over/): Nicholas Schoonover discusses concepts of RPO and RTO with incremental backups.
Better Than Dedupe: Unduped! (http://www.nimblestorage.com/blog/technology/better-than-dedupe-unduped/): Umesh shows a mathematically comparison of total storage space between different types of storage making the case for optimizing your entire storage environment. Be sure to skim through the comments at the bottom.
This is a part one in a two part series. In the second blog, we’ll cover the concept of data integrity, discuss application integration and review the different demos covering data protection and high availability.
We would love to hear from you. Follow us on Twitter (@NimbleStorage), send us a tweet (#nimblestorage #hybridstorage) or leave a note below.