2017-05-09 08:40 AM
We are using two HA pairs running 8.2.4P5 7-mode.
The current disk space is becoming sparse and 2 shelves of 8Tb disks have been added to the system to cope with the snapvault destinations.
The current setup is managed through DFM 5.2.0.
We added the storage config for 8.2.4 in the dfm.
What we are trying to do is to move the current snapvault destination from an aggregate to another one.
A snapmirror has been performed to recreate the snapvault destination, after the initial transfer the snapmirror relation has been broken-off.
The new destination has been defined as secondary volume within dfm
We then associated the existing primary volume to the new secondary volume.
This operation completes, with a message
"Importing backup relationship between secondary FILER2:/Vault_1 and primary FILER1:/vol1/Qtree1"
We then associate the same schedule as the existing snapvault relation
The issue is that the new snapvault relation doesn't update and the lag keeps increasing.
When trying to manualy perform an update of the relation, i got the following error message
"Could not configure ip_address_of_filer_1as defined in options ndmp.prefered_interface as the transfer interface for filer1:/vol1/qtree1: NDMP communication error: NDMP_SVS_MODIFY_RELATIONSHIP: 0x20500306 (SV NO RELATIONSHIP)"
When performing a simple snapvault update on the destination filer, the snapvault relation comes back to an updated state but as the snapshots are created by dfm, this is not a solution.
Any idea why this is happening ?
PS : I also tried to recreate the relation to a brand new volume, and in this case the dfm can update the relation without problem.
Solved! SEE THE SOLUTION
2017-05-09 07:18 PM
2017-05-10 01:46 AM
I just tested this.
I did the snapvault update through dfm/um and the status of the job is failed, BUT the snapvault relation is transfering.
Will wait for the scheduled transfer to check the job status
So far so good anyway