>The /dev/sda5 (/usr) partition misbehaves in the same way, so I did: > >dump 0usf 1048576 - /dev/sda5 | restore -tvf -
First, do **not** use the 'u' option when testing like this. That updates /etc/dumpdates and will really screw up the incremental scheduling. You should do an "amadmin <config> force ..." to get this straightened out. >It ran, spit stuff out and then ended with: >... >leaf 478498 ./kerberos/sbin/sserver >leaf 176 ./tmp > DUMP: Broken pipe > DUMP: The ENTIRE dump is aborted. That could be perfectly normal. The directory information is all at the beginning of a dump image. Some versions of restore, when running in 't' (catalogue) mode, will just terminate when they have everything they need. That propogates back to dump as a broken pipe. This would be a more accurate test: dump 0sf 1048576 - /dev/sda5 | (restore -tvf - ; cat > /dev/null) As to your original problem, I agree with Joshua that it sounds like a gzip problem. Note the following: compress got signal 24 What is signal number 24 on your OS (grep -w 24 /usr/include/sys/signal.h)? My next guess would be that you've hit a 2 GByte boundary someplace. How much data are you dumping on the file systems that fail? Are there some that are under 2 GBytes that work? > runtar: error [must be invoked by operator] As Joshua said, this has got to be a problem for doing backups of that client. When you built Amanda for that client (however that happened), it was told it would be run by "operator". That isn't happening and runtar is failing. This would only affect the backups done with GNU tar (/home), but it is fatal for that one. You either need to rebuild Amanda for that client and set --with-user to "backup" or start running amandad as "operator" on that client. > [EMAIL PROTECTED] John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
