toasters

toasters@lists.teaparty.net

13520 discussions

Re: Will F760 work with IBM ADSM backup system?
by Mark Muhlestein 01 Mar '99

01 Mar '99

If ADSM can back up an NT member server via CIFS it should work. According to the ADSM FAQ I found: "4. Can ADSM backup remote machines? "ADSM does not have a specific remote backup function. Any remote NTFS file system access needs to appear to the ADSM client as a local NTFS. "Remote drives can be backed up." So it would probably work by mapping a drive from the filer. However, we haven't tested ADSM to my knowledge. The filer's NT backup also includes the ability to fully back up UNIX metadata. Paul Benn at Netapp has a white paper that describes how to use NT backup utilities with the filer. Paul, can you post a pointer to the toasters list? I can't seem to locate it. David's point about sparse files is correct: sparse files will be expanded when restored. For CIFS-created files that is not a problem since the clients can't create them (until Win2k). Mark -----Original Message----- From: David Drum <david(a)more.net> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Monday, March 01, 1999 8:44 AM Subject: Re: Will F760 work with IBM ADSM backup system? >Quoth Mike Ball: > >> Does anyone know if the F760 will work with the IBM ADSM backup system? > >There is no ADSM client for NetApps, so it would have to backup through >an NFS mount. > >> Has anyone had any experience with the IBM ADSM backup system >> and any Netapp filer? > >Please be aware that ADSM does not back up UNIX sparse files properly. >(Last time I checked anyway.)

1 0

nightly.1 busy: snapshot rollovers not happening
by Todd C. Merrill 01 Mar '99

01 Mar '99

Folks, What does this "busy" mean? bat> snap list Volume vol0 working.................................................... %/used %/total date name ---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Mar 01 11:01 hourly.0 0% ( 0%) 0% ( 0%) Mar 01 10:01 hourly.1 2% ( 2%) 1% ( 1%) Mar 01 09:01 hourly.2 14% (13%) 11% ( 9%) Feb 27 00:01 nightly.0 22% (15%) 19% (12%) Feb 26 00:00 nightly.1 (busy) The nightly snapshot apparently didn't roll over, and hence a lot of testing suites that we run that depend on an image at mignight are giving us out of date results. The word "busy" is not mentioned anywhere in the ontap html docs (NetApp Release 5.2.1: Thu Dec 31 12:56:45 PST 1998). I've searched the archives for this list, and hit upon a similar thread just a few weeks ago (RE: Shared Snapshot directory), but the discussion went off on backups, not why the rollover wasn't happening. I suspect it's a CIFS locking issue. So, is there a way to *force* the automatic nightly snapshot to rollover? If not, I guess I'll just hand-job this to do "manual automatic" snapshots at midnight and `snap rename` the busy ones. <sigh> What's the use of having the automated capability if it doesn't work when files are locked, he sarcastically muttered under his breath... ;) And, if nightly.1 is busy, how come nightly.0 wasn't just replaced with one dated "Mar 01 00:01" instead? I realize the implications to possible Windows clients: programs dying, BSODs, etc., but that's okay in this environment. And, since these areas are read-only, there should be no data loss, yes? And, how TF do I get rid of this without rebooting the filer? bat> snap delete nightly.1 Snapshot in use by dump or a CIFS share. It's ain't being dumped, and never has been, so it's a CIFS share issue. (`cifs sessions *` works. Wo-hoo! But, which one is holding that particular snapshot busy?) (1-month newbie to NetApp filers, still learning the intricacies... Thanks for listening.) Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

Will F760 work with IBM ADSM backup system?
by Mike Ball 01 Mar '99

01 Mar '99

Does anyone know if the F760 will work with the IBM ADSM backup system? The ADSM system is used to backup over 200 NT servers over the network, and we would like to use it to backup the F760 filer running CIFS. Has anyone had any experience with the IBM ADSM backup system and any Netapp filer?

2 1

Re: Problems w/ NetApp & BudTool 4.6
by Jay Sekora 01 Mar '99

01 Mar '99

