Starting DFM 4.0 we stopped rebaseline from primary if the destination/secondary volume is out of space or out of inodes.
The only way forward is the migrate the destination volume using Secondary Space Management, which uses VSM to copy the data from old volume to new volume.
Since Ontap does not support VSM between 32bit and 64 bit Aggr SSM throws error that the dst aggr is not suitable for migration.
But SV, QSM and NDMPCopy support copying data between 32 and 64 bit aggr. So re-baseline from primary is the way.
- The only way forward is the remove the 32bit RP from the dataset node.
- Then set the following options.
- Then remove the secondary volume from the dataset.
- Add the RP containing the 64bit Aggr to the dataset secondary node.
This will do a rebaseline from primary to the new volume created in the 64 bit aggr, using SV or QSM as per the protection policy.
The reaper process will cleanup the relationship within 2 to 3 hours.So the new updates dont go to the old volume, but those backup version registered with the dataset are available for restore.
The advantage is if you need a logner retention then you might be limited by the 255 snapshots and using SSM will not help as that copys the entire volume so the same procedure is required.
Another way is to instead of step 3 do the below.
Remove the primary from the old dataset.
Create a new dataset.
Add it to the new dataset.
Add the 64bit RP to the destination node of the dataset.
By this way you will achieve the same.
But you will have to retain the old dataset so that the backup version expire on the old secondary volume.( This will help because once all backup version expire you know which secondary volume to delete.)
But if you go with the first approach you will have to make note of all the destination volume names.
Another down fall of this approach is conformance will unnecessarily run on the first dataset( we increase the nubmer of dataset count and impact the performance if there a more number of dataset.)
Regards
adai
