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