In message 36D6915F.EA2416A6@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@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@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@netline.net.uk