Skip to main content
Enterprise applications

SnapRestore

Contributors jfsinmsp
PDFs

Rapid data restoration in ONTAP from a snapshot is delivered by NetApp SnapRestore technology, which allows you to instantly restore the state of an AFF volume or an ASA LUN.

When a critical dataset is unavailable, critical business operations are down. Tapes can break, and even restores from disk-based backups can be slow to transfer across the network. SnapRestore avoids these problems by delivering near instantaneous restoration of datasets. Even petabyte-scale databases can be completely restored with just a few minutes of effort.

While the basic technology is the same on AFF and ASA platforms, the they are used slightly differently.

AFF Overview

There are two forms of SnapRestore on an AFF system - file-based and volume-based:

  • Individual AFF files, LUNs, and namespaces and individual ASA LUNs and namespaces can be restored in seconds, whether it is a 2TB LUN or a 4KB file.

  • The complete contents of an AFF volume can be restored in seconds, whether it is 10GB or 100TB of data.

The reason SnapRestore works so quickly and efficiently is due to the nature of a snapshot, which is essentially a parallel read-only view of the contents of a volume, LUN, or namespace at a specific point in time. The active blocks are the real blocks that can be changed, while the snapshot is a read-only view into the state of the blocks that constitute the files and LUNs at the time the snapshot was created.

ONTAP only permits read-only access to snapshot data, but the data can be reactivated with SnapRestore. The snapshot is reenabled as a read-write view of the data, returning the data to its prior state. SnapRestore can operate at the volume, file, LUN or namespace level. The technology is essentially the same with a few minor differences in behavior.

AFF Volume SnapRestore

Volume-based SnapRestore returns the contents of an entire volume to an earlier state. This operation does not require data movement, meaning that the restore process is essentially instantaneous, although the API or CLI operation might take a few seconds to be processed. Restoring 1GB of data is no more complicated or time-consuming than restoring 1PB of data. This capability is the primary reason many enterprise customers migrate to ONTAP storage systems. It delivers an RTO measured in seconds for even the largest datasets.

One drawback to volume-based SnapRestore is caused by the fact that changes within a volume are cumulative over time. Therefore, each snapshot and the active file data are dependent on the changes leading up to that point. Reverting a volume to an earlier state means discarding all the subsequent changes that had been made to the data. What is less obvious, however, is that this includes subsequently created snapshots. This is not always desirable.

For example, a data retention SLA might specify 30 days of nightly backups. Restoring a dataset to a snapshot created five days ago with volume SnapRestore would discard all the snapshots created on the previous five days, violating the SLA.

There are a number of options available to address this limitation:

  1. Data can be copied from a prior snapshot, as opposed to performing a SnapRestore of the entire volume. This method works best with smaller datasets.

  2. A snapshot can be cloned rather than restored. The limitation to this approach is that the source snapshot is a dependency of the clone. Therefore, it cannot be deleted unless the clone is also deleted or is split into an independent volume.

  3. Use of file-based SnapRestore.

AFF File SnapRestore

File-based SnapRestore is a more granular snapshot-based restoration process used with AFF volumes. Rather than reverting the state of an entire volume, the state of an individual file, LUN, or namespace is reverted. No snapshots need to be deleted, nor does this operation create any dependency on a prior snapshot. The file or LUN becomes immediately available in the active volume.

No data movement is required during a SnapRestore restore of a file or LUN. However, some internal metadata updates are required to reflect the fact that the underlying blocks in restored data now exist in both a snapshot and the active volume. There should be no effect on performance, but this process blocks the creation of snapshots until it is complete. The processing rate is approximately 5GBps (18TB/hour) based on the total size of the files restored.

ASA LUN/namespace restoration

Restoring data on ASA is similar to AFF SnapRestore. Data is simply restored to an earlier state. The process is nearly instantaneous and does not require data movement. It also has the same limitations, including the requirement that restoration of a snapshot results in deletion of subsequently deleted snapshots. If this is problematic, there are two options. First, a LUN/namespace can be cloned from an earlier snapshot while leaving the source volume unchanged. This is an instantaneous and space-efficienc process. It essentially makes a read-write copy of the read-only pointer to the blocks in a snapshot. A second option is via the REST API, which can use the same single-file SnapRestore logic used in AFF systems. The result is an instant restoration of a LUN/namespace using the data from a snapshot and all snapshots are preserved.