toasters February 1999

toasters@lists.teaparty.net

106 participants
95 discussions

Re: Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 26 Feb '99

26 Feb '99

IT WORKS!!! Special thanks to: Tom Wike for verifying that BudTool 4.6 actually does work with OnTap 5.1.2R3P1 despite some confusing/conflicting recomendations from both NetApp and Intelliguard. Bamiyan Gobets & Grant Schuerfeld from NetApp for verifying all our configs. And finally to Shona McNeill who experienced the same problems and told me to check our jbcap file. After copying the entry for our jukebox from the old jbcap into the new, everything worked great! If any of you make it to the Philadelphia area, drop me a note so I can buy you a beer. No thanks to: Intelliguard support... :( Unfortunately, we just noticed that the file history database merges are not working properly. Hopefully we can resolve this ourselves, 'cause Intelliguard isn't any help.... Thanks again to everyone who provided help. jason In message <199902241959.OAA28405(a)jagular.dev.susq.com>, "Jason D. Kelleher" writes: > > On the evening of Saturday February 20 we upgraded from BudTool 4.5 > to 4.6. Since then, we've not been able to do local NDMP backups > on our filer. Anyone out there experience similar problems? If > so, would you please throw some suggestions my way. > > We have support calls open with both NetApp (being very helpful > considering it's probably not an issue with their system) and > Intelliguard (with what we pay them I'd assume they could at least > hire warm bodies). Here's what we've come up with so far: > > > 1) Intelliguard told us to add the line "ROBOT_SCSI_LUN 1" to > the jbmgr_config for the filer. This allowed the jbmgr > daemon to start. > >audreyii: /usr/budtool/bud [225] % cat jbmgr_config.audreyii.2 >ROBOT_DEV_HOST nfssrv1 >ROBOT_DEV_NAME spt0 >ROBOT_SCSI_ID 2 >ROBOT_SCSI_BUS 2 >ROBOT_SCSI_LUN 1 >DATA_DEV_NAME0 nrst0a >DATA_DEV_HOST0 nfssrv1 >PASSWORD xxxxxxxx >USEBARCODE N >VALIDATECMD "$BTHOME/bin/jbupdate audreyii:2 -a" >audreyii: /usr/budtool/bud [226] % > > > 2) Running the BudTool probe-scsi command shows the devices: > >audreyii: ~ [230] % probe-scsi -h nfssrv1 >Copyright (c) 1990-1999 by Intelliguard Software Inc. probe-scsi BudTool 4. >6 >SCSI Bus 0 >SCSI Bus 1 >SCSI Bus 2 >Target 2 > Unit 0 Removable Tape EXABYTE EXB-8500 CC37 > Unit 1 Removable Jukebox Device EXABYTE TZ Media Changer CC37 >SCSI Bus 3 >SCSI Bus 4 >audreyii: ~ [231] % > > > 3) After placing 2 labled BudToool tapes into the jukebox, > running jbupdate returns instantly showing no tapes in the > jukebox (doesn't even attempt to read tape labels). > >audreyii: ~ [236] % jbupdate audreyii:2 -a >------------------------------------------------------------------ > ------ W A R N I N G ------- >You have selected to force an update on all 5 tapes. This process >requires several minutes per tape for unbarcoded tapes. Large >jukeboxes with unbarcoded tapes can take several hours. The PID of >this process is 8721. Use a HUP, INT, TERM or QUIT to terminate >this process if you do not want to continue. >------------------------------------------------------------------ >Update complete. >audreyii: ~ [237] % jbmgr -H audreyii:2 ls -a > 0: > 1: > 2: > 3: > 4: >audreyii: ~ [238] % > > > 4) We can perform remote NDMP backups to our BudTool master > media server, but this isn't practical at ~2.2 GB/hr with > 70+ GB on our filer. (It's an old, slow F330 which I'm > supposed to be replacing instead of trouble-shooting...) > > 5) Gave Intelliguard a copy of our config file, the jbmgr diag > log, and the probe-scsi output for analysis. The diag file > does show some errors: > > 6) After not receiving much help from Intelliguard, we called > NetApp. They sugggested we upgrade from 5.1.2P2 to > 5.1.2R3P1 to remove the possibility that this was related to > an NDMPD bug (6417). > > 7) Spoke to Intelliguard again Monday and informed them that we > were going to upgrade the filer. We decided to see if the > upgrade solved the problem. (They managed to fix a btcp > issue after I waited 4 hours for a call back -- I'm still > waiting for our sales rep to tell me exactly what kind of > turn around to expect when paying extra for 24x7 support.) > > 8) Nothing changed after the upgrade Monday night. I informed > NetApp; they opened another call and had us send them more > info. > > 9) Told Intelliguard, gave them another copy of the diag file. > > 10) Configured BudTool to do lev 1 remote backups of the filer, > this should hold us until the weekend. > > 11) Had to take a personal day Tuesday (for personal reasons). > Hoped I get a couple voice/e-mails telling me that someone > figured out what was wrong. (Finding out we were stupid > and didn't have BudTool configured correctly would have > been a relief.) > > 12) Wednesday we received some follow-up calls from NetApp, the > call was escalated, and we're currently expecting a call. > > 13) We verified that tapes can be manually loaded into the > jukebox drive and dump run on the console of the filer. > Pretty confident that the jukebox didn't coincidentally die > during the BudTool upgrade. > > 14) Will file missing persons reports for Intelliguard > employees in another 24 hours. (Anyone have the number for > the police in Dublin, CA?) > > > So far, I'm confident it's a BudTool issue. (Many thanks/apologies > to NetApp if it is.) I'd be very grateful if someone could give me > a possible avenue of investigation. I'm at a dead-end and looking > at over 30 hours of backups to lev 0 our filer this weekend... :( > > thanks, > > jason > >--- >Jason D. Kelleher kelleher(a)susq.com >Susquehanna Partners, G.P. 610.617.2721 (voice) >401 City Line Ave, Suite 220 610.617.2916 (fax) >Bala Cynwyd, PA 19004-1122

