Vol copy will copy a volume's contents and the snapshots as well, but it won't work between traditional and flexible volumes.
Since you have space for both the traditional volumes and the aggregates, could you just not migrate the volumes contents to the new volumes and start snapshotting there, and at the same time retain the old volumes for a period of time until you don't require the old snapshots anymore.
Chris
--------------------------------------------------------
Christopher Holloway Consultant Professional Services
Main: +44 (0)1423 519000 Direct: +44 (0)1423 519099 Fax: +44 (0)1423 519251 Mobile:
DNS Arrow Nidderdale House Beckwith Knowle Harrogate HG3 1SA www.DNSarrow.co.uk
Email Confidentiality Notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.
"DNS Arrow" means Digital Network Services (UK) Limited, a company registered in England. Company Registration Number 3952678. Registered Office: Squire, Sanders & Dempsey, Level 28 Tower 42, 25 Old Broad Street, London EC2N 1HQ, UK.
-----Original Message-----
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Blake Golliher Sent: 21 March 2007 15:32 To: Scott, Tom E Cc: toasters@mathworks.com Subject: Re: move snapshots
There is no way to do this easily. ndmpcopy is a good way to start if you don't have a lot of files. qtree snapmirror is a good way to go as well. But there's no way to just move the snapshot from point a to point b. There's also 3rd party products like neopath, that can move data independent of your underlying filesystem technology.
-Blake
On 3/21/07, Scott, Tom E ScottTE@state.gov wrote:
List,
We have a FAS270 recently upgraded to 7.0.5. We would like
migrate
from traditional volumes to flexible volumes and keep the existing snapshots. I searched the NOW site and could not find much, has anyone
done
this? Will we be able to retain the existing snapshots?? We have
enough
drives to have the aggregate and traditional volumes working
simultaneously
on the same filer.
Cheers.
Tom.
chris.holloway@DNSArrow.co.uk writes: [...]
Since you have space for both the traditional volumes and the aggregates, could you just not migrate the volumes contents to the new volumes and start snapshotting there, and at the same time retain the old volumes for a period of time until you don't require the old snapshots anymore.
That's what we did, and we didn't _really_ have enough space. I had to downgrade the old traditional volume to raid4, _and_ run without hot spares. Oh, and turn off autosupport to NetApp until it was all over, so that it wouldn't keep automatically opening new support cases ... :-(
Someone had posted the following info on this list in mid 2006. I have used this technique to migrate a few trad vol to flexvols and retain the snapshots. Hope this helps
<Quote> 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... <end quote>
On 3/21/07, Chris Thompson cet1@cus.cam.ac.uk wrote:
chris.holloway@DNSArrow.co.uk writes: [...]
Since you have space for both the traditional volumes and the aggregates, could you just not migrate the volumes contents to the new volumes and start snapshotting there, and at the same time retain the old volumes for a period of time until you don't require the old snapshots anymore.
That's what we did, and we didn't _really_ have enough space. I had to downgrade the old traditional volume to raid4, _and_ run without hot spares. Oh, and turn off autosupport to NetApp until it was all over, so that it wouldn't keep automatically opening new support cases ... :-(
-- Chris Thompson Email: cet1@cam.ac.uk
the datetime stamps on our snapshot folders are "messed up" without doing all of this. They are sort of chronological, but not always, is that an option that needs to be enabled?
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.
Unix or Windows? On unix, try using the last access flag (-u) with ls, e.g. ls -lut .snapshot to see them ordered by the time the snapshot was created. Similarly, on Windows, try sorting by last access. This column is hidden, (right click on any column and then on more to see it). HTH
-G
On 3/21/07, Jack Lyons jack1729@gmail.com wrote:
the datetime stamps on our snapshot folders are "messed up" without doing all of this. They are sort of chronological, but not always, is that an option that needs to be enabled?
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.
-
Chris Thompson -
Holloway, Chris -
Jack Lyons -
Sto Rage©