toasters

toasters@lists.teaparty.net

2 participants
13522 discussions

moving data between filers
by Anthony Fiarito 15 Jan '99

15 Jan '99

Here is the scenario: I have two identically configured F630 filers. Filer A is active and contains about 150 gigs of data (all in one volume). Filer B is brand new and empty. I need to replicate the data from Filer A to Filer B with the minimal amount of downtime for Filer A. I could do a vol copy to move the data, but in the time that it would take to complete, much of the data would have changed and would be out of date. I was thinking of some sort of solution where I could do a vol copy (or something similar) of the data from Filer A to Filer B while Filer A was up and running. Once that was done, I should shut down Filer A and resync the changes that were made to Filer A during the copy to Filer B (thus giving me an exact copy of the data on each netapp). It would be similar to doing a level 0 dump while everything was active, and then a level 1 while they were shut down. The problem though is that I need them to be synched exactly (i.e. files/dirs that get deleted from Filer A during the initial copy would also get deleted from Filer B during the sync phase). Another option might be to do an rdist from Filer A to Filer B of the data while they are active, isolate them from the network once that is done, and re-run rdist to sync of any changes that took place during the initial move. With 150 gigs of data though, this would probably take a ReallyLongTime[tm], thus not being a viable solution. Has anyone tackled a situation like this before? What methods did you use and in what sort of time frame were you able perform the replication? Thanks in advance for any feedback. -alf --- Anthony Fiarito alf(a)cp.net Critical Path Operations

5 4

RE: moving data between filers
by Melvin, Grant 15 Jan '99

15 Jan '99

Hi, I'm not sure how long volcopy will take. You will have to budget 8-10 hours minimum. Thought I'd share some numbers on this with you: F630 local volume copy (no load) ~36 GB/hr F630 -> F760 via GbE (no load) ~48 GB/hr F760 -> F760 via 100bT (load on source) ~28 GB/hr ++++++++ The second option to consider if you have NDMP backup in place Take a snapshot of Filer A Using NDMP backup Filer A. (This will take about 7 hours) Restore the back to Filer B. (This will take about 10-12 hours) Remove Filer A from the network.( rename it Filer C) Get a snapshot of Filer C. Backup any changes from Filer C since last backup.(this is an incremental backup) (This will take less than 1 hour) Restore the incremental backup to Filer B. (this will take about 1-1.5 hours) Filer B should look like Filer A data. This will keep all your associated ACL. Alternatively, you can use NDMPcopy available on ftp://ftp.ndmp.org and skip writing/reading to/from tape. As outlined in the "Migrating Data Between NetApp Filers" white paper at: http://www.netapp.com/technology/level3/3018.html Cheers, Grant

3 3

example of .snapshot confusion under linux (fwd)
by Jim Davis 15 Jan '99

15 Jan '99

