>Hi! I just started using amanda on Monday night. ...
Welcome!
>... the dump summaries all had the same
>error: index tee cannot write. The only other error listed was
>"/usr/sbin/ufsdump returned 3". ...
I suspect the "index tee cannot write" error is just a related symptom
of the "ufsdump returned 3" error, so we'll ignore that for now.
Wasn't there some more stuff in the "FAILED AND STRANGE DUMP DETAILS"
section of the E-mail?
One of our disks happened to do this ("ufsdump returned 3") a few
days ago. It was accompanied by a mess of messages like this:
? DUMP: bread: dev_seek error: Error 0
| DUMP: Warning - block 1348685612 is beyond the end of `/dev/rdsk/c0t0d0s4'
Did you see something like this?
While this looks seriously broken :-), what it really means is the file
system was very active and ufsdump just doesn't handle that very well
(which Sun should fix, but that's a different story). Ufsdump grabs a
disk block it thinks is full of indirect disk block pointers, but it's
been reallocated by the OS as data. Needless to say, seeking to disk
address "Hi mom, send money" doesn't work well :-).
In our case, we had some control over the activity and just moved it
away from the backup timeframe. Or we could have given Amanda a start
time to have it start later than the active period.
This is usually more of a problem when doing full dumps than incrementals.
You could try to force Amanda into doing the full dump on days with lower
activity, but it's hard (for perfectly valid reasons) to convince Amanda
to do things your way instead of its.
As a last resort, you could use GNU tar for your problem file systems.
It will not suffer from the active file system issues as much as dump,
although it has other issues (the worst of which being that it destroys
the access time on anything it backs up).
>Ricky
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