4 3

RE: Nitech XRP1000 filer
by Thomson, Michael (UK, GIS ISM Group for R&D) 26 Feb '99

26 Feb '99

>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> >> To open a real can-of-worms, what would people on this list like to see in >> a low-end product offering? (Sub-$10k chassis). >This hypothetical discussion would be of great interest to me. :-) A bit like the Auspex 4Front AS100 / AS200 perchance? I just attended a presentation in London, and it looks like they've finally woken up to the low end of the market. Having used & administered Auspex and NetApp personally, it'll be interesting to see what happens in the next year... -- \\|||// Minds are like parachutes; (@ @) They only work when open. *---oOO-(_)-OOo------------------------------------* * Michael Thomson Email: mt53590(a)ggr.co.uk * * Unix Specialist Internal: 782 2369 * * Glaxo Wellcome External: 01438 762 369 * * Stevenage, UK Fax: 01438 762 461 * * .oooO Oooo. Mobile: 0498 725 047 * *--( )---( )-----------------------------------* \ ( ) / (Quote: Sir James Dewar) \_) (_/

2 1

Net App and NetBackup
by Michael Salmon 26 Feb '99

26 Feb '99

I wondered if anyone was using NetBackup with their filers. We are currently using Networker but are sufficiently dissatisfied that we going to look at NetBackup and I am interested in any problem that others have encountered. /Michael

7 8

Re: Nitech XRP1000 filer
by sirbruce＠ix.netcom.com 26 Feb '99

26 Feb '99

