In this NetApp tutorial, you’ll learn what ONTAP Snapshots are and how they work. Scroll down for the video and also text tutorial.
NetApp Snapshot Operation Video Tutorial
Niklas Kusserow
First of all I want to thank you for the unbelievable work! The new NetApp course is even more informative, structured, exciting and detailed than the last one. I could not believe that this was possible but it is!
The way you are teaching the theory is understandable to everyone. No matter if they work with Netapp for years or just started learning it.
The labs are easy to build but super powerful, they represent every single detail from the theory lessons and help understand the material even more!
I would spend much more to get this oodles of knowledge from a teacher like you. Please keep up your great work!
Snapshots
A Snapshot copy is a read-only, point in time image of the active file system (AFS). An active file system is whatever files and folders with a directory structure of a volume right now. You've got your volume, whatever files and folders are active in it right now, that is the active file system.
Snapshots are used for very fast and very convenient, short term backups. Individual files, folders, or the entire volume can be quickly and conveniently restored by the storage administrator or by end users if you enable the option to allow them to do that.
They're configured and maintained at the volume level and different volumes can have different snapshot settings, for example, how often we take each snapshot.
Aggregate Snapshots
For our day-to-day running of the system, our snapshots are going to be managed at the volume level, but aggregate level snapshots are also supported.
These are required for SyncMirror and MetroCluster, and they can be used by NetApp technical support to restore data if the aggregate file system becomes inconsistent. It is highly unlikely that that would ever happen, but if it does it's possible for technical support to possibly restore that from an aggregate level snapshot.
The aggregate level snapshots are there and supported, but when we're talking about snapshots in general, and when we're configuring and using them, it's going to be volume level snapshots.
Snapshots
When the snapshot is taken, it does not back up the data by copying it to new blocks on disk. It doesn't take up double the amount of blocks. The way it does work is it consists of pointers to the blocks on disk that were in the volume at the time that the snapshot was taken.
Because it's not copying data to new blocks on disk and just taking a pointer, the snapshot is nearly instantaneous. It's not taking time to actually copy it and move it into a new location, so it's nearly instantaneous. Also, it does not initially take up any space on disk, apart from a root inode index file.
It just got pointers and it's just an index of what was on disk. It doesn't actually copy it to a new location. That index takes up practically no space, it's about 4 kilobytes in size. When you first take a snapshot, it basically doesn't take up any space and it's basically instantaneous.
As for the active file system changes, however, blocks which would have been removed from it could be locked by a snapshot. The snapshot, therefore, starts to take up space over time.
The snapshot is saved in the volume that it is taken off, so if you lose the volume, you lose the snapshots of the volume to. Snapshots initially take up no space, but they do grow over time, so because of those two characteristics of snapshots they're used for short term convenient backups and restores.
They do not replace a long-term offsite backup strategy. This is because the snapshot is saved in the actual volume that it's a snapshot of. So, say that you have a fire in the building or some other natural disaster, and you physically lose that volume. Well, you've lost all the snapshots of it as well.
For your long term backups, they need to be saved off-site somewhere, so if you do lose a site, if you do lose a physical system, you're not going to actually lose your data.
However, snapshots do not give you that capability. Snapshots are not a complete backup strategy, they're used just for short term backups. For your long-term backups, you're going to need an offsite backup.
Backup the data to an external location. You can use SnapVault or you can use tape for that. Another reason that they're not a long-term backup solution is that the snapshots start to take up space over time. If you left them there for a long time, they're going to start taking up all the space in your volume, and we don't want to do that.
Typically, we're going to automatically delete snapshots as they reach a certain age, so we're only going to have short term snapshots kept in the volume. Therefore, they're not going to take up too much space.
Snapshots can be taken manually on demand, so if you knew that some changes were going to occur, you could quickly take a snapshot as a backup before those changes happened. Snapshots can also be taken automatically based on a schedule, and that's the most common way for snapshots to occur.
Snapshot Example
Let's look at an example of how snapshots work. Here we have got a volume and somebody has written some data to it. It contains the blocks A, B, and C. The active file system (AFS), that's what's in the volume right now, is blocks A, B and C.
Now, we take a snapshot of the volume. That is our T0 snapshot. That locks blocks A, B, and C. The snapshot doesn't take up any space, it just consists of pointers of what was in the active file system at the exact time that the snapshot was taken. So, snapshot T0 has got pointers to blocks A, B, and C.
Then, a user writes more data to the volume. Block D is added to the active file system. Right now, the active file system contains blocks A, B, C and D. The T0 snapshot, a snapshot, is read-only and it never changes. The T0 snapshot is always going to contain pointers to blocks A, B, and C.
The next thing that happens is we take a T1 snapshot. Again, it's a snapshot of whatever is in the active file system right now, that is blocks A, B, C and D. Therefore, the T1 snapshot consists of pointers to blocks A, B, C and D.
Next up, blocks A and D are deleted from the active file system, and block E is created. A user has edited the files that are in that volume. They've ended up deleting blocks A and D, and creating block E.
You can see that right now, the file system consists of blocks B, C and E. The snapshots never change, so T0 is always going to contain pointers to blocks A, B and C, and the T1 snapshot is always going to contain pointers to blocks A, B, C and D.
The next thing that happens is we take another snapshot, that is our T2 snapshot. Again, it's pointers to whatever is in the active file system right now, that is blocks B, C and E.
Then, block E is deleted from the active file system.
Snapshot Example Implications
Let's look and see where we are at right now. The point in time that we stopped with the example, block A is locked by the T0 and the T1 snapshots. It's no longer in the active file system.
Block B is locked by T0, T1, T2, and the active file system. Block C is the same. It's locked by the T0, T1 and T2 snapshots and also the active file system.
Block D is locked just by snapshot T1 and block E is locked by the T2 snapshot. Blocks A, D and E would be deleted if we didn't have snapshots.
You can see that the snapshots are starting to take up space over time. When the snapshots are first taken, they're just a pointer to what is in the active file system, they don't take up any space at all. But right now, blocks A, D and E have been deleted from the active file system.
If we didn't have any snapshots, they would be deleted and not taking up space. But because they are contained in snapshots, those blocks are not actually deleted, they're not freed up on the disk, so you can see that the snapshots are taking up the space of blocks A, D and E.
If we delete the T2 snapshot, block E will be deleted because the T2 snapshot is the only thing that is locking block E right now. If we delete the T1 snapshot, block D will be deleted. Again, because with T1 snapshot is the only thing that's locking block D right now.
If we wanted block A to be deleted, we would need to delete the T0 and the T1 snapshots, because they are both locking block A. If we deleted the T0 snapshot on its own, that would not free up any disk space, because everything that is being locked by T0 is also being locked by something else as well.
You can see with this that the amount of space that is being taken up by different snapshots is hard for you to see what's happening, because you can have multiple snapshots which may or may not be locking the same blocks. Those blocks may or may not be locked by the active file system as well.
To see exactly how much space your snapshots are taking up, and how much space would be freed up if you deleted a snapshot, there are tools available, such as the space reclaimable command.
Additional Resources
What a Snapshot Copy is: https://library.netapp.com/ecmdocs/ECMP1635994/html/GUID-FB79BB68-B88D-4212-A401-9694296BECCA.html
Creating Snapshot Copies Manually: https://library.netapp.com/ecmdocs/ECMP1368826/html/GUID-E30DF75C-A3DC-4BD5-BCB5-9402962D9DA4.html
User Access to Snapshot Copies: https://library.netapp.com/ecmdocs/ECMP1368826/html/GUID-D951E474-AE33-4B4C-A492-F7BBABDAF1F4.html
Libby Teofilo
Text by Libby Teofilo, Technical Writer at www.flackbox.com
With a mission to spread network awareness through writing, Libby consistently immerses herself into the unrelenting process of knowledge acquisition and dissemination. If not engrossed in technology, you might see her with a book in one hand and a coffee in the other.