Snapshots have long been a part of any good data protection plan, and today they are even more critical due to security threats such as ransomware. Snapshots offer point in time recovery so if data is lost, corrupted, or held hostage, users can simply go back to the last point in time before the problem occurred and recover their data. This allows for significantly improved recovery time objectives (RTOs) and recovery point objectives (RPOs).
While snapshots in and of themselves are not a new concept, how snapshots are performed, how they are stored, and their effect on performance have changed over time and can have a significant impact on an organization. With that in mind, let’s take a look at how Panzura snapshot technology compares to that of one of our competitors, Nasuni.
At first glance, Panzura and Nasuni would seem to offer similar products. Both companies have products that allow customers to consolidate data in the cloud, and both Panzura and Nasuni provide snapshots as a way of protecting data. However, that is where the similarities end because each company’s products are designed with fundamentally different architectures.
One of the results of using a different architecture is that each company’s products perform snapshots differently. Nasuni uses a very space efficient snapshot technology known as copy-on-write. When a change is made to data that is protected by copy-on-write snapshots, before the data is overwritten, it is first read into memory. The original data is then written to the snapshot space. Finally, a second write is performed, with the new data overwriting the original. This means that for every write to occur, not just one, but three I/O operations need to be performed.
Copy-on-write is a legacy snapshot technology that was once widely used, but is generally no longer common on enterprise class products. The well-known performance penalty of three I/O operations for every write that is performed can cause significant performance degradation, particularly in write-intensive environments, or simply over time.
A modern, more efficient way to do snapshots is with the redirect-on-write method. Redirect-on-write keeps the original data intact, and simply directs the pointer to another block and writes the data there (i.e., it redirects on write). Snapshot metadata keeps track of where all the blocks are that comprise a snapshot. This has the advantage of providing the same level of space efficiency as the copy-on-write method, but without the performance overhead. One write means one I/O operation with no noticeable overhead or performance penalty. Panzura uses the redirect-on-write method.
So we now know that Panzura snapshots do not suffer from the performance penalty that Nasuni does, but how do they compare in terms of the number of snapshots that can be taken? Nasuni claims to have unlimited snapshots, which is physically impossible, so what is the reality?
Nasuni says they have tested up to 27,000 snapshots, but because their snapshot technology is based on the Linux Volume Manager (LVM), they are in fact limited to 256 snapshots per volume. That’s a lot of volumes. In contrast, Panzura has tested 10,000 snapshots (enough for 1 per day for 27 years). Note that I say that is what we have tested. Our distributed cloud file system can support 264 (about 18 quintillion) snapshots, so we could go higher.
At the end of the day, the whole point of snapshots is to protect your data. Both Panzura and Nasuni have proven snapshot solutions that can allow you to recover from a problem by rolling back to the last point in time before the problem occurred. Both are space efficient and both can scale. The difference is that one solution is designed for the modern data center and does not impact performance, while the other is based on legacy technology that is known to cause performance problems. When your data is compromised, which would you choose to get you back on track?