Is anyone else having this problem?
We have 2 clustered F740s running 5.3D11 that are backed up via
Budtool 4.6, and one of them (bonnie) reboots about every 10 to 15 days
during backups. It isn't restricted to a particular level of dump, time
of dump, or seemingly anything else non-randomly reproducible :( I've
now sent several cores off to netapp for analysis, and to all I've
received the same reply:
Bug 16084. Problem is that 3 args were expected, but only 2
were given. The following message is what it was trying to
print out:
"Your dump succeeded, but it could not update the table.
The data is safe, but this dump cannot be the base of a
future incremental, unless you update the table by hand."
Now, the immediate thing every engineer I've talked to has said was
"check the permissons on /etc/dumpdates". Of course, the permissions
on both boxes in the cluster are exactly the same, the dumpdates file
*has* been getting updated, there isn't an issue with space, pretty
much every reason we've been given as to why this is happening just ain't
so. Besides, the other 740 in the cluster hasn't had any problems with
backups as of yet (knock on wood). So, this leaves me wondering, has
anyone else seen this and if so, what's your configuration like?
Bleah,
Mark
Susquehanna Partners