Hi Peter,
We are using the legato netapp client on our filers, and have been doing it for a while - primarely because it then acts like any other client to our Legato Server. My expereience is a bit mixed - it's working allright, I can do redirectied recover of it's data or recover dirctly to the filer, my problem is 1) speed: It's attached to my LAN via a 100MBit full duplex interface, but I only get about 5MB/sek; Im not sure where the problem is, it's alot of small files so it can be on both the filer and the server .... but we are looking into it now :) 2) It's not being maintained in the future, our support tells us that NetApp is going to use NDMP instead :( Med venlig hilsen, Best regards
Christian Sønder, System administrator TDC Internet (http://www.opasia.dk http://www.zillion.dk) Olof Palmes Alle 36, DK - 8200 Aarhus N, Denmark Tlf: +45 86 78 63 12, Fax +45 86 78 38 00 e-mail: mailto:chso@int.tele.dk
-----Oprindelig meddelelse----- Fra: Peter D. Gray [mailto:pdg@uow.edu.au] Sendt: 18. juni 2001 08:56 Til: toasters@mathworks.com Emne: legato netapp client
It seems most people on this list are using NDMP for backup of their filers. However, I would like to avoid that if I can.
Does anybody have expereience with the legato netapp client and does anybody know if that product is being maintained into the future?
Regards, pdg
--
See mail headers for contact information.
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 :)
Reasons given by the NetApp support is the CPU has a bunch of work in calculating optimizations of read and write operations. But I would be sure we are really not strunglled by any other limitations.
So here are our two questions : - (just to be sure) did anyone succed in using the vol copy command once and go beyond these limits ? -what is your opinion about that alternative : plug the Filer on a private Giga-ethernet network and make a manual copy (copy -R mnt/nac/vol0 /other_place ) of the whole volume from a shelf to the other. Do you think we could obtain real high rate transfers while keeping the integrity of the volume ? (the volume is a root volume with the "/etc" directory), no special tricks needed (if I use Windows, may I expect ACL modifications) ?
I thank you in advance.
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
Actually, if your copying a qtree, ndmpcopy will preserve the qtree. If you're copying something within a qtree it won't.
~JK
Steve Losen wrote:
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
Actually, if your copying a qtree, ndmpcopy will preserve the qtree. If you're copying something within a qtree it won't.
~JK
I used ndmpcopy -level 0 to copy an entire volume that contained over 20 qtrees to a newly created volume. When I was done, the target volume had normal directories in the place of the original qtrees, as indicated by the "qtree" command. DOT 5.3.7R2
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support
Actually, if your copying a qtree, ndmpcopy will preserve the qtree. If you're copying something within a qtree it won't.
Steve> I used ndmpcopy -level 0 to copy an entire volume that Steve> contained over 20 qtrees to a newly created volume. When I was Steve> done, the target volume had normal directories in the place of Steve> the original qtrees, as indicated by the "qtree" command. DOT Steve> 5.3.7R2
I ran into this too on DOT 5.3.6?? when I used nmdpcopy. I had to pre-create the qtrees on the destination as well.
John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548
"FPS France" fpsfrance@fps.fr writes
[...] but it appeared the rate isbuggy limited to 36Gb/hour (as if the Filer was copyinbg over a 'perfect' 10Bas-T interface) :
From what you say later, you clearly mean 36 GB/hour = 10 MB/sec, which sounds like a "perfect" 100Base-T interface to me!
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 :)
There's not a great deal of point trying to put a gigabit interface onto an F630, certainly.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
-
Chris Thompson -
Christian Sønder -
FPS France -
Jeff Kennedy -
John Stoffel -
Steve Losen