Many times you wondered how to copy over an entire volume from one filer to the other or how you can have a DR site with the same content as the production one. Also the flowing procedure can be used for just regular backup. To find out how I use this on netapp, please read this post.
Snapmirror (SM) replicates a volume or qtree to a destination volume or qtree. This destination is usually another filer but can be the same filer. With the exception of permissions SM relationships are configured on the destination filer. SM utilizes snapshots to accomplish incremental updates to the destination without needing a complete retransmission of the source volume. You will see these snapshots in a snap list, they are named with a format similar to:
Configuring SM involves these steps:
- Configure access permissions.
- Configure SM relationship on the destination (manual and scheduled)
- Initialize (baseline) the replica on the destination.
- Update replicate on the destination (for manual updating)
- Optionally: Quiesce and Break relationship to enable writing on destination.
- Optionally: Resyncronize relationship after Breaking to continue updates.
- Optionally: Permanently destroy the relationship.
1 – Permissions:
Both Source(src) and Destination(dst) filers must have entries in the /etc/hosts files and each filer must have the other filer listed in the /etc/snapmirror.allow file.
2 – Configure relationship:
Relationships are configured in the /etc/snapmirror.conf file on the dst filer. Each line specifies a separate relationship. The format of the file is as follows.
For Manual Updates:
|filer1:/vol/vol_to_be_duplicated/data1 filer2:/vol/destination_volume/data1 – – – – –|
This example is from filer2 and it says replicate from filer filer1, the qtree /vol_to_be_duplicated/data1 to the filer filer2 into qtree /vol/destination_volume/data1 . The five hyphens mean no options and no schedule. This example requires a manual update command be issued whenever the replication should occur.
For Scheduled Updates:
|filer1:/ vol/vol_to_be_duplicated/data1 filer2:/vol/ destination_volume/data1 – 0-59/20 * * *|
This example is also from filer2 and it says replicate from filer filer1 the qtree / vol/vol_to_be_duplicated/data1 to the filer filer2 into qtree /vol/ destination_volume/data1 every 20 minutes.
The scheduling options are similar to cron use man snapmirror to read all the detailed options for snapmirror. The above are both examples of qtree replication.
Volume replication uses the following format:
|filer1:vol_to_be_duplicated filer2:destination_volume – – – – –|
This is an example of replicating the entire volume. It says replicate volume vol_to_be_duplicated on filer filer1 to the volume destination_volume on filer filer2. All scheduling options also apply to volume replication.
Volume replication requires that the destination volume exist and be equal or larger in size than the source. The destination volume must also be in restricted mode (filer>vol restrict <vol-name>). Volume level replication also replicates existing snapshots on the volume which is not the case with qtree replication.
3 – Initialize the replica
Initialization is accomplished using the snapmirror initialize command.
|filer>snapmirror initialize /vol/ destination_volume/data1|
This will copy over the network the entire src data to the dst filer. This is accomplished by taking a snapshot on the src just after the above command is executed. This snapshot is then used for the src of the transfer. This transfer may take a long time. You can monitor it with the command: filer>snapmirror status
4 – Incrementally update replica
Once the initialization completes the snapshots will be marked with (busy, snapmirror) tag in snap list. This indicates the snapshot is tied to an initialized snapmirror relationship. These snaps can begin to take up space just as normal ones do. Thus once a relationship is setup it must be updated somewhat regularly or it the snaps will become problematic in terms of disk utilization. Updating the destination is done using the command:
|filer>snapmirror update /vol/ destination_volume/data1|
Another snapshot is taken after the update is run and the block differences between the new snapshot and the previous one are sent over the network. You can also monitor this progress with snapmirror status command. It normally would complete much faster than the original update (unless every block has changed in the volume).
5 – Enable writing to destination
Snapmirror destinations are read-only while in an initialized state. In order to use the destination volume in a read-write fashion it must be broken. This is accomplished in a two-step process.
|filer>snapmirror quiesce /vol/ destination_volume/data1
filer>snapmirror break /vol/ destination_volume/data1
The destination volume is now read write.
6 – Resynchronize relationship
When the relationship is broken the snapshots used in the relationship are released from their locked state but are not discarded. As long as these snapshots remain on the volume it is possible to resynchronize the relationship and continue updates. This is accomplished using the snapmirror resync command
|filer>snapmirror resync /vol/ destination_volume/data1|
7 – Destroy the relationship for good.
Once you are sure you will no longer be using the relationship for updates it can be removed. (for example to do a one time copy). First do step 5 which releases the snapmirror snapshots. Then delete the snapshots as detailed in the Snapshot section on both the src and dst filers. Finally remove the line in the /etc/snapmirror.conf file on the dst filer.