Garret Flynn <flynng(a)iol.ie> wrote: > I think your looking for BudTool46-2 > > $ more BudTool46-2.README [snip] > > * [PR 7273] btmerge fails for media server names that include "." [snip] > The bad news is that I checked today and this patch is no longer in > ftp://ftp.iguard.com/pub/dist/patch/BudTool/BudTool46 > Anymore. Intelliguard gave us a copy of this patch, and it didn't solve the problem for us. The merge still died. We changed to unqualified names, and then it started working. So the patch did *not* perform as advertised. I'm really happy with the way our backups are running now that we finally have BudTool working properly, but I am *not* impressed with Intelliguard's technical support or QA. (BTW, a hideous workaround for backing up NetApps across multiple DNS domains would be to give the toasters all CNAME entries in the domain the BudTool host was in.) -j. Jay Sekora <jay(a)ccs.neu.edu> Unix Systems Administrator Northeastern University College of Computer Science

1 0

DELL<->NetApp deal?
by Philip Thomas 28 Feb '99

28 Feb '99

Can NetApp provide some more details on this DELL <->NetApp announcement? http://www.dell.com/corporate/media/newsreleases/98/9811/04.htm http://www.netapp.com/news/level3b/news_rel_981104.html (a) Are they going to take say, a 740 stick Dell label on it and sell? (b) Is this going to replace Dell's disk subsystem? In which case the NetApp/disks are no longer a "network attached" system. Am I right? (c) Will this NetApp disk system from Dell loose any of NetApp's features, namely '.snapshot'.? (d) I would assume Dell system; no speak NFS?? Philip Thomas Motorola - PEL, M/S M350 2200 W. Broadway M350 Mesa, AZ 85202 rxjs80(a)email.sps.mot.com (602) 655-3678 (602) 655-2285 (fax)

2 1

RE: DELL<->NetApp deal?
by Melvin, Grant 27 Feb '99

27 Feb '99

(d) I would assume Dell system; no speak NFS?? Yip, one of the reasons that we are producing papers such as "How to Integrate a Network Appliance Filer into the Windows NT Backup Model". Check it out at: http://www.netapp.com/technology/level3/3052.html Cheers, Grant

1 0

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

26 Feb '99

In message <36D6915F.EA2416A6(a)iguard.com>, James Lowe writes: >Would anyone from Network Appliance care to comment on anything about >this thread? > >Yours waiting in anticipation > >James Lowe >Intelliguard Software International I'm not from NetApp, but I'd love to comment... We recently (Saturday) upgraded from BudTool 4.5 to 4.6. After Shona told us to check the jbcap file (care to comment why AFTER 6 DAYS NO ONE AT INTELLIGUARD HAD HELPED US!!!), so BudTool 4.6 could control the jukebox on our filer we have the following systems running: BudTool 4.6 SunOS 4.1.3_U1, Solaris 2.5.1, 2.6, & 2.7 OnTap 5.1.2R3P1 (recommended by NetApp support) The NetApp is working great. The only problems we're currently having regard errors in the btmerge reports: ============================================= ============================================= Running btmerge for host hercules.dev.susq.com Command: (btmerge -s / -o /audreyii/budtool/hist/hercules.dev.susq.com/db.hercules.dev.susq.com.n.of.m.tm p -m /audreyii/budtool/hist/hercules.dev.susq.com/db.hercules.dev.susq.com.n.of.m -H hercules.dev.susq.com -c /usr/budtool/bud/.budfclass -i /usr/budtool/hist/db.hercules.dev.susq.com -i /usr/budtool/build/db.her cules.dev.susq.com.int.0) ****************************************************************** ------ E R R O R ------- Cannot get maximum file history database continuation number: (Error 0) ****************************************************************** ****************************************************************** ------ E R R O R ------- A btmerge input file was busy. Rebuilding list of input files. ****************************************************************** ============================================= ============================================= These are refering to a Solaris 2.6 system with a FQDN in the .buddb. After removing all FQDNs from our .buddb, everything worked fine. So, I think you should quite pointing fingers at NetApp and FIX THE PROBLEM! 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 >Shona McNeill wrote: >> >> "Shaun T. Erickson" <ste(a)research.bell-labs.com> writes: >> > >> > When I upgraded to BudTool 4.6, my file history database merges failed >> > too, except for one system. That one system's name was not fully >> > qualified, so it's merges worked. All the merges failed for systems wit >h >> > fully qualified host names. This is as seen in $BTHOME/hist. First, a >> > patch to BudTool's patch program was required. Then, they gave me a "on >e >> > off" patch, to make the merges work. It did, except that when my >> > toaster's database was converted to the 4.6 format and the saved up fil >e >> > histories were merged in, the size grew past 500MB and the database for >> > that system split in two. So far so good. Then that system's file >> > history merges failed again, this time because the continuation file ha >d >> > a bad magic number. >> > >> >> We have just installed BudTool 4.6 from scratch, hosted on a Sun running >> Solaris 7, backing up one of our newly-installed NetApps, all of which >> shipped running 5.1.2R3. >> >> Once we'd fixed the jbcap file and could actually talk to the jukebox, we >> found that history merges fail with msrt coredumping. >> >> We _are_ using FQDNs, but then this one copy of BudTool will be eventuall >y >> controlling backups for NetApps in different subdomains, so not using FQD >Ns >> is not really an option here. >> >> Iguard have mentioned nothing of patches, their answer is for us to upgra >de >> the filer to 5.2.1 as "BudTool is certified against that version". >> (We refused their first suggestion to downgrade the filer to 5.1.2P2.) >> >> I am loathe to schedule downtime on a busy filer for what may prove an >> unnecessary upgrade. Is there anyone out there using BudTool 4.6 with fi >le >> histories _and_ FQDNs _and_ a filer running 5.2.1 who can comment on whet >her >> this upgrade will have any effect on the problem whatsoever? >> >> Shona McNeill >> -- >> shona(a)netline.net.uk

