On Fri, Mar 08, 2002 at 11:36:11AM +0100, Paul Bijnens wrote: > You broke the report off just too early :-)
Ah, well... > First Amanda said that it was writing md1 from host "cat" to tape > while it ran out of tape. > In the NOTES section of the Amanda report you'll find something > like: (cut from my last archive report) > > > NOTES: > > taper: tape ARCHIVE-040 kb 34115424 fm 111 writing file: short write > > driver: going into degraded mode because of tape error. The report I forwarded yesterday had: NOTES: planner: Adding new disk peterbilt://server/f$. planner: Last full dump of bradley:md10 on tape Daily08 overwritten on this run. planner: Adding new disk nova:hda1. taper: tape Daily08 kb 0 fm 0 writing filemark: Input/output error driver: going into degraded mode because of tape error. Which I'd say confirms that it didn't really run out of tape. > Or your capacity is for not-hardware compression, and you use both > hard- and software compression... resulting in LESS native capicity on tape. Is hardware compression controlled by the host or the drive? I'm currently using a Linux host and a Quantum DLT4000 drive; the drive's compression LED stays on (my predecessor set this up and I'm only now having the need to look closely at it), so I assume it's using hardware compression. So far, I've only been able to turn it off by using the drive's "Density Override" button; is there another/a better way? (Yeah, I would RTFdriveM, but I have no idea where TFM is. Disappeared before I got here.) > Or you ran into an error somewhere halfway the tape (bad tape? drive? computer?) > Look into the system logs to find out (dmesg, syslog, etc). It gets worse... This morning, I didn't have an amanda report waiting in my mailbox, so I tried to ssh to the tape host. No response. Go into the server room, punch it up on the KVM, and see a kernel panic. Looks like swap got hosed and the machine locked up while running the backup last night. *sigh*