On 02/25/99 08:34:50 you wrote: > > > >>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> > >>> To open a real can-of-worms, what would people on this list like to see in >>> a low-end product offering? (Sub-$10k chassis). > >>This hypothetical discussion would be of great interest to me. :-) > >I'll take a crack at it: > >PC-ish Mini-tower not to exceed 19" high (so it could be rack mounted on its side) >Lower-end Alpha or medium Intel processor (whatever's cheaper for NetApp) >256 MB RAM >4-8MB NVRAM >Single 10/100 Ethernet >Single SCSI Bus >Up to 7 9GB (or larger?) disks >A couple of PCI slots for other types of network interfaces, and/or SCSI Tape. > >Make it one box, disks and all. I thought they already did this. It was called the F210. :) My personal experience with those admins who are "cheap" either by nature or by force is that such a small box doesn't appeal to them for a variety of reasons. They don't need high-performance at that end of the scale, so they can cobble together a server with cheaper ethernet cards and disks that work "just as well". They may not get RAID, but they rarely need it. Then the inevitable happens... they want to add more disk that it can take. They feel resentful that they can't add more disk, even though they think the CPU can handle it. The have no qualms about stringing 21 drives off an old Pentium with an ISA ethernet card if they can get away with it. And of course they want to use *their* cheap disk, not what Netapp wants for the performance. And then when the load gets too great or it crashes, they want to blame the vendor(s) and netapp. And then they get resentful if you tell them they have to upgrade the whole server to handle the increased load of the increased disk and users... they want to just put in more memory, or swap the CPU, and be done with it! I'm not saying Netapp can't make some more inroads into the low-end. I think they can and will, eventually. But there's a large contigent out there who always think they can get away with doing it cheaper by putting together their own linux box with a bunch of disks. Sometimes they can get away with it; sometimes they can't. If netapp can design a low-end box that uses cheaper components and perhaps has optional RAID but still at reasonable (not great) performance, they might be able to make some headway. But the margin will be small. Bruce

3 2

atime updates - OT 5.1.1 / NFS / FreeBSD
by Brett Rabe 26 Feb '99

26 Feb '99

Greetings. Is it the correct NFS behavior for non-uid-0 users opendir() calls to not update st.st_atime, but uid-0 opendir() calls to do so? I've got a filesystem mounted from the NetApp to the FreeBSD machine, exported as: /vol/vol0/home -access=client_hostname,anon=0 It's mounted on the client rw,intr,nfsv2. When I run a program as uid 0 that does simply an opendir()/closedir() on a directory, the directory's st.st_atime gets updated. When I run the same program as uid > 0 (in this case, 51, to be exact), atime does not get updated. I'm obviously missing my NFS roll here. Whassup with that? Shouldn't client requests as non-uid 0 also update atime? (Because I know somebody will ask, no_atime_update is not set on the volume. :) ) Am I just plain not understanding the man pages? Brett --- Brett Rabe Email : brett(a)uswest.net Systems Administrator - U S West Phone : 612.664.3078 Interact - 3S Pager : 612.613.2549 600 Stinson Blvd. Fax : 612.664.4770 Minneapolis, MN 55413 USA Pager : page-brett(a)uswest.net Bombs don't kill people. Explosions kill people.

2 2

Re: Nitech XRP1000 filer
by Tony Paolucci 25 Feb '99

25 Feb '99

>>> Dave Hitz <hitz(a)netapp.com> 02/24 9:32 AM >>> >> To open a real can-of-worms, what would people on this list like to see in >> a low-end product offering? (Sub-$10k chassis). >This hypothetical discussion would be of great interest to me. :-) I'll take a crack at it: PC-ish Mini-tower not to exceed 19" high (so it could be rack mounted on its side) Lower-end Alpha or medium Intel processor (whatever's cheaper for NetApp) 256 MB RAM 4-8MB NVRAM Single 10/100 Ethernet Single SCSI Bus Up to 7 9GB (or larger?) disks A couple of PCI slots for other types of network interfaces, and/or SCSI Tape. Make it one box, disks and all. Don't worry about hot-swap or hot spare disks. If you're buying at this end of the market, down time probably costs you less than it does the big-boys. Instead, sell a cold-spare disk which sit on the shelf until they need it. If it saves mfg costs, solder the memory, nvram & ethernet to the motherboard. Ship a single config. With a max usable of +/- 50GB a box like this could be a departmental fileserver, or a NetCache box for small to medium organizations who don't need/want a big NetApp for the job. I don't know how close this comes to the $10K figure. It's probably closer to $20K maxed with disks. Still, that's my .$.02 worth Tony Paolucci System Administrator, Growth Management, Metro, Portland, Oregon