Mail from a user on a linux Redhat 5.1 system mounting files from a F520 running 5.1.2R3, and getting some odd results with the .snapshot files. Sounds client-side to me, but I'm not real familiar with linux: Here's an example of bad .snapshot confusion under Linux. [runic] mv mAwareness.java mAwareness.bad [runic] cp .snapshot/hourly.1/mAwareness.java . cp: `.snapshot/hourly.1/mAwareness.java' and `./mAwareness.java' are the same file (( no, they aren't; there shouldn't BE a ./mAwareness.java: I just mv'd it. )) (( later, viewing the directory on hawk confirms that the mv was done )) [runic] cp .snapshot/hourly.1/mAwareness.java xx cp: .snapshot/hourly.1/mAwareness.java: No such file or directory (( huh? it was just there )) [runic] ls -l mA* -rw-rw-r-- 1 gmt gmt 870 Jan 12 15:33 mAwareness$1.class -rw-rw-r-- 1 gmt gmt 984 Jan 12 15:33 mAwareness$2.class -rw-rw-r-- 1 gmt gmt 1248 Jan 12 15:33 mAwareness.class -rw-rw-r-- 1 gmt gmt 1241 Dec 21 14:03 mAwareness.java (( where's mAwareness.bad? )) [runic] ls -l xx /bin/ls: xx: No such file or directory [runic] make clean make -f ../jMakefile clean make[1]: Entering directory `/.automount/home/gmt/.snapshot/hourly.1/cj/Monitor' (( wait a minute. that's the wrong directory. I'm not in the snapshot dir. )) rm -f built.t newest.t *.class *.jar rm: built.t: Read-only file system rm: newest.t: Read-only file system rm: Config.class: Read-only file system rm: Display$1.class: Read-only file system rm: Display$2.class: Read-only file system rm: Display.class: Read-only file system rm: HostPane.class: Read-only file system rm: Monitor$1.class: Read-only file system rm: Monitor$2.class: Read-only file system rm: Monitor.class: Read-only file system rm: Remote.class: Read-only file system rm: StripChart.class: Read-only file system rm: Supervisor$1.class: Read-only file system rm: Supervisor.class: Read-only file system rm: SysData.class: Read-only file system rm: SysEntry.class: Read-only file system rm: mAwareness$1.class: Read-only file system rm: mAwareness$2.class: Read-only file system rm: mAwareness.class: Read-only file system rm: mInit$1.class: Read-only file system rm: mInit.class: Read-only file system rm: mReporter$1.class: Read-only file system rm: mReporter.class: Read-only file system rm: rBoot$1.class: Read-only file system rm: rBoot.class: Read-only file system rm: rControl$1.class: Read-only file system rm: rControl.class: Read-only file system rm: rIdentity.class: Read-only file system rm: rLoad$1.class: Read-only file system rm: rLoad.class: Read-only file system rm: rMicro.class: Read-only file system rm: rboot.jar: Read-only file system rm: remote.jar: Read-only file system make[1]: *** [clean] Error 1 make[1]: Leaving directory `/.automount/home/gmt/.snapshot/hourly.1/cj/Monitor' make: *** [clean] Error 2 (( this would have worked except for the directory confusion ))

3 4

RE: moving data between filers
by Michel Kapuscinski 14 Jan '99

14 Jan '99

In the past I have moved large amounts of data over night. 100Gig -200Gig. This is how I was configured. -3 sun server were used to copy the data via NFS version 2 with the command "cpio" from one mount point to the other. Each mount point would be from a different sub-directory. -one server with an ATM FORE OC-3 interface, with 4 concurrent cpio streams allowing 20Gig/hr -and two server using built-in 100BT-FD, each server with 2 concurrent cpio streams allowing 12Gig/hr from each system -My new server would have 3 to 6 interfaces to allow for load balancing of traffic during the copy. Change your export to be READ ONLY and disable your SHARE to PC clients or rename the system and have the new system renamed with Filer A and configuration. Keep in mind this will not keep any ACL associated with any file. For 150Gig it would take about 4 hours if all goes well. The second option to consider if you have NDMP backup in place Take a snapshot of Filer A Using NDMP backup Filer A. (This will take about 7 hours) Restore the back to Filer B. (This will take about 10-12 hours) Remove Filer A from the network.( rename it Filer C) Get a snapshot of Filer C. Backup any changes from Filer C since last backup.(this is an incremental backup) (This will take less than 1 hour) Restore the incremental backup to Filer B. (this will take about 1-1.5 hours) Filer B should look like Filer A data. This will keep all your associated ACL. I'm not sure how long volcopy will take. You will have to budget 8-10 hours minimum. Michel Kapuscinski mikeka(a)nortel.com > -----Original Message----- > From: Anthony Fiarito [SMTP:alf@cp.net] > Sent: Thursday, January 14, 1999 4:25 PM > To: toasters(a)mathworks.com > Cc: alf(a)cp.net > Subject: moving data between filers > > Here is the scenario: > > I have two identically configured F630 filers. Filer A is active and > contains about 150 gigs of data (all in one volume). Filer B is brand > new and empty. I need to replicate the data from Filer A to Filer B > with the minimal amount of downtime for Filer A. I could do a vol > copy to move the data, but in the time that it would take to complete, > much of the data would have changed and would be out of date. I was > thinking of some sort of solution where I could do a vol copy (or > something similar) of the data from Filer A to Filer B while Filer A > was up and running. Once that was done, I should shut down Filer A > and resync the changes that were made to Filer A during the copy to > Filer B (thus giving me an exact copy of the data on each netapp). It > would be similar to doing a level 0 dump while everything was active, > and then a level 1 while they were shut down. The problem though is > that I need them to be synched exactly (i.e. files/dirs that get > deleted from Filer A during the initial copy would also get deleted > from Filer B during the sync phase). Another option might be to do an > rdist from Filer A to Filer B of the data while they are active, > isolate them from the network once that is done, and re-run rdist to > sync of any changes that took place during the initial move. With 150 > gigs of data though, this would probably take a ReallyLongTime[tm], > thus not being a viable solution. > > Has anyone tackled a situation like this before? What methods did you > use and in what sort of time frame were you able perform the > replication? > > Thanks in advance for any feedback. > > -alf > > --- > Anthony Fiarito > alf(a)cp.net > Critical Path Operations

1 0

Re: example of .snapshot confusion under linux (fwd)
by sirbruce＠ix.netcom.com 14 Jan '99

14 Jan '99

Looks very much like a client side issue to me. Hard to tell without a full transcript, though. If the problem is as advertised, it should be easily reproduced and additional information collected. The problem or confusion at the end may have resulted from using automounter... you'd have to check how that is configured. Bruce

2 1

Forcing full duplex on 720
by Jamie Lawrence 13 Jan '99

13 Jan '99

Hi - I have a 720 with a quad card which never negotiates to full duplex with out 10/100 switch. The Solaris boxes on the same switch negotiate to FD just fine, and the 720 thinks FD is enabled, but the switch only ever negotiates to HD. Has anyone seen this before? thing> ifconfig -a e0: flags=43<UP,BROADCAST,RUNNING> mtu 1500 inet xxx.xxx.xxx.xxx netmask ffffff80 broadcast xxx.xxx.xxx.xxx ether 00:a0:98:00:26:1e (100tx-fd-up) e2a: flags=43<UP,BROADCAST,RUNNING> mtu 1500 inet 192.168.0.1 netmask ffffff00 broadcast 192.168.0.255 ether 00:c0:95:e0:72:e8 (100tx-fd-up) e2b: flags=43<UP,BROADCAST,RUNNING> mtu 1500 inet 192.168.0.2 netmask ffffff00 broadcast 192.168.0.255 ether 00:c0:95:e0:72:e9 (100tx-fd-up) e2c: flags=43<UP,BROADCAST,RUNNING> mtu 1500 inet 192.168.0.3 netmask ffffff00 broadcast 192.168.0.255 ether 00:c0:95:e0:72:ea (100tx-fd-up) e2d: flags=43<UP,BROADCAST,RUNNING> mtu 1500 inet 192.168.0.4 netmask ffffff00 broadcast 192.168.0.255 ether 00:c0:95:e0:72:eb (100tx-fd-up) lo: flags=9<UP,LOOPBACK> mtu 1536 inet 127.0.0.1 netmask ff000000 broadcast 127.0.0.1 Thanks for any insights. -j -- Jamie Lawrence "Self-knowledge is always bad news." -- John Barth __________________________________________________________ Sr. Systems Administrator Third Age Media 415.267.4657 jal(a)thirdage.com www.thirdage.com

4 4

Re: Forcing full duplex on 720
by Paul Albers 13 Jan '99

13 Jan '99

Hello Jamie, Do you have the switch set to autonegotiate? If you do, what will happen is the switch will attempt to autonegotiate with the filer, but since e0 was set manually, we don't communicate back with the switch. By default then the switch will negotiate down to half duplex, no matter what the other side is set to. The best way I think to fix this, is to manually set both switch and filer's interfaces to full duplex. Turning both autosensing and autonegotiation off on the corresponding switch ports. As Andrew mentioned below, setting auto works very well with most switches. There are switches out there that will not autonegotiate well. In these cases, if the filer does not get response back, we drop down to half duplex. This is the protocol I mentioned above. Then it is likely that the switch could be running at full duplex. Either method is fine, just do some testing with the auto setting working with your current switch to make sure all works fine. Regards, -paul Escalations Engineer Network Appliance 408.367.3103 At 08:18 AM 1/13/99 +0000, you wrote: >You haven't given enough info for me to tell what type of card e0 is, but >the quad card will certainly support autosensing. Try setting the >mediatype to "auto" - it should then negotiate with the switch correctly. >If e0 supports autonegotiation it will have only one socket - in which case >you can do the same there. > >If it doesn't work, open a call with NetApp support and supply more >information - at least the switch details, sysconfig -v > >Andrew Bond, >UK Systems Engineer > >At 06:46 pm 1/12/99 -0800, Jamie Lawrence wrote: >>At 06:36 PM 1/12/99 -0800, Jerry Talkington wrote: >>>Jamie Lawrence wrote: >>>> >>>> Hi - >>>> >>>> I have a 720 with a quad card which never negotiates to full >>>> duplex with out 10/100 switch. The Solaris boxes on the same >>>> switch negotiate to FD just fine, and the 720 thinks FD is >>>> enabled, but the switch only ever negotiates to HD. >>>> >>>> Has anyone seen this before? >>> >>>Not sure I understand the question, those all seem to be at full >>>duplex. As a general rule, setting the filer up to autonegotiate is a >>>bad idea, since it will try to come up faster than the interface can >>>negotiate a connection. I always recommend that people manually set >>>both the filer (through the rc file) and the switch to whatever duplex >>>they want to use. >> >>Sorry - That message was poorly written. The filer thinks the interface >>is full duplex. The switch thinks it is half duplex. I am setting the >>interface manually in rc: >> >>ifconfig e0 mediatype 100tx-fd `hostname`-e0 netmask 255.255.255.128 >>ifconfig e2a mediatype 100tx-fd `hostname`-e2a >>ifconfig e2b mediatype 100tx-fd `hostname`-e2b >>ifconfig e2c mediatype 100tx-fd `hostname`-e2c >>ifconfig e2d mediatype 100tx-fd `hostname`-e2d >> >>This is an unmanaged switch, so forcing the speed is not an option, >>but I don't think the switch is faulty because the Sun machines behave >>as expected - both the machines and the switch declare a full duplex >>connection. >> >>-j >> > >

1 0

Fore ATM Drivers on F760
by Des Barden 13 Jan '99

13 Jan '99

We are looking to connect a F760 into a Fore Systems ATM LAN. The LAN has has four ATM switches that are meshed for resilience. The ATM services are configured to use LANE and Distributed LAN Emulation. To make use of the features available in the Fore Systems version five code we would like to connect the F760 via four OC3 ATM cards. What I would like to know if by having multiple cards that we could make use of UNI failover, failover groups and load balancing. Regards, Des Barden Team Leader Unix/LAN IS Regional Services (Harlow) Esn: 742-5856

1 0

Re: Gigabit ethernet card placement
by Scott Miller 12 Jan '99

12 Jan '99

On Jan 11, 10:19pm, Roland Lee wrote: > Subject: Re: Gigabit ethernet card placement > Daniel, on the F630, the gigabit card should be in slot 10, What if you have a cluster? The ServerNet card must also go into slot 10. -Skottie > and on the > F520 and the F540, the card must be in slot 3. Those are the only slots > supported and tested, though they may work in other slots. > Performance-wise, you would want the fastest network card to be in slot 10 > on the F630 anyways. > > Roland Lee > NetApp TSE > > On Mon, 11 Jan 1999, Daniel Quinlan wrote: > > > Performance-wise, does it matter what PCI slot you put a Gigabit > > ethernet card? (This goes back to the question about which slots are > > 64bit vs. 32bit.) Specifically, I'm wondering about the F630 and > > maybe the F540. > > > > I wasn't able to find much information about installing Gigabit > > ethernet cards on now.netapp.com. > > > > - Dan > > > >-- End of excerpt from Roland Lee -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

1 0

NDMP fix works!
by Menachem Kaiser (r53417) 12 Jan '99

12 Jan '99

Date: Tue, 12 Jan 1999 16:17:35 +0200 From: "Menachem Kaiser (r53417)" <r53417(a)email.sps.mot.com> Reply-To: "Menachem Kaiser (r53417)" <r53417(a)email.sps.mot.com> Organization: Motorola Semiconductor Israel To: andrew.lockhart(a)veritas.com, "robert.slater(a)veritas.comkahana"@clalsys.clalcomp.co.il, support(a)veritas.com, brian.blake(a)veritas.com, mike.proveder(a)veritas.com, brad.haggert.veritas.com(a)email.sps.mot.com CC: support(a)netapp.com, bobbl(a)netapp.com, pas(a)veritas.com, Nachshon Yeshurun <nachshon(a)msil.sps.mot.com>, Haim Leib <haiml(a)msil.sps.mot.com>, pas(a)veritas.com, "dan(a)netapp.com Eyal Traitel" <eyalt(a)msil.sps.mot.com>, karl(a)corp.webtv.net, toaster(a)mathworks.com, "Nick Janakas (qa4418)" <qa4418(a)email.sps.mot.com>, "Hans-Peter Kiekuth (hkiekut1)" <hkiekut1(a)email.sps.mot.com> Subject: NDMP fix works! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We wish to thank all those who responded to my request. We changed the following two variables in the bp.conf file in veritas netbackup software as follows: CLIENT_CONNECT_TIMEOUT = 3600 CLIENT_READ_TIMEOUT = 3600 From our initial test the backup does not crash any more. We will continue checking the backup and restore using NDMP. Regards Manny Date: Mon, 11 Jan 1999 14:51:21 +0200 From: "Menachem Kaiser (r53417)" <r53417(a)email.sps.mot.com> Reply-To: "Menachem Kaiser (r53417)" <r53417(a)email.sps.mot.com> Organization: Motorola Semiconductor Israel X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: andrew.lockhart(a)veritas.com, robert.slater(a)veritas.com, kahana(a)clalsys.clalcomp.co.il, support(a)veritas.com, brian.blake(a)veritas.com, mike.proveder(a)veritas.com, brad.haggert.veritas.com(a)email.sps.mot.com CC: support(a)netapp.com, bobbl(a)netapp.com, pas(a)veritas.com, Nachshon Yeshurun <nachshon(a)msil.sps.mot.com>, Haim Leib <haiml(a)msil.sps.mot.com>, pas(a)veritas.com, dan(a)netapp.com, Eyal Traitel <eyalt(a)msil.sps.mot.com> Subject: NDMP doesn't work ! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Sir's, We have an open call at Veritas call #110239. On Jan 7th the call was upgraded to severity 1. According to the SLA agreement with Veritas this call should be upgraded to SVP WW operations. We have not yet received any solution. The local Veritas representitive has explained to us that he has been in contact with Veritas UK. and hopes to be in contact with Veritas U.S. this evening. One of the key reasons we chose the combination of Veritas and Network Appliance were the assurances we got that we would be able to restore data to the filer in the event of a disaster within a relatively short period of time. (at a rate of 50 GB/Hr). We have two F760 Netapp filers that we are unable to utilize since we cannot effectively restore the data in the event of a disaster. Although we can backup and restore the data across the net, the severe impact of hours of downtime related to a double disk failure while restoring a filer over the net, are not feasible. Thus we have ceased migrating data to these filers. This is a major setback in the normal operations of the company and has already made a serious impact on our business. We expect to hear from you by the end of the business day with a plan and timetable for solving this problem. Thank-You Regards

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters