| Index | Top - Up | Data ONTAP 8.3 |
Restore a Snapshot copy from a source volume to a destination volume
Availability: This command is available to cluster and Vserver administrators at the admin privilege level.
The snapmirror restore command restores the entire contents of a Snapshot copy or one or more files or LUNs of a Snapshot copy from one volume to another volume.
The source of the restore can be a volume that is:
The following volumes cannot be used as either the source nor destination volume of a restore:
A SnapMirror relationship of type RST is created from the source volume to the destination volume by the snapmirror restore command. This relationship lasts for the duration of the restore operation and is deleted when the command completes successfully.
The following paragraphs describe the behavior when restoring the entire contents of a Snapshot copy to a destination volume.
By default the snapmirror restore will copy the latest Snapshot copy from the source volume to the destination volume. A specific Snapshot copy can be selected with the -source-snapshot parameter.
Any quota rules defined for the destination volume are deactivated prior to restoring the entire contents of a Snapshot copy. Run the command volume quota modify -vserver destination-volume-vserver -volume destination-volume-name -state on to reactivate quota rules after the entire contents of the Snapshot copy have been restored.
If the destination volume is an empty data protection volume, the snapmirror restore command performs a baseline restore. For a baseline restore the following steps are performed:
If the destination volume is a read-write volume, an incremental restore is performed. The incremental restore fails if it cannot find a common Snapshot copy between the source and destination volumes. Restoring a Snapshot copy to an empty read-write volume is not supported.
An incremental restore preserves all Snapshot copies on the destination volume but does not preserve changes to the active file system since the latest Snapshot copy. To preserve changes to the destination volume since the latest Snapshot copy use the volume snapshot create command. Restore is a disruptive operation so client access of the destination volume is not advised for the duration of the operation.
For an incremental restore the following steps are performed:
If snapmirror restore fails or is aborted, the RST relationship remains. Use the snapmirror show command with the destination volume name to display the reason for the error. An EMS is also generated when a failure occurs. There are two options to recover when restore fails or is aborted:
When specifying -clean-up-failure to cancel an incremental restore request, the following steps are performed:
When specifying -clean-up-failure to cancel a baseline restore request, the following steps are performed:
The following paragraphs describe the behavior and requirements when restoring one or more files or LUNs to the destination volume.
The destination volume must be a read-write volume. Restoring files or LUNs to a data protection volume is not supported. When restoring files or LUNs the source and destination volumes are not required to have a common Snapshot copy. If a common Snapshot copy exists, an incremental restore is performed for those files or LUNs being restored which exist in the common Snapshot copy.
The contents of the files or LUNs to which data is being restored on the destination volume are not preserved by this command. To preserve the contents of the destination files or LUNs, create a Snapshot copy on the destination volume prior to running this command. Client I/O is not allowed to a file or LUN to which data is being restored on the destination volume.
The -source-snapshot parameter is required when restoring files or LUNs. It identifies the Snapshot copy on the source volume from which the files or LUNs to be restored are copied. If all files or LUNs to be restored do not exist in this Snapshot copy the command fails.
The source path for each file or LUN being restored is required. The source path of a file or LUN is from the root of the source Snapshot copy of the source volume. The file is restored to the same path on the destination volume unless an optional destination path is specified. The destination path is from the root of the destination volume. If a file or LUN to which data is being restored on the destination volume does not exist, the file or LUN is created. If any directory in the path of the file or LUN being restored does not exist on the destination volume, the command fails. Overwriting the contents of an existing file with the contents of a different file or overwriting the contents of an existing LUN with the contents of a different LUN is supported. Overwriting a file with a LUN or a LUN with a file is not supported. Client I/O is not allowed to all files and LUNs to which data is being restored on the destination volume.
If quota rules have been defined for the destination volume, resource usage is updated during file restore, but limits of quota rules are not enforced. Therefore, resource limits might be exceeded during a file restore.
Multiple concurrent snapmirror restore commands, restoring one or more files or LUNs to the same destination volume, are not supported. The destination volume of a snapmirror restore to which one or more file or LUNs are being restored, can simultaneously be the source volume of a snapmirror update.
For a file or LUN restore the following steps are performed:
Since client I/O is not allowed to files or LUNs being restored, client I/O to files or LUNs being restored should be quiesced. Mapped LUNs remain mapped throughout the operation. SAN clients do not need to rediscover a mapped LUN that has been restored.
If snapmirror restore fails or is aborted, the RST relationship remains. Use the snapmirror show command with the destination volume to display the reason for the error. An EMS is also generated when a failure occurs. There are two options to recover when restore fails or is aborted:
When specifying -clean-up-failure to cancel a file restore request, the following steps are performed:
The snapmirror restore command must be used from the destination Vserver or cluster.
{ [-source-path | -S {<[vserver:]volume>|<[[cluster:]//vserver/]volume>}] - Source Path
| [-source-cluster <Cluster name>] - Source Cluster
[-source-vserver <vserver name>] - Source Vserver
[-source-volume <volume name>] } - Source Volume
{ -destination-path {<[vserver:]volume>|<[[cluster:]//vserver/]volume>} - Destination Path
| [-destination-cluster <Cluster name>] - Destination Cluster
-destination-vserver <vserver name> - Destination Vserver
-destination-volume <volume name> } - Destination Volume
[-source-snapshot | -s <text>] - Source Snapshot
[-throttle | -k <throttleType>] - Throttle (KB/sec)
[-transfer-priority {low|normal}] - Transfer Priority
[-disable-storage-efficiency [true]] - Disable Storage Efficient Transfer
[-clean-up-failure [true]] - Clean up after Failure
[-tries <unsigned32_or_unlimited>] - Tries Limit
[-force | -f [true]] - Force
[-file-list <<source path>[,@<destination path>]>, ...] - File List
/dira/file1
/dira/file1,@/dirb/file2
/dira/file1,@/dirb/file2,/dirc/file3
[-use-network-compression [true]] - Use Network Compression
The following example does an incremental restore between the restore source volume vs2.example.com:dept_eng_dp_mirror2 and the restore destination volume vs1.example.com:dept_eng:
vs1.example.com::> snapmirror restore
-destination-path vs1.example.com:dept_eng
-source-path vs2.example.com:dept_eng_dp_mirror2
-source-snapshot snap3
Warning: All data newer than Snapshot copy snap6 on volume
vs1.example.com:dept_eng will be deleted.
Do you want to continue? {y|n}: y
[Job 34] Job is queued: snapmirror restore from source
vs2.example.com:dept_eng_dp_mirror2 for the snapshot snap3.
vs1.example.com::>
The following example restores /file3 from the source Snapshot copy snap3 on the source volume vs2.example.com:dept_eng_dp_mirror2 to the active file system of the restore destination volume vs1.example.com:dept_eng:
vs1.example.com::> snapmirror restore
-destination-path vs1.example.com:dept_eng
-source-path vs2.example.com:dept_eng_dp_mirror2
-source-snapshot snap3
-file-list /file3
Warning: This command will overwrite any file on destination
"vs1.example.com:dept_eng" that has the same path as any of
the files to be restored.
Do you want to continue? {y|n}: y
[Job 35] Job is queued: snapmirror restore from source
"vs2.example.com:dept_eng_dp_mirror2" for the snapshot snap3.
vs1.example.com::>
The following example restores /file3 from the source Snapshot copy snap3 on the source volume vs2.example.com:dept_eng_dp_mirror2 to /file3.new in the active file system of the restore destination volume vs1.example.com:dept_eng:
vs1.example.com::> snapmirror restore
-destination-path vs1.example.com:dept_eng
-source-path vs2.example.com:dept_eng_dp_mirror2
-source-snapshot snap3
-file-list /file3,@/file3.new
Warning: This command will overwrite any file on destination
"vs1.example.com:dept_eng" that has the same path as any of
the files to be restored.
Do you want to continue? {y|n}: y
[Job 36] Job is queued: snapmirror restore from source
"vs2.example.com:dept_eng_dp_mirror2" for the snapshot snap3.
vs1.example.com::>
The following example restores /file1, /file2, and /file3 from the source Snapshot copy snap3 on the source volume vs2.example.com:dept_eng_dp_mirror2 respectively to /file1.new, /file2, and /file3.new in the active file system of the restore destination volume vs1.example.com:dept_eng:
vs1.example.com::> snapmirror restore
-destination-path vs1.example.com:dept_eng
-source-path vs2.example.com:dept_eng_dp_mirror2
-source-snapshot snap3
-file-list /file1,@/file1.new,/file2,/file3,@/file3.new
Warning: This command will overwrite any file on destination
"vs1.example.com:dept_eng" that has the same path as any of
the files to be restored.
Do you want to continue? {y|n}: y
[Job 36] Job is queued: snapmirror restore from source
"vs2.example.com:dept_eng_dp_mirror2" for the snapshot snap3.
vs1.example.com::>
| Index | Top - Up | Data ONTAP 8.3 |
Copyright © 1994-2015 NetApp, Inc. Legal Information