How to release a SnapVault relationship and make the secondary qtree writable

Symptoms
Secondary qtree is read-only and cannot be made writable Snapvault relationship is no longer needed but backup data should be kept in a writable version

Solution
SnapVault secondary (destination) qtrees are read-only copies of the source qtrees. Therefore, they cannot be written to unless the snapvault relationship is broken. However, if the snapvault stop command is used to end the SnapVault backups, the secondary qtree is deleted from the file system. This article provides the procedures for making SnapVault secondary qtree read/write for situations where the SnapVault primary qtree (the data source) has failed or is inaccessible for some reason and failover to the secondary qtree is required. Note: The workaround of simply doing a "snapvault restore" to an alternate location is also sufficient for many cases. Note: This procedure requires a snapmirror license. Procedure to release the SnapVault relationship and make the secondary qtree writable: This procedure will make the snapvault destination qtree writeable. At the end of this procedure, a resync will still be possible as no snapshots were deleted. Warning: Diag level commands are for use under the guidance of NetApp. Caution should be taken when using these commands."

On the secondary filer/NearStore: 1. Disable snapvault. dst_filer> options snapvault.enable off 2. If snapmirror is not already licensed on the secondary filer, add a snapmirror license. dst_filer> license add <license_key> 3. As snapmirror is automatically enabled when licensed, disable snapmirror. dst_filer> snapmirror off 4. Enter diag mode and convert the snapvault secondary qtree to a snapmirror qtree. dst_filer> priv set diag dst_filer> snapmirror convert <secondary_qtree_path> 5. Exit diag mode and enable both snapvault and snapmirror. dst_filer> priv set admin dst_filer> options snapvault.enable on dst_filer> snapmirror on 6. Quiesce and break the new snapmirror relationship you created with the snapmirror convert command in step 4. dst_filer> snapmirror quiesce <secondary_qtree_path> dst_filer> snapmirror break <secondary_qtree_path> 7. Verify the snapmirror relationship has been broken. Note the base snapshot for this relationship. dst_filer> snapmirror status -l

Procedure to resync the relationship and resume updates from the original SnapVault primary: The released SnapVault relationship can be resynchronized and changes made on the writable destination can be moved to the original primary location. The following procedure will resync the SnapVault and then allow regular updates from the original primary to the secondary filer to be resumed. NOTE: Due to the use of the snapmirror resync command, a resync of the original SnapVault relationship can only be performed on filer-to-filer SnapVault relationships. Open System SnapVault (OSSV) relationships cannot be resynchronized using this procedure.

On the primary filer, move the changed data from the writable destination to the original primary filer's

qtree: 1. 2.

3. 4.

Stop client access to the writable destination qtree. Resync the snapmirror from the destination filer to the primary filer. src_filer> snapmirror resync -S dst_filer:<secondary_qtree_path> src_filer:<primary_qtree_path> Quiesce the snapmirror once the update completes. src_filer> snapmirror quiesce <primary_qtree_path> Break the snapmirror. src_filer> snapmirror break <primary_qtree_path>

On the secondary filer, restore the original primary to secondary snapvault relationship: 1. Resync the SnapVault. dst_filer> snapvault start -r -S src_filer:<primary_qtree_path> dst_filer:<secondary_qtree_path> On the primary filer, clean up the broken-off snapmirror relationship from the resync: 1. Determine the base snapshot. src_filer> snapmirror status -l <primary_qtree_path> 2. Delete the base snapshot identified in step 1. src_filer> snap delete <src_vol> <base_snapshot_name>

Procedure to remove the base snapshots if a resync will not be needed: If the relationship is to be permanently broken and a resync of the relationship is not needed, then the base snapshots can be cleaned up. Note: After performing this procedure, SnapVault backups cannot be continued to the destination qtree without reinitializing the SnapVault relationship. This re-initialization will require a complete transfer of all the data.

On the secondary filer: 1. Delete the base snapshot for the broken snapmirror identified in step 7. dst_filer> snap delete <dst_vol> <base_snapshot_name> 2. Verify the snapmirror relationship has been removed from the filer. dst_filer> snapmirror status 3. If snapmirror was licensed and enabled specifically for this procedure, disable snapmirror and remove the license. dst_filer> snapmirror off dst_filer> license delete SNAPMIRROR On the primary filer: 1. Release the snapvault qtree that was made writable on the destination. src_filer> snapvault release <primary_qtree_path> dst_filer:<secondary_qtree_path> 2. Verify the relationship has been removed. src_filer> snapvault status

NOTE: Snapmirror break can be long to complete and during this time that the break is occurring the CLI will not respond. Using RSH to check the snapmirror status on the filer during this period will show the relationship in a quiesced state, and it will not show as broken until the 'snapmirror break' command completes.