It sounds like you need to minimize downtime (and who doesn't). Have you considered using ndmpcopy ? You minimize downtime by running the full copy while you are still up, and then pick up just the changes during the downtime.
Unlike vol copy, ndmpcopy does not preserve qtrees. If you have any qtrees, you need to create them on the target volume before running ndmpcopy.
Run the full (level 0) ndmpcopy while you are still up, so it doesn't matter too much how long it takes.
An hour or so before the scheduled downtime, do a level 1 ndmpcopy to pick up changes since the full copy. Depending on how long since the full copy and how quickly data turns over in the filesystem, this might take an hour or so. No big deal because you are still up.
During the downtime, turn off NFS and CIFS and do a level 2 ndmpcopy to pick up changes since the level 1. There should only be about an hour of changes, so this should run in a matter of minutes.
WARNING:
There is a chance this will fail if you are running 5.3.x because of BURT 30733. Under some circumstances an incremental restore fails and crashes the filer. If you upgrade to 6.x, that supposedly fixes this bug.
Hi everyone,
We are looking for a high rate migration operation which could let us move a volume from a disk shelf to another. In a first place, we think of using the vol copy command. We thaught we could easily manage a strong volume copy rate but it appeared the rate is buggy limited to 36Gb/hour (as if the Filer was copyinbg over a 'perfect' 10Bas-T interface) : http://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.7295526.2875209&... resource= In looking around we found papers dealing with others interface kinds : http://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.7295507.2875209 The limit are 25GB/hr over 100Base-T interface, and 28GB/hr over FDDI so less than a 'perfect' 10Base-T interface. (on a F630 Filer :)
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support