The filer's SnapRestoreTM feature enables you to revert a volume to the state it was in when a particular snapshot was taken. Without this feature, you would need to use one of the following methods to restore data to a volume:
Using either of these methods takes a longer time than reverting the volume. This is because with SnapRestore, no data needs to be copied; the file system is just put back in its earlier state.
SnapRestore is a licensed feature. You must purchase and install the license code before you can use it.
After you select a snapshot for reversion, the filer reboots with the volume containing the same data and timestamps as it did when the snapshot was taken. All data that exists before you initiate the reversion is overwritten.
Caution: You cannot undo the reversion to change the volume back to the state it was in before the reversion.
SnapRestore reverts only the file contents. It does not revert attributes of a volume. For example, the snapshot schedule, volume option settings, RAID group size, and maximum number of files remain unchanged after the reversion.
Option settings applicable to the entire filer, however, might be reverted. This is because the option settings are stored in a registry in the /etc directory. If you revert the root directory, the registry is reverted to the version that was in use at the snapshot creation time. For more information about how reverting a root volume works, refer to "Effects of reverting a root volume."
You can revert a volume to a snapshot taken when the filer was running a different Data ONTAP version.
You cannot revert a volume to recover a deleted snapshot. For example, if you delete the hourly.2 snapshot and revert the volume to the hourly.1 snapshot, you cannot find the hourly.2 snapshot after the reversion. Although the hourly.2 snapshot existed at the creation time of the hourly.1 snapshot, SnapRestore cannot revert the contents of the hourly.2 snapshot because you already deleted it.
After you revert a volume to a particular snapshot, you lose the snapshots that are more recent than the snapshot used for the volume reversion. For example, after you revert the volume to the hourly.1 snapshot, you no longer have access to more recent snapshots, such as the hourly.0 snapshot. This is because at the creation time of the hourly.1 snapshot, the hourly.0 snapshot did not exist.
If a client application corrupts data files in a volume, you can revert the volume to a snapshot taken before the data corruption. The following examples illustrate some situations in which you can apply SnapRestore to recover from corrupted data.
A messaging application or a database application stores user data in one or two files that can grow to several hundred GB in a volume. If, for some reason, this application corrupts the files, you can revert the volume to a snapshot taken before the data corruption.
You can revert a volume used as a test environment to its original state after each test.
This section describes two considerations you must make before deciding whether you should use SnapRestore to revert a volume.
If the amount of corrupted data is small, it is easier to copy the files from a snapshot or restore the files from tape than to use SnapRestore for these reasons:
If the amount of data to be recovered is large, it takes a long time to copy the files from a snapshot or to restore from tape. In this case, SnapRestore is the preferred method for recovering from data corruption.
If a file to be recovered needs more space than the amount of free space in the active file system, you cannot copy the file from the snapshot to the active file system. For example, if a 10-GB file is corrupted and only 5 GB of free space exists in the active file system, you cannot copy the file from a snapshot to recover the file. In this case, SnapRestore can quickly recover the file; you do not have to spend time making the additional space available in the active file system.
The following list describes how SnapRestore and SnapMirror interact with each other:
For example, vol1 is the source volume for data replication and it contains two snapshots: hourly.0 and filerA_vol1.2. If hourly.0 was taken earlier than filerA_vol1.2 and you revert vol1 to hourly.0, you cannot find filerA_vol1.2 after the reversion. As a result, the filer cannot start an incremental update of the mirror. It must re-create the baseline version of the mirror.
Because the /etc directory of the root volume contains configuration information about the filer, reverting the root volume might change the filer configuration. The following list describes the effects of reverting the root volume:
Avoid reverting the configuration files. To avoid reverting the configuration files, follow one of these steps:
If you back up the /etc directory to another volume, you can use the vol options volume root command to make the filer reboot with that volume as the root volume. In this way, when the filer reboots during the reversion, it can use the correct settings in the /etc directory.
Because all files in a reverted volume have timestamps that are the same as those when the snapshot was created, the filer's dump and restore commands might be affected. Incremental backup and restore operations can no longer rely on the timestamps to determine what data needs to be backed up or restored.
After you revert a volume, perform a level-0 backup of the volume. After the level-0 backup is finished, the filer can perform subsequent incremental backups correctly. Also, if you need to restore data from tape to this volume, use only the backups created after the volume reversion.
Copyright © 1999, Network Appliance, Inc. All rights reserved.
Part No. 210-02166
File: disk9.htm
Last updated: 02/24/99 15:46:00