Subscribe

Restore volume from snapshot to different location

Here's the scenario:

Primary filers are going to be rebuilt.  Upgraded to ONTAP 8.1 and rebuild the aggrs from RG 15 32 bit to RG 18 64 bit. 

Planning on backing up data then wipe and rebuild the primaries.  Then, using Protection Mgr restore the volumes from latest backups.  After doing all that we want these new primaries to function like the old primaries and fit back into the protection policies managed by Protection Mgr.

In testing this the process works up to the point the first scheduled backup runs and we get the error "base snapshot for transfer no longer exists on the source".  This happens even after running a resync.

Primary concern is the backups we have (weeklies, monthlies, and annuals).  Can't lose these.

Version of ONTAP we're testing with is 7.3.6.

We plan on upgrading to 8.1, run on that for several weeks and then do the aggr conversion.  Maybe this is all fixed in 8.1????

Re: Restore volume from snapshot to different location

Hi,

Do you mean that you will be doing migration from 32 bit to 64 bit aggrs(i.e. from secondary to primary)? Am not sure if creating such relationship through PM is possible. Please check out this thread:

https://communities.netapp.com/message/68770#68770

Also you may want to check out TR http://media.netapp.com/documents/tr-3978.pdf for best practices for aggr conversion from 32 bit to 64 bit.

Thanks,

-Amir

Re: Restore volume from snapshot to different location

Scenario is:

Upgrade to 8.1 (all filers at 32 bit)

Migrate to 64 bit aggrs on secondary

Run backups (primary to secondary)

Wipe primary, rebuild aggrs as 64 bit

Restore data to primary

Reintegrate restored volumes back into protection policies without losing past backups

Tried to read the first thread but not able to access.  Kept telling me to login but was already logged in and further attempts to login again resulted in page error.

Second article was helpful.

Re: Restore volume from snapshot to different location

Hi Scott,

     We would like to first understand your environment/situation.

Do you have Dataset configured for the volume you are trying to migrate ?

Or Are you trying to leverage Protection Manager to assist you in migrating the data from 32 to 64 bit aggr ?

Now, coming to the limitation of PM esp with 32 and 64bit mirror.

VSM cannot be created using any of the available DFM/OnCommand versions  in NOW.

But it can update a 32 to 64 bit relationship which is created outside PM and imported into a dataset.

Also as per the TR doing inplace upgrade of aggr from 32 to 64 bit reduces the hassle of migration.

Regards

adai

Re: Restore volume from snapshot to different location

Yes we have datasets configured for the volumes.  This is what we're trying to preserve, the relationships and the backups.

The only assist that PM is doing is allowing us to backup data from the primary filers and then restore that data after we've rebuilt the primaries.

As for an in place upgrade of the primaries ONTAP limitations prevent us from doing that.  This is because there are only two ways to get to 64 bit aggrs from 32 bit aggrs.

1) New install with aggrs built as 64 bit.

2) Force conversion by pushing aggr size over 16 TB. 

We can't do number 2 because there are not enough spare disks on the primary filers to push the aggrs over the 16 TB limit.  We could push one of the aggrs over the limit but this requires us to destroy one of the aggrs on the filer so we can use the disks from the aggr to add to the other one and trigger the conversion.  Which we could do and only have to backup/restore half of the data on the primaries.  This of course still requires a backup and restore from the secondaries which is what we worried about doing and then finding out the dataset backups, after the restore, fail.

And since we would have to destroy one of the aggrs anyway to trigger the conversion we decided to go ahead and destroy both aggrs and do a proper rebuild of the aggrs on the primaries. 

The aggr rebuild is so we can go from 15 raid group to 18 raid group to fully utilize all our disks (go from having 9 spares to 3 spares).

Hope that helps.

Keith