Renaming a SnapMirror volume that is the source for SnapVault relationships can be tricky. If not done correctly, you can lose the base snapshot for the SnapVault relationships and be forced to re-baseline your SnapVaults. To make matters worse, if its managed my Protection Manager you have to ensure that the server learns of the change and behaves correctly. The following procedure can be used to safely rename a SnapMirror volume that is part of a "Mirror, then Backup" protection policy. No re-baseline of the SnapMirror or SnapVault is required.
Description
How do I rename a SnapMirror volume that has SnapVault relationships using it as the source?
How do I rename a SnapMirror volume in a “Mirror, then Backup” relationship in Protection Manager?
Procedure
For this example:
FILER_A is the source controller,
FILER_B is the SnapMirror destination controller, and
FILER_C is the SnapVault destination controller.
FILER_A:primary_vol is the source volume.
FILER_B:old_mirror_vol is the SnapMirror destination volume.
FILER_C:backup_vol_01 is the SnapVault destination volume.
The current SnapMirror destination volume – old_mirror_vol - is going to be renamed to new_mirror_vol.

- In Protection Manager, suspend the dataset which uses the SnapMirror destination volume as a resource. We don’t want SnapMirror or SnapVault updates attempting to run on the volumes while we’re performing these steps.
- Perform a 'snapmirror status' on FILER_B:old_mirror_vol. Document the name of the source controller and path.
- Perform a manual snapmirror update on FILER_B:old_mirror_vol to make sure its up-to-date.
FILER_B> snapmirror update –S FILER_A:primary_vol FILER_B:old_mirror_vol
- On FILER_C perform a 'snapvault update' on all the SV relationships originating from FILER_B:old_mirror_vol.
Filer_C> snapvault update FILER_C:/vol/backup_vol_01/primary_vol_-
Filer_C> snapvault update FILER_C:/vol/backup_vol_01/primary_vol_qtree1
Filer_C> snapvault update FILER_C:/vol/backup_vol_01/primary_vol_qtree2
Filer_C> snapvault update FILER_C:/vol/backup_vol_01/primary_vol_qtree3
NOTE: Naming properties are user-customizable in Protection Manager. As a result, your SnapVault paths may look different from the ones shown above.
- On Filer_B perform a snap list on old_mirror_vol. Verify that the volume has snapshots for the purposes of SnapMirror and SnapVault. Note that the snapshots contain the current name of the volume.
FILER_B> snap list old_mirror_vol
Volume old_mirror_vol
working...
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) May 01 15:55 FILER_B(4027617062)_old_mirror_vol.4 (snapvault)
0% ( 0%) 0% ( 0%) May 01 15:55 2013-05-01_1556-0500_daily
0% ( 0%) 0% ( 0%) May 01 15:48 FILER_B(4027617062)_old_mirror_vol.3
0% ( 0%) 0% ( 0%) May 01 15:22 2013-05-01_1523-0500_daily
0% ( 0%) 0% ( 0%) May 01 14:57 2013-05-01_1458-0500_daily
0% ( 0%) 0% ( 0%) May 01 14:03 2013-05-01_1404-0500_daily
- On Filer_B rename the SnapMirror volume.
Filer_B> vol rename old_mirror_vol new_mirror_vol
old_mirror_vol renamed to new_mirror_vol
- On Filer_B verify the status of the SnapMirror relationship for the newly renamed volume. The source should now be shown as a dash.
Filer_B> snapmirror status new_mirror_vol
Snapmirror is on.
Source Destination State Lag Status
- FILER_B:new_mirror_vol Snapmirrored 00:13:20 Idle
- On Filer_B update the SnapMirror relationship to point to the correct source volume. This allows the status registry to be updated with the new volume name.
Filer_B> snapmirror update –S FILER_A:primary_vol FILER_B:new_mirror_vol
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
- If the 'snapmirror update' does not work, use 'snapmirror break' and 'snapmirror resync' to resync the data between the source and destination.
Filer_B> snapmirror break new_mirror_vol
snapmirror break: Destination new_mirror_vol is now writable.
Filer_B> snapmirror resync -S FILER_A:primary_vol FILER_B:new_mirror_vol
- On Filer_B monitor the progress with 'snapmirror status' or by viewing the SnapMirror log. Wait for the snapmirror relationship staus to become idle.
- On Filer_C perform a 'snapvault status'. For each relationship that was using the old volume name as the source of the relationship (FILER_B:/vol/old_mirror_vol), update that relationship to point to the new volume name (FILER_B:/vol/new_mirror_vol). The qtree names should all remain the same.
NOTE: If any of the 'snapvault start' commands return an error of “Transfer aborted: destination is temporarily quiesced” just wait for the snapvault relationships to finish quiescing and then re-run that particular command.
Filer_C> snapvault start –r –S FILER_B:/vol/new_mirror_vol/- FILER_C:/vol/backup_vol_01/primary_vol_-
Filer_C> snapvault start –r –S FILER_B:/vol/new_mirror_vol/qtree1 FILER_C:/vol/backup_vol_01/primary_vol_qtree1
Filer_C> snapvault start –r –S FILER_B:/vol/new_mirror_vol/qtree2 FILER_C:/vol/backup_vol_01/primary_vol_qtree2
Filer_C> snapvault start –r –S FILER_B:/vol/new_mirror_vol/qtree3 FILER_C:/vol/backup_vol_01/primary_vol_qtree3
NOTE: Naming properties are user-customizable in Protection Manager. As a result, your SnapVault paths may look different from the ones shown above.
- On Filer_C perform a 'snapvault status'. Verify that all of the SnapVault relationships that were referencing the old source volume name now reference the new source volume name.
Filer_C> snapvault status
Snapvault is ON.
Source Destination State Lag Status
FILER_B:/vol/new_mirror_vol/- FILER_C:/vol/backup_vol_01/primary_vol_- Snapvaulted 0:04:08 Idle
FILER_B:/vol/new_mirror_vol/qtree1 FILER_C:/vol/backup_vol_01/primary_vol_qtree1 Snapvaulted 0:04:08 Idle
FILER_B:/vol/new_mirror_vol/qtree2 FILER_C:/vol/backup_vol_01/primary_vol_qtree1 Snapvaulted 0:04:08 Idle
FILER_B:/vol/new_mirror_vol/qtree3 FILER_C:/vol/backup_vol_01/primary_vol_qtree1 Snapvaulted 0:04:08 Idle
- On Filer_B, manually update the SnapMirror relationship for the newly renamed volume. Do NOT skip this step! This step is what tells the primary volume that a different base snapshot is being used for the SnapVault relationships.
Filer_B> snapmirror update –S FILER_A:primary_vol FILER_B:new_mirror_vol
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
- On Filer_A, do a 'snap list' on the primary volume. Verify that new snapshots exist with the new volume name (new_mirror_vol), and that they are the source of the SnapMirror and SnapVault relationships. Note that the old snapshots used for SnapMirror and SnapVault still exist.
Filer_A> snap list primary_vol
working...
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) May 01 16:28 FILER_B(4027617062)_new_mirror_vol.3 (snapmirror)
0% ( 0%) 0% ( 0%) May 01 16:15 FILER_B(4027617062)_new_mirror_vol.2 (snapvault)
0% ( 0%) 0% ( 0%) May 01 15:55 FILER_B(4027617062)_old_mirror_vol.4 (snapmirror)
0% ( 0%) 0% ( 0%) May 01 15:55 2013-05-01_1556-0500_daily
0% ( 0%) 0% ( 0%) May 01 15:48 FILER_B(4027617062)_old_mirror_vol.3 (snapvault)
0% ( 0%) 0% ( 0%) May 01 15:22 2013-05-01_1523-0500_daily
1% ( 0%) 0% ( 0%) May 01 14:57 2013-05-01_1458-0500_daily
1% ( 0%) 0% ( 0%) May 01 14:03 2013-05-01_1404-0500_daily
- On Filer_A run a snapmirror destinations command. Find the old and new destination entries.
Filer_A> snapmirror destinations
Path Destination
primary_vol Filer_B:old_mirror_vol
primary_vol Filer_B:new_mirror_vol
- On Filer_A run a 'snapmirror release' command on the OLD destination entry. This releases any soft locks on snapshots that we no longer need on the primary volume.
Filer_A> snapmirror release primary_vol Filer_B:old_mirror_vol
- On Filer_A run a 'snap list' on the primary volume to verify the old SnapMirror and SnapVault snapshots have been released.
Filer_A> snap list primary_vol
working...
%/used %/total date name
---------- ---------- ------------ --------
0% ( 0%) 0% ( 0%) May 01 16:28 FILER_B(4027617062)_new_mirror_vol.3 (snapmirror)
0% ( 0%) 0% ( 0%) May 01 16:15 FILER_B(4027617062)_new_mirror_vol.2 (snapvault)
0% ( 0%) 0% ( 0%) May 01 15:55 2013-05-01_1556-0500_daily
0% ( 0%) 0% ( 0%) May 01 15:22 2013-05-01_1523-0500_daily
0% ( 0%) 0% ( 0%) May 01 14:57 2013-05-01_1458-0500_daily
1% ( 0%) 0% ( 0%) May 01 14:03 2013-05-01_1404-0500_daily
- On Filer_B perform a manual update of the updated SnapMirror relationship.
Filer_B> snapmirror update –S FILER_A:primary_vol FILER_B:new_mirror_vol
- On FILER_C perform a 'snapvault update' on all the SV relationships originating from FILER_B:new_mirror_vol.
- Update the Protection Manager (a.k.a. DFM or OnCommand Unified Manager) server to make it aware of all the changes that have occurred on each controller. This step will update the dataset in Protection Manager to reflect the new volume name and all the updated SnapMirror and SnapVault relationships.
NOTE: BE PATIENT!!! This process can take a long time (10-15 minutes) depending on how large your environment is and how fast your DFM server is running. Go to the restroom and grab another cup of coffee…
DFM_SVR C:\> dfm host list
ID Type Host Name Host Address ProductId Deleted
--- --------------- -------------- ---------------------- ------------ --------
130 Controller Filer_A 192.168.172.71 4027616951 No
131 Controller Filer_B 192.168.172.72 4027617062 No
132 Controller Filer_C 192.168.172.72 4027617062 No
In the output, find the ID number (first column) for Filer_A, Filer_B and Filer_C. Using the ID numbers instruct the DFM server to force a polling update on all three controllers.
DFM_SVR C:\> dfm host discover 130
Refreshing data from host Filer_A (130) now.
DFM_SVR C:\> dfm host discover 131
Refreshing data from host Filer_B (131) now.
DFM_SVR C:\> dfm host discover 132
Refreshing data from host Filer_C (132) now.
- On the DFM server, query the Protection Manager dataset which uses the renamed volume and relationships to see if it’s been updated with the correct information. Keep querying the dataset until you see every single volume AND relationship update with the correct information. You can do this through the GUI or CLI interface.
NOTE: Updating the dataset can take 10-15 minutes after you re-discovered the hosts, so be patient! If after 20 minutes you have not seen everything update correctly, repeat the dfm host discover command on all three controllers, wait another 10-15 minutes and repeat this step. Do not proceed until the dataset reflects the correct information.
DFM_SVR C:\> dfpm dataset list
DFM_SVR C:\> dfpm dataset list –R <dataset_ID_number>
- Once you’ve verified the dataset has been completely updated, resume (un-suspend) the dataset in Protection Manager. This will allow scheduled backups to occur using the newly renamed mirror volume.
- At this point you can either initiate an on-demand protection, or wait for the next scheduled backup of the dataset to occur.