The scenario Flip put forword does work and it being deployed by NetApp Professional Services for those customers who want to buy this as a service. You can use QSM (or ndmpcopy for that matter) to transfer snapshots one qtree at a time, then take a local snapshot, then go to the next snapshot.

This method isn't for everyone and will not be practical in all environments, but it's a way to do it. The only other way I've seen some sites handle it is to just migrate the active filesystem to a new flex vol(s), then keep the old trad vol(s) around until the snapshots would have expired anyway, then re-deploy them.

Those are really the only choices I'm aware of for snapshot retention.

-- Adam Fox adamfox@netapp.com

-----Original Message----- From: Filip Sneppe [mailto:filip.sneppe@gmail.com] Sent: Tuesday, May 16, 2006 2:16 AM To: David Dalby Cc: George, Andrew; Steven Mandrake; toasters@mathworks.com Subject: Re: Upgrade 270 and keep snapshots for snapmirror

Hi,

On 5/16/06, David Dalby Ddalby@asi.com.au wrote:

You can qtree SnapMirror between trad & flex vols if you are using qtrees and you do not want to use ndmpcopy.

However, does not overcome your issues with snapshot retention .....

This is my first post to this list ...

If your data is inside qtrees on the tradvol, there is a clean way to migrate everything from tradvol to flexvol. Here's the basic idea:

- stop all scheduled snapshotting on source & dest - do a QSM initialize from your tradvol qtree(s) to your qtrees on the newly created flexvol, but - and this is important - use the oldest snapshot on the source as the baseline snapshot for the "snapmirror initialize" operation(s) - afterthe transfer(s) has/have finished, take a snapshot on the destination (same name as on the source) - next, do a QSM update operation for the relations from your tradvol to your flexvol, but use the "next" snapshot as a baseline for that snapshot - after those transfers have finished, take a snapshot on the destination again.

In the end, you will have all your snapshots on the destination. The dates will be all messed up, as those snapshots will all be taken on the same day, even if they cover months of snapshot differences in data.

Now, if your tradvol data is not in qtrees, there is always a possibility to do vol-to-qtree snapmirror, by using "-" as the source qtree. (Read up on it, as this won't transfer data that isn't already in a real qtree - that data will need to be transferred separately). You will end up with a different path to your data though. There's no way around that.

Also, I don't know how this migration procedure will work with your existing snapmirror relations. Don't know if you'll be able to just move them over to flexvol. Might work, but you need to test it out...

Regards, Filip