topic Re: Protection Manager behavior for full SV destination aggregates in Active IQ Unified Manager Discussions

Protection Manager behavior for full SV destination aggregates

christop — Thu, 05 Jun 2025 07:16:55 GMT

When a snapvault destination aggregate fills up and it is part of a resource pool managing by Protection Manager 3.7, does PM automatically migrate volumes to another aggregate and preserve the relationships?

Re: Protection Manager behavior for full SV destination aggregates

adaikkap — Thu, 18 Mar 2010 15:35:38 GMT

Yes, it will create a new relationship between the primary volume and the new secondary volume to be provisioned.

But this will be a baseline transfer from the primary volume to new secondary volume.

The old volume and its snapshots (Backups version) will be preserved and will expire as per the retention of the policy.

Why don’t you try to use the Secondary Space Management feature of Protection Manager 4.0.

This will migrate the existing secondary volume to whichever aggr you wish and at the same time the base line is from the old secondary and not for the primary.

Also old backup versions are transferred to the new volume in this process, so you don’t need to have two volumes.

Regards

adai

Re: Protection Manager behavior for full SV destination aggregates

smoot — Fri, 19 Mar 2010 05:42:34 GMT

In the newly released 4.0 code, the behavior is different. ProtMgr will not automatically create new secondary volumes, but instead has a secondary space management wizard to help you plan and execute moving volumes among secondary aggregates. This should reduce load on the primary storage system and avoid creating a second full copy of your data.

This would be an excellent excuse to upgrade from 3.7 :-).

Re: Protection Manager behavior for full SV destination aggregates

christop — Fri, 19 Mar 2010 15:36:29 GMT

Adai/Pete:

Thanks for the heads up on the secondary space management feature in 4.0. I was not aware of that and it is reason enough for us to push toward 4.0. We'll get to 3.8.1 next week and plan to move to 4.0 in the coming months.

Since PM create a new baseline copy when a new secondary volume is created, I think we have some cleanup to do to determine if we want to keep both volumes for those that have been migrated. I think we have cases where 3-4 secondary volumes may exist for a single primary, so I will take a look.

A somewhat related question - how would I go about migrating a snapvault secondary volume with volume snapmirror if the snapvault relationship is managed by protection manager? Would I use the CLI to do the migration and somehow import the new SV relationship into PM? Would it be a combination of PM and CLI somehow? Or is it even an option with pre-4.0 versions of PM? The process I was planning on using to VSM migration the SV destination volume is located here: http://now.netapp.com/NOW/knowledge/docs/ossv/rel25/html/software/install/manage9.htm

Thanks!

Chris

Re: Protection Manager behavior for full SV destination aggregates

adaikkap — Fri, 19 Mar 2010 15:43:08 GMT

Hi,

When you migrate using SnapMirror, and import we will not be able to show the backup version in PM.

Inspite of the snapshots being in the volume.

Regards

adai

Re: Protection Manager behavior for full SV destination aggregates

christop — Fri, 19 Mar 2010 16:02:21 GMT

Thanks for the quick reply. Just so I'm clear - with PM pre-4.0 if we migrate a SV destination volume with VSM, it cannot be imported to PM. So the only option is to have PM create a new snapvault destination, have PM preserve the old volume, and then rebaseline the SV relationship from the primary volume.

Re: Protection Manager behavior for full SV destination aggregates

adaikkap — Sat, 20 Mar 2010 01:37:42 GMT

Just so I'm clear - with PM pre-4.0 if we migrate a SV destination volume with VSM, it cannot be imported to PM.

No.It can be imported but you will loose your older backup version info, though further new backups will continue.

But still can restore from the snapshots directly, but not using PM oNMC

So the only option is to have PM create a new snapvault destination, have PM preserve the old volume, and then rebaseline the SV relationship from the primary volume.

In this way your backup version info are preserved, but you will use twice the amount of storage.

You will be able to restore from PM/NMC and there is no need to go to the filer snapshots.

Also this will put a load on your primary server as baseline copy is from the primary.

Also if primary and secondary are geographically seperated and the pipe is small its going to take a long time.

With 4.0 we take care of the following.

baseline from the secondary,

Backup version info are preserved,

give you an opitons as to when to delete the old volume.

also allow updates from the primary to secondary during the entire duration of baseline copy,

so you don't miss even a single backup that is part of the schedule.

Ops-Mgr volume history is also copied over and preserved as part of the migration.

Gives you control of choosing the aggr in your resource pool.

Regards

adai