Dataset Migration

Due to performance problems, I'm in the process of migrating on to a new install of DFM 4.0.2. I need to recreated this instance exactly the same as the old. So far I have been able to recreate all the groups and their members, resource pools, schedules, and policies, but when I get to the datasets there seems to be a big problem. I recreated the same dataset config on the new instanace (with the same members, resource pools and even the volume within the resource pool) and suspended it. Then, I suspended the dataset on the old instance and resumed it on the new. Well, I was hoping that the new instance would pickup where the old dataset left off, but instead it reinitialized it and laid down a new baseline transfer. This is not good. It seems that the datasets are tied to the dfm server on which they were created. How can I get past this? I can't export the relationships on the old then import them because when I do this in production I will have thousands of relationships to deal with. I need to be able to have the newly created datasets "take over" the control of the dataprotection from the old datasets seemlessly. I have not been able to find any info on how to do this. Thanks for the help.

In order to retire relationships (or to move relationships out of a dataset), administrators delete their datasets along with the dpReaperCleanupModer option set to Never. This is not a healthy

option. You need to follow these steps to retire a relationship gracefully from a dataset:

Relinquish the relationship – This will enable PM to mark the relationship as external

Use the dfpm reliniquish command

Remove the Primary Volume/Qtree from the dataset – Do not remove the secondary volume first as the conformance will trigger a new rebaseline. Remove the Secondary Volume from the dataset. Delete the dataset (if required)

Note: It is true that you can delete the dataset with dpreapercleanupmode set to “never” to avoid the deletion of relationships, but it needs to stay that way forever, if re-activated PM will try to

reap the relationships.

CONSEQUENCES OF DELETING A DATASET

One really needs to consider the possible consequences of deleting a dataset, as the operation cannot be undone. Deleting a dataset not only affects the relationships (through

dpReaperCleanUp mode), but you will end up losing the backup versions. The backup versions are index of snapshots of members in a dataset. These backup versions are responsible for

restore operations and snapshot expiration based on retention time and retention count.If the backup versions are lost (due to the deletion of a dataset) then you will end up having

orphaned snapshots that cannot be restored through OnCommand Protection tool and will never be expired occupying huge amounts of space over time

So follow 5.12, dont delete the dataset on server 1. Add the controllers src and dst to server 2 and import the relationship in server 2 into a newly created dataset.

Regards

adai

7Replies

0
Likes

Re: Dataset Migration

It would be nice if we could put functionality into OC in the future to allow for toggling back and forth between identical datasets on different DFM instances. Now I have to deal with the relinquishing and importing of thousands of relationships into new datasets. This would not be a big deal in a small environment, but for large enterprises this is tedious.

--todd

7Replies

0
Likes

Re: Dataset Migration

I agree todd, BUT the dataset info is tied to a DFM server. And managing the same members from two dfm server will cause dueling effect.If you are bringing up a new instance, just importing the members from the external relationship into the dataset would be fine provided you scrap the older instance. But if you want both to exisit then you will have to do one of the two things.

1.Destory the dataset in older instance. or

2.Reliquish the relatinship and leave the dataset.

The 1st would reap the relationship within 2hours ,

where as the 2nd approach is better because it will mark the relationships as external and take care of deleting all the old snapshot as per the retention so that you dont lose any space on the filer.

Regards

adai

7Replies

0
Likes

Re: Dataset Migration

I followed these steps, but after I relinquished and removed the members of the relationships out of the old dataset and imported them into the new dataset, I can't see the old backup versions from the old dataset. I did not delete it:

Re: Dataset Migration

For old backup versions you should go to the old dataset. As a backup version is meta data attached to the dataset and not to the volumes of the dataset.The old dataset will take care of retiring or expiring the snapshots based on the retention settings.The "CONSEQUENCES OF DELETING A DATASET" explains this and that's why we recommend not to delete the old dataset.

You will have to retain the old dataset for all restores from previous backup version or until they expire. Or as always you can use the snapshot which still exist on the volume to restore them.

Regards

adai

7Replies

0
Likes

Highlighted

Re: Dataset Migration

I understand what you are saying but the problem that I'm having is that I can't access the snapshot data on the old dataset after I relinquish and move the members out. I have tested this twice and each time it appears that I can't access the old snapshots via DPM. In the following test I relinquished and removed 2 volumes and their destination volume from their dataset. I could see the old snapshots after I relinqished them, but after I removed them I can't see the old snapshots with the "dfpm dataset snapshot list" command. I guess I'm missing as to how, without getting on the filer itself, I can acceess the old snapshots via the NMC: