QSM for 32bit to 64bit data migration

[shindesac]

Hi,

Please point me to the link or document which explain step by step QSM procedure to migrate data between 32bit aggregate and 64bit aggregate for the volumes with snapshot.

I have volumes with snapshots with the default name(hourly./nightly./weekly.)

Thanks and Regards,

Sachin SHInde.

[radek_kubka]

Hi Sachin,

As far as I am concerned, nothing changed since you have posted a very similar question few months ago (http://communities.netapp.com/message/53569#53569), and the answer to it is still valid:

- either wait for ONTAP 8.1

- or do a tedious migration following KB article https://kb.netapp.com/support/index?page=content&id=1012182

Regards,

Radek

[adamgross]

+1 wait for ONTAP 8.1

[shindesac]

Hi Radek,

I had gone through the KB article you gave and it was very helpful.

But I am confused about how to migrate default snapshots which got created with name hourly, nightly and weekly.

Can you please explain how to migrate default snapshots (snapshots with name hourly/nightly/weekly ) to the destination?

Thanks,

Sachin.

[peter_lehmann]

Hi there is a simple answer to that...

You can not.

[abuchmann]

Correct me if I'm wrong, but I think it's possible (but not easy) to migrate the snapshots.

After you have initialized the snapmirror:

snapmirror update -s nightly.0 -c nightly.0 -S src:/vol/<srcvol>/<srcqtree> /vol/<dstvol>/<dstqtree>

snapmirror update -s nightly.1 -c nightly.1 -S src:/vol/<srcvol>/<srcqtree> /vol/<dstvol>/<dstqtree>

snapmirror update -s nightly.2 -c nightly.2 -S src:/vol/<srcvol>/<srcqtree> /vol/<dstvol>/<dstqtree>

snapmirror update -s nightly.3 -c nightly.3 -S src:/vol/<srcvol>/<srcqtree> /vol/<dstvol>/<dstqtree>

you have to do it for every snapshot!

Kind regards,

Adrian

[radek_kubka]

I thought that as well - wasn't aware of any restrictions re snapshots with default names.

[peter_lehmann]

Adrian, you are correct. Sorry

[shindesac]

If we try to update snapmirror with the automatically created snapshots (hourly/nightly/weekly) it gives following message:

snapmirror update  -s weekly.0 -c weekly.0 -S /vol/<src_vol>/<src_qtree> -w /vol/<dstvol>/<dstqtree>

Cannot transfer a snapshot with a name in the format of

an automatically created snapshot: weekly.0.

Select a different snapshot, or rename the snapshot you have chosen.

usage:

snapmirror update [-k <n>][-s <src_snap>] [-c <dst_snap>][-S [<srcfiler>:]<srcpath>][-w] [<dstfiler>:]<dstpath>

in which <srcpath> and <dstpath> are

<volname> or </vol/volname/qtreename>

        - forces snapmirror update of snapmirror destination

That’s why i posted this on community to find out ways to migrate automatically created snapshots.

I can see the option to rename the snapshot and migrate it. But it will manual task to remove the snapshots after they expires.

[radek_kubka]

It would add yet one more step to already tedious task, but how about renaming default snapshots for the migration & then renaming them back to their original names?

[abuchmann]

Okay, did not know that.

But you may have to choose that way and use a scheduled powershell-script for cleanup. simple solution:

$vol = '*'           #is looking fo all volumes

$retention = -7      #stands for 7 days (has to be negative)

get-navol | where {$_.Name -like $vol} | foreach-object {$ParentName=$_.Name;get-nasnapshot $_.Name | add-member -membertype noteproperty -name ParentName -value $ParentName -passthru} | where {$_.AccessTimeDT -lt ((Get-Date).AddDays($retention))} | ForEach-Object {Remove-NaSnapshot $_.ParentName $_.Name -Verbose}