3 2

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

26 Feb '99

James, Ummm.... I'm a bit confused... You responded to me, or so it seems, but many of the snipets of text you referred to in the first half of your message aren't from me, or the message I sent...? And I beleive we were discussing the problem of btmerge failing for systems with FQDNs. I know nothing about the "one off" patch for merges. Not surprising since it took tech support 3 days to inform us about the "one off" for the btcp failures we reported on Saturday... The text reffering to the "one off" patch was nowhere in the message I sent. I didn't complain about any "KNOWN PROBLEM WITH THE ONTAP OS PRIOR TO 5.1.2P2". We aren't running OnTap version prior to 5.1.2P2... Who were you responding to...? As for having to wait 6 days... We did call Intelliguard several times a day, only to be put through to voice mail. These messages were rarely returned. I spent 4 hours trying to get in touch with support personnel Monday (after I got tired of waiting for a call back from Sunday). After leaving several voice mails I decided to try and speak to a manager, I was told they were busy and asked if I'd like to leave them voice mail.... The only human being working for Inelliguard I could get a hold of was our regional sales rep and it took him another hour to get someone to call me (17:00 EDT)... Would you like further explanation for my "rude, arrogant, & cynical attitude"...? Forgive me, but I beleive I'm very polite the first 2-3 times I call tech support regarding an issue. I start getting sarcastic around the 4th call and rude around the 6th call for any specific problem. I've been told I need to work on my patience. Notice, I'm not complaining about your attitude. While working, I could care less what someone's attitude is as long as they get the job done. I go home to be around nice people. At work I expect people to do their jobs... By the way, I'm still trying to find out what the expected response time for a call to Intelliguard 24x7 support is...? (You know, that service that you charge extra for...) If I'm told it's 4 or more hours, I'll gladly apologize and expect less in the future. You are correct that the version of OnTap, 5.1.2R3P1, we are running is not officially certified by NetApp & BudTool. I'm sorry if my message implied that it was. I meant to point out the fact that this combination of OnTap & BudTool has no btmerge problems as long as no FQDNs are used. Oh well, we are currently not having any problems with BudTool 4.6. Intelliguard support fixed our btcp problem, Shona fixed our jbcap problem, and the various people discussing the FQDN issues took care of that for us. If I'm lucky, I won't need to speak to Intelliguard until I have to get new keys for some jukebox licenses and I think that can be done via email. have a good weekend, jason P.S. I'll now refrain from commenting on BudTool, I'm starting to take this too personally -- understandable since I've spent more time with BudTool than my girlfriend this week.... In message <36D70609.22997A9A(a)iguard.com>, James Lowe writes: >errr..sorry Mr Kellerher, I thought the problem that we were discussing >was core dumps from BudTool due to 'bad' Filehistory streams from the >filers found by the NetApp tech team and resolved in the P2 patch of >5.1.2P2. > >> >> >First, a >> >> > patch to BudTool's patch program was required. > >Oh dear me..software that needs patches...now that is unheard of isn't >it? > >> >>Then, they gave me a "one >> >> > off" patch, to make the merges work. It did, > >Patches that work?..my oh my..whatever next > >> >>except that when my >> >> > toaster's database was converted to the 4.6 format and the saved up >fil >> >e >> >> > histories were merged in, the size grew past 500MB and the database >for >> >> > that system split in two. So far so good. Then that system's file >> >> > history merges failed again, this time because the continuation file > ha >> >d >> >> > a bad magic number. > >..and guess what...this is a KNOWN PROBLEM WITH THE ONTAP OS PRIOR TO >5.1.2P2 > >And if you are really really lucky you might see all the CPU sucked out >of your BudTool machine by BudTool's merge binaries as it tries to >negotiate 'bad' filehistory datastreams from the filer. You can watch >your network grind to a halt as your NFS falls over and see your >precious disk space fill up with a lovely juicy core file fresh from the >MSRT oven. > >Now that was us producing the core file we have never denied that, but >instead of..as you so elegantly put it...let me see.. > >ah yes.. > >> So, I think you should quite pointing fingers at >> NetApp and FIX THE PROBLEM! > >We didn't point fingers oh no...through what is known as 'cooperation' >and being 'proactive' Intelliguard AND Network Appliance worked on it... >and you know what? 5.1.2'P2' was produced but nothing was needed for >BudTool note. You see NDMP is a 'joint' effort (not just with >Intelliguard and NetApp I might add) And you know what else? We did the >same with NetApp for 5.1.2..we worked together and now we are working >towards OnTap 5.3...now I don't know exact figures, but i reckon that >between 5.0.1 and 5.1.2 there have been a few dozen P and R and D (and >whatever else letters you care to use) patches for OnTap, some of them >making quite significant changes to the filer I believe and some of them >out less than 24 hours after the previous ones. If ANY software company >could test against all these different versions in such a short space of >time I would be very impressed. Indeed some of these extra patches from >NetApp were to fix bugs in previous patches a days earlier. > >As far as I am aware (and you will need to verify with NetApp about this >I suppose as you obviously have no time for Intelliguard). This release >of OnTap that you have been recommended by NetApp has not been certified >(as far as I, or any of the team in Europe have been informed anyway) >against BudTool 4.6. So far be it for me to start advising people to >upgrade to *Operating systems* that may or may not work with our >product. > >You may not care about any of this, and just want a fix, fair enough. >However, before you start 'spouting off' at people like myself who do >try and genuinely help as much as we possibly can can I point out one >last thing please... > >> (care to comment why AFTER 6 >> > DAYS NO ONE AT INTELLIGUARD HAD HELPED US!!!) > >I won't defend genuinely poor 'support' from Intelliguard ever, >especially if you have paid for the maintenance, however why did you >have to wait 6 days anyway? If the problem was so urgent as you have >blatantly made obvious it was, why were you not on the phone, email >bombarding the support team until you had your answer?, getting cynical, >rude and arrogant as you do so well on this mailing list and even ask to >be put on hold until a 'manager' was made available to you? You may say >you shouldn;t have to, and I would agree whole heartedly...but life's >funny like that jason...sometimes it lets you down.. > >Have a good weekend > >James Lowe >Intelliguard Software International > >Jason D. Kelleher wrote: >> >> In message <36D6915F.EA2416A6(a)iguard.com>, James Lowe writes: >> >Would anyone from Network Appliance care to comment on anything about >> >this thread? >> > >> >Yours waiting in anticipation >> > >> >James Lowe >> >Intelliguard Software International >> >> I'm not from NetApp, but I'd love to comment... >> >> We recently (Saturday) upgraded from BudTool 4.5 to 4.6. After >> Shona told us to check the jbcap file (care to comment why AFTER 6 >> DAYS NO ONE AT INTELLIGUARD HAD HELPED US!!!), so BudTool 4.6 could >> control the jukebox on our filer we have the following systems >> running: >> >> BudTool 4.6 >> >> SunOS 4.1.3_U1, Solaris 2.5.1, 2.6, & 2.7 >> >> OnTap 5.1.2R3P1 (recommended by NetApp support) >> >> The NetApp is working great. >> >> The only problems we're currently having regard errors in the >> btmerge reports: >> >> ============================================= >> ============================================= >> Running btmerge for host hercules.dev.susq.com >> >> Command: (btmerge -s / -o /audreyii/budtool/hist/hercules.dev.susq.com/d >b.hercules.dev.susq.com.n.of.m.tm >> p -m /audreyii/budtool/hist/hercules.dev.susq.com/db.hercules.dev.susq.co >m.n.of.m -H hercules.dev.susq.com >> -c /usr/budtool/bud/.budfclass -i /usr/budtool/hist/db.hercules.dev.susq >.com -i /usr/budtool/build/db.her >> cules.dev.susq.com.int.0) >> >> ****************************************************************** >> ------ E R R O R ------- >> Cannot get maximum file history database continuation number: (Error 0) >> ****************************************************************** >> ****************************************************************** >> ------ E R R O R ------- >> A btmerge input file was busy. >> Rebuilding list of input files. >> ****************************************************************** >> ============================================= >> ============================================= >> >> These are refering to a Solaris 2.6 system with a FQDN in the >> .buddb. After removing all FQDNs from our .buddb, everything >> worked fine. So, I think you should quite pointing fingers at >> NetApp and FIX THE PROBLEM! >> >> 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 >> >> >Shona McNeill wrote: >> >> >> >> "Shaun T. Erickson" <ste(a)research.bell-labs.com> writes: >> >> > >> >> > When I upgraded to BudTool 4.6, my file history database merges fail >ed >> >> > too, except for one system. That one system's name was not fully >> >> > qualified, so it's merges worked. All the merges failed for systems >wit >> >h >> >> > fully qualified host names. This is as seen in $BTHOME/hist. First, >a >> >> > patch to BudTool's patch program was required. Then, they gave me a >"on >> >e >> >> > off" patch, to make the merges work. It did, except that when my >> >> > toaster's database was converted to the 4.6 format and the saved up >fil >> >e >> >> > histories were merged in, the size grew past 500MB and the database >for >> >> > that system split in two. So far so good. Then that system's file >> >> > history merges failed again, this time because the continuation file > ha >> >d >> >> > a bad magic number. >> >> > >> >> >> >> We have just installed BudTool 4.6 from scratch, hosted on a Sun runni >ng >> >> Solaris 7, backing up one of our newly-installed NetApps, all of which >> >> shipped running 5.1.2R3. >> >> >> >> Once we'd fixed the jbcap file and could actually talk to the jukebox, > we >> >> found that history merges fail with msrt coredumping. >> >> >> >> We _are_ using FQDNs, but then this one copy of BudTool will be eventu >all >> >y >> >> controlling backups for NetApps in different subdomains, so not using >FQD >> >Ns >> >> is not really an option here. >> >> >> >> Iguard have mentioned nothing of patches, their answer is for us to up >gra > >de >> >> the filer to 5.2.1 as "BudTool is certified against that version". >> >> (We refused their first suggestion to downgrade the filer to 5.1.2P2.) >> >> >> >> I am loathe to schedule downtime on a busy filer for what may prove an >> >> unnecessary upgrade. Is there anyone out there using BudTool 4.6 with > fi >> >le >> >> histories _and_ FQDNs _and_ a filer running 5.2.1 who can comment on w >het >> >her >> >> this upgrade will have any effect on the problem whatsoever? >> >> >> >> Shona McNeill >> >> -- >> >> shona(a)netline.net.uk

1 0

Nitech XRP1000 filer
by Brian Tao 26 Feb '99

26 Feb '99

Has anyone used the XRP 1000? It's Nitech's "answer" to the Netapp (the even mention Network Appliance specifically as the market leader in network-attached storage, and that they compete with Netapp). http://www.nitech.com/online/Company/Storage/XRP_1000/body_xrp_1000.html -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

9 12

Re: Problems w/ NetApp & BudTool 4.6
by James Lowe 26 Feb '99

26 Feb '99

Mr Blank-Edelman, et al, I am so sorry, this is not the patch. It has been one of those months for me.. %^& I should not be so quick to jump in I suppose. My apologies for wasting your time. Yours, eating humble pie James Lowe Intelliguard Software International David N. Blank-Edelman wrote: > > James Lowe <jlowe(a)iguard.com> writes: > > > ftp.iguard.com/pub/dist/patch/BudTool/BudTool46/BudTool46-3 > > Sorry, which does what? Is a new patch? The others we tried a while > back did not allow for successful merges. We're ok with not using a > FDQN now, but it was problematic when we first tried to use your > product. > > Respectfully, > David N. Blank-Edelman > Director of Technology > College of Computer Science > Northeastern University

3 3

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