Snapshot. Snapvault. Snapmanager. SnapLock. SnapDrive. SnapMirror.
Are you screaming and confused yet?
Don't worry. Most of their new customers are, as was I, until about a couple of years or so ago when I really took the time to dive in with some SE's and try to understand the logic around it all.
Since I still hear from new and/or potential customers frequently, asking me to help them understand what all of this "Snap" stuff is about, I thought I would take the time to write it all out here.
What I’m not going to do is regurgitate a bunch of the circles and ABC diagrams that you can find on the NOW site or in a typical google search, because that can often times compound the confusion. We’re going to strictly talk logic, vocabulary, and understanding. So you other NetApp guys out there, please understand this is more personal theory than “inode level 2” type stuff.
So sit back, grab a coffee, open your mind, and let's get going!
Snapshot.
NetApp defines a Snapshot as: "a read-only, space-efficient, point-in-time image of the data in a volume or aggregate. It is only a picture of the file system and does not contain the actual contents of data files."
Wait. What do you mean it doesn't contain data?! What's the point otherwise!?
OK, here's my version: Think of a snapshot as a differential backup from the last time you took a full backup. What happens during a differential backup? Only the parts/files that have changed since your last backup get backed up. Similar concept, only we're talking blocks instead of files. Your live volume will be the equivalent of your full backup, and every time you take a snapshot, it’s another differential copy. This isn’t a 1-to-1 comparison of the two minds of thought, but it’s an easy way for new folks to understand.
All those words at the top of this post that start with Snap are all based on the Snapshot, and the concepts around it. Keep that in mind as we talked about the other big Snap words.
So let’s continue on with what is likely the most commonly used…
Snapmirror.
Snapmirror is exactly what you think it would be, just as it sounds. It is a mirror of a dataset between two different NetApp filers. While there are different levels and utilizations of Snapmirror, I don’t want to go into it here, because that’s not what we’re talking about.
How are Snapshots and Snapmirror related? That’s what I want to cover here, because everything is based around the Snapshot.
When you first build a Snapmirror relationship of a volume between two filers, this relationship must be “initialized.” Initializing the Snapmirror is a fancy way of saying, “I need to copy all the data from the source to the destination, before I can actually start syncing the data.” How does it do this effectively? You guessed it. Snapshot. A snapshot is taken at the time of initialization, and this is called your “baseline.” Contents of this snapshot are completely sync’ed between the two filers, including any and all other snapshots you’ve taken on the source. Since snapshots of a volume are stored within said volume, and you’re making a 1:1 mirror copy of said volume, all the other snapshots from the original source volume are coming along too. So when you go to snap list <vol name> or Filer > Volume > Snapshots > Manage in FilerView, you will see all of you scheduled snapshots, as well as a new one (“baseline”), and all of these will exist for that volume on both filers hosting the Snapmirror relationship.
Make sense? If not, ask away in comments!
"But Nick, I don’t want to keep a constant 1:1 full copy sync’ed of all of my volumes on two controllers! I just want a backup mechanism to be able to store MORE snapshots for longer periods of time!"
Ah-HA! Enter SnapVault.
SnapVault is the disk-to-disk “backup” version of SnapMirror. Where SnapMirror is the 1:1 scheduled sync’ing of a volume, SnapVault is the scheduled “backup” of a volume, only copying changed blocks in…you guessed it…Snapshots (noticing a trend here?)…from the source to the destination.
SnapVault systems are made up of two major components:
SnapVault Primary’s: These are you source systems containing volumes/datasets that you want to backup.
SnapVault Secondary’s: These are the destination system(s) where you long-term archive as many iterations of a dataset as you have available disk to store them on.
To make it easier to understand, think of it as a hub-and-spoke topology. In the simplest of configurations, your SV_Secondary (destination) filer is the hub of the wheel, and each SV_Primary (source) represents a single spoke, connecting back to the hub. You can SnapVault many primary systems to a single secondary system, again, for as much disk as you have available on the secondary to store data. For every controller (2 on clustered systems) you must have a SV_Primary license if you intend to use SnapVault to backup volumes on that controller. However, you will only need the single SV_Secondary license, unless you begin to expand your SnapVault configuration out even more.
SnapVault also gives you the ability to centrally control all snapshot schedules among all of your filers across your entire infrastructure, to maintain naming conventions, standardize schedules, etc. This gets even moreso centralized with NetApp’s other software product, known as Protection Manager. But, again, a little out-of-scope of this writing.
Before we get to SnapManager products and SnapDrive, I wanted to cover one that is most-often used in Legal, Hospital/Medical, and government agencies, which require extremely long-term archiving of WORM data. In case you didn’t know, WORM stands for Write-Once-Read-Many. It is a way of locking down change access to data completely (even from admins) but still allowing to be accessed in a read-only fashion for reporting, auditing, compliance, and legal purposes.
SnapLock.
SnapLock is NetApp’s way of locking down a dataset in this fashion. It is almost always used in conjunction with a 3rd party application that is used to manage archived data. Similar comparisons to this are things like EMC’s DiskXtender product, which uses UDO laser discs as WORM media. But, this is still cumbersome, as it requires you to manage laserdiscs, and protect them if they ever have to be moved, removed, or destroyed.
SnapLock is still used in the same fashion, only you’re locking this data down onto your Unified shared storage, and this can be mirrored, snapped, or vaulted to other controllers, and will still maintain its SnapLock status.
Honestly, this is the one I have the least experience with, but being a medical company, we are looking at ways to improve our current WORM solution, and SnapLock is definitely on the radar for us in the next couple of years.
SnapDriveandSnapManagers
These two are not directly related to Snapshots, but they affect the ways and processes that Snapshots are taken. SnapDrive and SnapManager products are middle-men. They are communication applications that allow applications, operating systems, and NetApp storage systems to all speak the same language and accomplish all of your goals for you.
NetApp has a SnapManager app out there for just about every tier1 application on the marketplace.
Oracle (SMO)
Exchange (SME)
SQL (SM-SQL)
VMware (SMVI)
…and more.
I’m going to pick the one I’m the most familiar with (Oracle) to give some direct steps and examples of how these two coordinate among the App, OS, and Storage system to give you app-level-consistent snapshots of your apps and databases.
SnapDrive is the “agent” of sorts, that gets installed locally on the host of whatever application/OS/DB you’re wanting to take snapshots of. He will tell the OS and local host disks the correct instructions when the NetApp controller makes calls to it.
SnapManager application software also gets installed on your host, but it is geared more as an agent for the application/db running on said host. He will tell the Application itself the correct instructions when the NetApp controller makes calls to it.
These two have to work in conjunction with each other, as well as with the OS/application/DB/NetApp, in order to give you consistent backups.
So here we go: The layman’s language of how SnapManager takes a snapshot of a production Oracle database.
Let’s assume you want to snapshot an Oracle database once per day at midnight. Oracle databases need to be put into “hot backup mode” in order for the snapshot to be worth anything. You schedule SMO to take this snapshot of this database named ORACLE on a host named SERVER1 every night at midnight. The data files for this db are stored on FILER1.
It goes down a little something like this:
SMO> Hey, FILER1, my schedule says it’s time to snapshot ORACLE database on SERVER1.
FILER1> Hmm, ok. Let me check with SERVER1 and make sure SnapDrive isn’t busy, because he’ll have to pause the mount points to the OS while we do this thing.
SnapDrive> Hey! SERVER1 said you needed me. Yea, I’m ready when you guys are!
SMO> OK, hold on, let me put the database in hotbackup mode. (alter database *) OK, done!
FILER1> OK, SnapDrive, I’m gonna snapshot, you ready on those mount points?
SnapDrive> Ready when you are!
SMO> Go go!
(roughly 60 seconds per 100GB is typically what I see here)
FILER1> OK, snapshots completed, SMO. Name them whatever you like and re-open the database when you’re ready!
SMO> Done and done. (alter database open *) We’re done! See ya tomorrow night!
So, while SnapManager and SnapDrive don’t really have anything to do with the snapshots themselves (technically…let’s not split hairs here), they are pivotally important to the communications between all systems involved. And while I didn’t understand the product(s) initially, I have certainly fallen in love with them, and would love to be involved in the “how to make them better” side of things.
Each of the tier1 app SnapManager products must be run and configured autonomously of each other, but there is unconfirmed rumor abounding about a “unified view” version coming soon where you will get a MMC-style version that will encapsulate all SnapManager products into one screen, giving you a single pane of glass to manage all of your snapshotting routines for all of your tier1 apps.
I hope this will serve as a good primer for you newer NetApp customers out there, and help clear up some of the confusion about what each of the Snap products does and how they interact with other.
At the end of the day, spend most of your time understanding what a Snapshot is, but more importantly what it isn’t. Once you have that down-pat, the rest just comes along naturally.