toasters

toasters@lists.teaparty.net

13513 discussions

Re: nightly.1 busy: snapshot rollovers not happening
by Mark Muhlestein 01 Mar '99

01 Mar '99

>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... ;) No, it's probably because you have a CIFS share defined on the snapshot. >It's ain't being dumped, and never has been, so it's a CIFS share issue. Exactly. Doing 'cifs shares' should show you the share defined on the snapshot. (For NFS folks, a CIFS 'share' corresponds to an NFS 'export'.) You can do a 'cifs shares -delete sharename' to remove the share. >(`cifs sessions *` works. Wo-hoo! But, which one is holding that >particular snapshot busy?) Snapshots can't be held from expiring by open files. It's the fact that a share is defined on the snapshot that is the problem here. (Another good question for the FAQ I guess.) Mark Muhlestein -- mmm(a)netapp.com

2 1

Re: nightly.1 busy: snapshot rollovers not happening
by Patrick.Day.B＠bayer.com 01 Mar '99

01 Mar '99

I ran across this same problem when i shared the Nightly.0 for backup purposes. When the nightly.0 rolls over to the Nightly.1, the CIFS share keeps track and actually keeps the share mapped to nightly.1. (same thing next night when it rolls over to nightly.3). I posted the problem a few weeks ago and the only "solution" anyone could come up with was running an rsh command to stop and recreate the share every time the backup runs. I opted to forget the snapshot directory backup and go with a live backup of the C$\ share. --Patrick Day owner-toasters(a)mathworks.com on 03/01/99 01:34:39 PM Please respond to "DDA.RFC-822=tmerrill(a)mathworks.com/P=Internet/A= /C=us" @ X400 To: "DDA.RFC-822=toasters(a)mathworks.com/P=Internet/A= /C=us"@X400 cc: "DDA.RFC-822=tmerrill(a)mathworks.com/P=Internet/A= /C=us"@X400 Subject: nightly.1 busy: snapshot rollovers not happening 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

RE: Will F760 work with IBM ADSM backup system?
by Benn, Paul 01 Mar '99

01 Mar '99

Here's a link: http://www.netapp.com/technology/level3/3052.html Please keep in mind, though, that a more current version of this white paper will be posted within the next few days. Once it's posted (official), there will be a link to it on the "technology/applications" page: http://www.netapp.com/technology/apps.html Regards, Paul -----Original Message----- From: Mark Muhlestein [mailto:mmm@netapp.com] Sent: Monday, March 01, 1999 9:12 AM To: toasters(a)mathworks.com Subject: Re: Will F760 work with IBM ADSM backup system? 8><----snip----snip----snip---- 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. 8><----snip----snip----snip----

1 0

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

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