How do netapp snapshots work

#|

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.

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. 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. Users can access Snapshot copies online, enabling users to retrieve their own data from past copies, rather than asking a system administrator to restore data from tape. Administrators can restore the contents of a volume from a Snapshot copy. Each volume has a. The contents of the. If users accidentally delete or overwrite a file, they can locate it in the most recent Snapshot directory and restore it to their main read-write volume simply by copying it back to the main directory.

OLTP workloads with data change rates which are higher could also benefit from this type of Snapshot-only policy. NetApp uses its Snapshot technology to provide you with instantaneous, highly efficient storage backups that can be used in many recovery scenarios, including recovering from possible ransomware threats , without impacting your AFF or FAS performance. Add the Cloud Tiering solution to this mix and you end up with a more efficient snapshot-based backup strategy with savings in storage TCO provided by Cloud Tiering.

Cloud Central. View All Blogs. Subscribe to our blog. Thanks for subscribing to the blog. October 4, Topics: Cloud Tiering Advanced 8 minute read. Copy on Write Under the COW approach, data blocks in a snapshot which need to be modified have to go through a process that would copy them elsewhere. A write operation to put them in the snapshot area on the disk.

A write operation of the modified data into the original blocks. Similarly, when a restore operation from a snapshot is performed, the storage system goes through a decision process where it examines the blocks being kept securely. For each block it needs to know whether or not that block was modified.

If it was modified, then the storage system needs to get the data block from where it was copied to. Redirect on Write With the Redirect on Write approach, whenever a data block protected by a snapshot needs to be modified, the system only redirects the writes of data that was changed to new storage blocks and updates the pointers of the active file system to those blocks.