o "Level i" copies will *not* work with level 0-9 copies of the same source and destination. That is, you cannot do a "-level 0" ndmpcopy to move data initially, then use "-level i" to make updates. For that matter, you can't use any other method to do the initial copy such as "vol copy", dump/restore, rsync, etc. If you want to use "-level i" at all, you must use it to do the initial copy in addition to all updates (until you want to stop using ndmpcopy for updates).
Thanks for the clarification.
o Don't modify the destination until you're done ndmpcopy'ing to it. Once the destination is modified, another "level i" will likely *not* be able to update that destination.
Someone suggested having the destination 'offline' until the moment we are ready to switch the volumes (i.e. we have two identical filesystems).
Also be aware that if you are copying the entire vol1 to vol2, snapmirror is definitely going to be faster than incremental ndmpcopy. Not sure if you have a snapmirror license, but assuming the deltas on the source volume aren't enormous, the final snapmirror sync can often take only a few minutes.
I believe we have the license for snapmirror, but have not been using it. Would snapmirror be a better solution in this situation? Is it relevant for snapmirror that source and destination volumes have different number of drives and RAID sizes? And that they reside on the same filer?
Thanks again,
Robert
On Wed, Jun 06, 2001 at 06:43:54PM -0700, Robert.Sabo@ecomm.bc.ca wrote:
Someone suggested having the destination 'offline' until the moment we are ready to switch the volumes (i.e. we have two identical filesystems).
I'm pretty sure that NDMPcopy requires the destination volume to be on-line. It is definitely true that all "vol copy" commands or for the level 0 copy for SnapMirror, the destination volume must be off-line. For SnapMirror, after an initial copy it brings the destination volume on-line but read-only for all incremental updates.
Just make sure that the destination volume isn't NFS exported or CIFS shared at all until after you've completed the NDMPcopy migration. Changes to the destination will most certainly make the incremental restore's job difficult if not impossible.
I believe we have the license for snapmirror, but have not been using it. Would snapmirror be a better solution in this situation? Is it relevant for
If you have the license, definitely. SnapMirror is basically a scheduled version of "vol copy" but it has a pretty robust feature-set. My guess is that it will be the absolute fastest, error-free, hassle-free way to do this kind of a migration.
Instances where you can't or shouldn't use vol copy/SnapMirror are typically when:
1) The destination volume already has some unique data on it that can't be destroyed.
2) Less than a full volume is being copied to the destination volume.
3) The requisite disks/inodes are not available on the destination volume.
4) Data is migrated with 1-n, n-1, or n-n relationship of number of source volumes to destination volumes (they only work with 1-1).
Would snapmirror be a better solution in this situation? Is it relevant for snapmirror that source and destination volumes have different number of drives and RAID sizes? And that they reside on the same filer?
Not in any way. As Chris mentioned in this thread, neither vol copy or SnapMirror care about the RAID properties of a destination volume. They do care about some filesystem properties - specifically the destination must be greater than or equal to the source in size *and* it must have more than or equal the number of inodes as the source. Both of these can be checked with "df" and "df -i". One caveat is ensure your "snap reserve" is set the same on both source and destination before comparing sizes with df since this setting affects the output. I typically zero out both "snap reserves" for a few minutes to ensure that the destination volume is equal or greater in size, then I re-set the reserves to whatever their original value was.
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com
-
Jeffrey Krueger -
Robert.Saboï¼ ecomm.bc.ca