3 2

Re: budtool 4.6 / ndmp /restore
by dnb＠ccs.neu.edu 25 Feb '99

25 Feb '99

Douglas Ritschel <djr(a)research.bell-labs.com> writes: > We seem only to be able to restore files, that were backed up from our > Netapp 760 filer, to their original location on the Netapp. If I try to > restore a file to a different location on the Filer, than the location > that it was backed up from, I receive an error message saying that the > machine is not running ndmp. And the restore fails. > > Does anyone have experience with this? We had some interesting restore problems until we found out that you must create an "etc" directory at the top of each of your volumes (at least in 5.1.2* with Budtool 4.6). The filer will then create a "tmp" dir for you in that etc dir and use it as a staging area for your restore. Fascinating, no? Peace, dNb

3 2

budtool 4.6 / ndmp /restore
by Douglas Ritschel 25 Feb '99

25 Feb '99

We seem only to be able to restore files, that were backed up from our Netapp 760 filer, to their original location on the Netapp. If I try to restore a file to a different location on the Filer, than the location that it was backed up from, I receive an error message saying that the machine is not running ndmp. And the restore fails. Does anyone have experience with this?

2 1

RE: Net App and NetBackup
by Daisy Nguyen Davis 25 Feb '99

25 Feb '99

I DO NOT recommend Budtool! I have been using Budtool in the last 4 years. From the beginning, the support was wonderful even though the product was just so so. But since Budtool splits into 2 companies: budtool and Intelliguard, I have had many bad experiences with both product and support from Intelliguard. Many of their experience tech supports are gone. The new ones are nasty and inexperience. In my opinion, the product is not worth the headache. Daisy --------------------------------------- From: "Raymond Brennan" <ray_brennan(a)mentorg.com> Subject: RE: Net App and NetBackup MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 In-Reply-To: <199902251256.NAA15704(a)uabs78c65.uab.ericsson.se> Sender: owner-toasters(a)mathworks.com Precedence: bulk X-Mozilla-Status2: 00000000 part text/plain 619 Press <return> to show content... I have been using Budtool from Intelliguard and can heartily recommend it-very stable, very easy to use and well supported. Raymond >-----Original Message----- >From: owner-toasters(a)mathworks.com >[mailto:owner-toasters@mathworks.com]On Behalf Of Michael Salmon >Sent: Thursday, February 25, 1999 12:57 PM >To: toasters(a)mathworks.com >Subject: Net App and NetBackup > > >I wondered if anyone was using NetBackup with their filers. We are >currently using Networker but are sufficiently dissatisfied that we >going to look at NetBackup and I am interested in any problem that >others have encountered. > >/Michael >

5 6

Problems w/ NetApp & BudTool 4.6
by Jason D. Kelleher 25 Feb '99

25 Feb '99

