RoHS CompliantAll Small Tree cards, switches and storage products are RoHS compliant!

Snapshots…your trashcan, on steroids

May 19, 2014 by Steve Modica

I have to admit, as an old time UNIX guy that’s been around inodes, fsck and corrupted filesystems all my life, snapshots sounded a little too good to be true.

The word was long known to me.  Customers would say, “I took a snapshot of that disk so I could upgrade it and revert if I screwed something up.”  It’s just that imaging a disk would take hours.  You’d start the copy and go home for the night.

These new snapshots (like those supported by ZFS) were instantaneous.  One click and you would “instantly” have a new copy of your data.  How?  That’s not even possible.  To make it even weirder, the new copy takes up no space!?  Now it’s starting to sound like perpetual motion.

The actual explanation is a lot simpler. Every filesystem is composed of data (your file data) and metadata (the name of the file, permissions, location of blocks, inode number, etc.).  All this metadata is what organizes your data.  You have what’s called an “inode table” where all that stuff lives, and it “points to” the actual data you wrote.  It might be video data, or your mom’s apple pie recipe.

When you create a snapshot, you are instantly making a copy of that inode table.  You now have two. All these inodes point to the same data.  So the data was not copied.

Now the magic happens. When a user deletes a file from the original data, the inode for that file is removed, but the snapshot inode remains.  ZFS will keep the data around as long as there’s an inode in some snapshot somewhere pointing to it.  The same is true if you edit a file.  The old data is saved, but the new data gets written.

All this old stuff (old data) essentially becomes part of the snapshot.  As more things change, the snapshot grows larger. If you were to delete “all” the data on the original filesystem, the snapshot would essentially grow to the size of the original filesystem. (The original filesystem would drop to 0.)

In some ways, it’s a little like a trashcan. When you delete something, it doesn’t really go away. It goes into the trash. If you wanted to, you could drag it out of the trash.

There’s a similar way of recovering snapshots.  You simply “clone” (or mount) them.  When you do this, the snapshot inode table is mounted and it still points to all the old data.  That file you deleted yesterday?  If you mount yesterday’s snapshot, it’s right back where it was.  Simply drag it back out.

Obviously, while snapshots make for a great method of saving previous images of a set of data, they are not a backup solution.  If your RAID dies and can’t be recovered, your snapshots die too!  So for true backup protection, consider rsync or some other method of moving your data to another system.

Small Tree’s TitaniumZ servers support snapshots and rsync and we have a very nice graphical interface so you can manage it all yourself. If you have any questions about snapshots or a backup solution that’s right for your editing team, don’t hesitate to contact me at


No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.