What to use SnapMirror for

SnapMirror can be useful to you in several scenarios.

You might want to copy or use the data stored on a SnapMirror destination. The additional advantages of SnapMirror make it useful in other data retrieval situations, as described in the following table.

Situation	How to use SnapMirror
Disaster recovery: You want to provide immediate access to data after a disaster has made a qtree, volume, or system unavailable.	You can make the destination writable so clients can use the same data that was on the source volume the last time data was copied.
Disaster recovery testing: You want to test the recovery of data and restoration of services in the event of a disaster.	You can use FlexClone technology on the SnapMirror destination, and test for disaster recovery, without stopping or pausing other replication operations.
Data restoration: You want to restore lost data on a qtree or volume source from its mirrored qtree or volume SnapMirror partner.	You can temporarily reverse the roles for the source and destination qtrees or volumes and copy the mirrored information back to its source.
Application testing: You want to use an application on a database, but you want to test it on a copy of the database in case the application damages the data.	You can make a copy of the database to be used in the application testing to ensure that the data on the source cannot be lost.
Load balancing: A large number of users need read-only access to a qtree or volume.	You can copy the data in a qtree or volume to multiple volumes or storage systems to distribute the load.
Off-loading tape backups: You need to reserve all processing and networking resources on a storage system for serving NFS and CIFS requests.	After copying data on the source system, you can back up the data in the destination to tape. This means that the source system does not have to allocate resources for performing backups.
Access to remote data: Users who need read access to a volume are distributed over a large geographical area.	You can copy the source volume to other storage systems that are geographically closer to the users. Users accessing a local system can read the data using less resource time than if they connected to a distant system.

Beginning with Data ONTAP 7.3, SnapMirror and SnapVault support the replication of NFS version 4 ACLs (access control lists). When replicating, the destination might not understand NFS version 4 ACLs.

If the destination can understand NFS version 4 ACLs, the ACL is replicated as is from the source to the destination. The access rules applied for the data on the destination is identical to the access rules on the source.
If the destination cannot understand NFS version 4 ACLs, a new ACL, that the destination can understand, is created. The access rules in this new ACL will be equivalent or stricter than the original ACL. This is done to avoid any security issues.
Note: This alternative also implies that a user might not be given access to a set of data on the destination, although the user has access to the same data on the source.

Parent topic: Overview of SnapMirror