On the evening of Saturday February 20 we upgraded from BudTool 4.5 to 4.6. Since then, we've not been able to do local NDMP backups on our filer. Anyone out there experience similar problems? If so, would you please throw some suggestions my way. We have support calls open with both NetApp (being very helpful considering it's probably not an issue with their system) and Intelliguard (with what we pay them I'd assume they could at least hire warm bodies). Here's what we've come up with so far: 1) Intelliguard told us to add the line "ROBOT_SCSI_LUN 1" to the jbmgr_config for the filer. This allowed the jbmgr daemon to start. audreyii: /usr/budtool/bud [225] % cat jbmgr_config.audreyii.2 ROBOT_DEV_HOST nfssrv1 ROBOT_DEV_NAME spt0 ROBOT_SCSI_ID 2 ROBOT_SCSI_BUS 2 ROBOT_SCSI_LUN 1 DATA_DEV_NAME0 nrst0a DATA_DEV_HOST0 nfssrv1 PASSWORD xxxxxxxx USEBARCODE N VALIDATECMD "$BTHOME/bin/jbupdate audreyii:2 -a" audreyii: /usr/budtool/bud [226] % 2) Running the BudTool probe-scsi command shows the devices: audreyii: ~ [230] % probe-scsi -h nfssrv1 Copyright (c) 1990-1999 by Intelliguard Software Inc. probe-scsi BudTool 4.6 SCSI Bus 0 SCSI Bus 1 SCSI Bus 2 Target 2 Unit 0 Removable Tape EXABYTE EXB-8500 CC37 Unit 1 Removable Jukebox Device EXABYTE TZ Media Changer CC37 SCSI Bus 3 SCSI Bus 4 audreyii: ~ [231] % 3) After placing 2 labled BudToool tapes into the jukebox, running jbupdate returns instantly showing no tapes in the jukebox (doesn't even attempt to read tape labels). audreyii: ~ [236] % jbupdate audreyii:2 -a ------------------------------------------------------------------ ------ W A R N I N G ------- You have selected to force an update on all 5 tapes. This process requires several minutes per tape for unbarcoded tapes. Large jukeboxes with unbarcoded tapes can take several hours. The PID of this process is 8721. Use a HUP, INT, TERM or QUIT to terminate this process if you do not want to continue. ------------------------------------------------------------------ Update complete. audreyii: ~ [237] % jbmgr -H audreyii:2 ls -a 0: 1: 2: 3: 4: audreyii: ~ [238] % 4) We can perform remote NDMP backups to our BudTool master media server, but this isn't practical at ~2.2 GB/hr with 70+ GB on our filer. (It's an old, slow F330 which I'm supposed to be replacing instead of trouble-shooting...) 5) Gave Intelliguard a copy of our config file, the jbmgr diag log, and the probe-scsi output for analysis. The diag file does show some errors: 6) After not receiving much help from Intelliguard, we called NetApp. They sugggested we upgrade from 5.1.2P2 to 5.1.2R3P1 to remove the possibility that this was related to an NDMPD bug (6417). 7) Spoke to Intelliguard again Monday and informed them that we were going to upgrade the filer. We decided to see if the upgrade solved the problem. (They managed to fix a btcp issue after I waited 4 hours for a call back -- I'm still waiting for our sales rep to tell me exactly what kind of turn around to expect when paying extra for 24x7 support.) 8) Nothing changed after the upgrade Monday night. I informed NetApp; they opened another call and had us send them more info. 9) Told Intelliguard, gave them another copy of the diag file. 10) Configured BudTool to do lev 1 remote backups of the filer, this should hold us until the weekend. 11) Had to take a personal day Tuesday (for personal reasons). Hoped I get a couple voice/e-mails telling me that someone figured out what was wrong. (Finding out we were stupid and didn't have BudTool configured correctly would have been a relief.) 12) Wednesday we received some follow-up calls from NetApp, the call was escalated, and we're currently expecting a call. 13) We verified that tapes can be manually loaded into the jukebox drive and dump run on the console of the filer. Pretty confident that the jukebox didn't coincidentally die during the BudTool upgrade. 14) Will file missing persons reports for Intelliguard employees in another 24 hours. (Anyone have the number for the police in Dublin, CA?) So far, I'm confident it's a BudTool issue. (Many thanks/apologies to NetApp if it is.) I'd be very grateful if someone could give me a possible avenue of investigation. I'm at a dead-end and looking at over 30 hours of backups to lev 0 our filer this weekend... :( thanks, jason --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Partners, G.P. 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 February 1999