Mailing List Archive

I recommend using NDMPCopy. It is non disruptive since it uses a Dump & Restore to disk, the process can be done on-line.
If you are doing it on the same filer you might notice some CPU taxation, but nothing to serious. You can also use the Incremental NDMCopy features to accommodate gradual migration.

If you need to use Qtrees you can use NDMPCopy to copy to Qtrees within the Destination Volume, just make sure you Create the Qtrees prior to starting the NDMPCopy. You can start 4 NDMPCopy processes concurrently.

You can get the instructions & details on the requirements from the NOW website.

-------------------------------------
Monty Ayyash, E.E, MCSE
Network Appliance - Canada
Professional Services Consultant
201 City Center Drive, Suite 900
Mississauga, Ontario L5B 2T4
Office: 905-804-1099
Fax: 905-804-1232
Mobile: 416-727-7892
Pager: 1-877-5-NETAPP (1-877-563-8277)
Email: monty.ayyash@netapp.com
-----------------------------------------


-----Original Message-----
From: Boris Khmelniker [mailto:BKhmelniker@bna.com]
Sent: Monday, August 05, 2002 1:26 PM
To: toasters@mathworks.com
Subject: Migration question


Hello,
We are going to migrate data from 10 9GB shelves (2 Volumes)
to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760
filer running DATAONTAP 6.1.1. Downtime allowed is minimum
(4 hours). I was planning to use SnapMirror but worrying
about fragmentation it will cause because of the difference
in disk size. Any thoughts on that are appreciated.
Thank you,
Boris

I'd like to second that question: we used snapmirror to
copy a vol of 18's to 7x72 on a ds14, but it hasn't been attached
to the production filer yet. Snapmirror, because vol copy and
ndmpcopy both failed, source filer was at 536R1 and dest was 613.






-----Original Message-----
From: Boris Khmelniker
To: toasters@mathworks.com
Sent: 8/5/02 1:25 PM
Subject: Migration question

Hello,
We are going to migrate data from 10 9GB shelves (2 Volumes)
to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760
filer running DATAONTAP 6.1.1. Downtime allowed is minimum
(4 hours). I was planning to use SnapMirror but worrying
about fragmentation it will cause because of the difference
in disk size. Any thoughts on that are appreciated.
Thank you,
Boris

It's not truly fragmentation but a matter of bit ordering. Snapmirror's
bit order is 1 to end-of-source-drive, then continue if dest drive still
has room. So, if you are going from 9gb drives to 72gb drives, you're
going to have serious issues. What will happen is all data from the
first 7 or 8 drives (depending on BC or ZC drives) will all be put onto
the first 72gb drive.

I found out the hard way, 18gb drives to an r100 with 136gb drives.
Couldn't figure out why my backups from the r100 were so slow; that
would be why.

In my case, what would normally be 7 stripes across seperate drives
became 7 stripes located non-sequentially on one drive.

~JK

"Toal, Dave" wrote:
>
>
>
> I'd like to second that question: we used snapmirror to
> copy a vol of 18's to 7x72 on a ds14, but it hasn't been attached
> to the production filer yet. Snapmirror, because vol copy and
> ndmpcopy both failed, source filer was at 536R1 and dest was 613.
>
> -----Original Message-----
> From: Boris Khmelniker
> To: toasters@mathworks.com
> Sent: 8/5/02 1:25 PM
> Subject: Migration question
>
> Hello,
> We are going to migrate data from 10 9GB shelves (2 Volumes)
> to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760
> filer running DATAONTAP 6.1.1. Downtime allowed is minimum
> (4 hours). I was planning to use SnapMirror but worrying
> about fragmentation it will cause because of the difference
> in disk size. Any thoughts on that are appreciated.
> Thank you,
> Boris

--
=====================
Jeff Kennedy
Unix Administrator
AMCC
jlkennedy@amcc.com

One caveat to this is qtree snapmirroring. There is no bit ordering
problem if you do it by qtrees in OT 6.2+.

~JK

Jeff Kennedy wrote:
>
> It's not truly fragmentation but a matter of bit ordering. Snapmirror's
> bit order is 1 to end-of-source-drive, then continue if dest drive still
> has room. So, if you are going from 9gb drives to 72gb drives, you're
> going to have serious issues. What will happen is all data from the
> first 7 or 8 drives (depending on BC or ZC drives) will all be put onto
> the first 72gb drive.
>
> I found out the hard way, 18gb drives to an r100 with 136gb drives.
> Couldn't figure out why my backups from the r100 were so slow; that
> would be why.
>
> In my case, what would normally be 7 stripes across seperate drives
> became 7 stripes located non-sequentially on one drive.
>
> ~JK
>
> "Toal, Dave" wrote:
> >
> >
> >
> > I'd like to second that question: we used snapmirror to
> > copy a vol of 18's to 7x72 on a ds14, but it hasn't been attached
> > to the production filer yet. Snapmirror, because vol copy and
> > ndmpcopy both failed, source filer was at 536R1 and dest was 613.
> >
> > -----Original Message-----
> > From: Boris Khmelniker
> > To: toasters@mathworks.com
> > Sent: 8/5/02 1:25 PM
> > Subject: Migration question
> >
> > Hello,
> > We are going to migrate data from 10 9GB shelves (2 Volumes)
> > to 1 DS14 shelf (14 72GB disk) (also 2 volumes) on the F760
> > filer running DATAONTAP 6.1.1. Downtime allowed is minimum
> > (4 hours). I was planning to use SnapMirror but worrying
> > about fragmentation it will cause because of the difference
> > in disk size. Any thoughts on that are appreciated.
> > Thank you,
> > Boris
>
> --
> =====================
> Jeff Kennedy
> Unix Administrator
> AMCC
> jlkennedy@amcc.com

--
=====================
Jeff Kennedy
Unix Administrator
AMCC
jlkennedy@amcc.com