| Randall,
WHAT YOUR ERROR MESSAGE TELLS ME:
================================
"brMiGetCallBack(): failed on error 89"
indicates to us as developers that Recovery Manager
failed in function brMiGetCallBack(), and received
a HUB_ERROR message at the time when your Hub900 script tried to
backup the Hub900 connection table.
TRANSLATION:
===========
It sounds like your hub(s) got into an incoherent state, where the
Hub900 backplane connection tables are hosed somehow. The error
you received occurs somewhere in the code that builds the SNMP
request/response packet, and is not one of the usual SNMP
errors seen by a client (bad value, no response, generrs, etc).
Here's a few thoughts on how the Hub900 got into an incoherent
state:
1) Did you pop a module in and out quickly, and not wait 15 or so
seconds before kicking off a backup operation? This can cause the
backplane connections to be in a state of flux (the connection
tables are rebuilt each time a device is removed or inserted),
and Recovery Manager was reading the Hub900 "Connection table"
when the connection tables were not in steady-state.
2) Was a module removed while in the middle of the backup
operation? Each module is backed up, and then the Hub900
last ... if a module was removed just prior to the backup
of the Hub900, the Hub900 could get into an incoherent state.
3) Have you completed a successful restore of a previously
saved configuration? This is important, because it would mean
that things were in a defined state and were working at one time,
and now they are not (versus "things never worked").
I would try the following to fix your problem:
- try to "reset to current settings" for the Hub900 backplane,
and once the hub comes up, try the backup operation again.
- if the backup still fails, and you have a backup file for the hub that
you were able to restore sucessfully, reset the Hub900 to
Factory Defaults, and try again.
============================================================
In the upcoming clearVISN Recovery Manager V2.0 release,
we've added more user-friendly text to our error messages,
and we are going to run the Hub900 consistency check
at restore time prior to restoring any devices. If we possibly
can, we'll try to run a similar consistency check at backup
time before any modules are backed up ... this would catch
your problem before any devices are backed up, but it's a case
of "sooner than later", and the Hub900 connections are still
hosed regardless.
Keep me posted on your progress.
John Gillis
clearVISN
|