Hello, Thanks for responding. Also, thanks for providing such a useful program!
Kern Sibbald wrote:
You should do three things: 1. Run btape "test" and "fill" commands. The latter is very slow.
I have done both but I don't see any critical errors. But then again, maybe I am missing something. I didn't have time to run a multitape fill test but I plan on trying it later. As recommended, I turned off hardware compression before running the fill test.
I have attached the output of both commands, run with the '-v -p' options. At the end of the 'fill' test, I did see this in the syslog: btape: btape: End of Volume "TestVolume1" at 103:11361 on device /dev/nst0. Write of 64512 bytes got -1. But I assume its because btape encountered an EOF.
2. Look at your system log to see if you are getting any errors.
Besides the occasional "Key=8h (BLANK CHECK)" SCSI error when reading a blank tape, I haven't seen anything.
3. Turn on the directive in the default SD config file that checks
for tape alerts. It can provide early warning if you have bad tapes.
I have this in my Device resource: Alert Command = "sh -c 'tapeinfo -f /dev/sg5 | grep TapeAlert || true'" I'm still stumped. Thanks for you help.
On Wednesday 20 July 2005 03:37, Theron Toomey wrote:Hello, I'm seeing some strange behavior with restores under 1.36.3/RHEL 3 using an AIT-3 drive. I'm not quite sure what is causing it and I'd really appreciate any suggestions. When I choose restore option 5 (Select the most recent backup) bacula proceeds to restore data from the last full and subsequent diff/incr jobs. However, for large restores (>50 GB), I notice a few dozen error messages like: Error: attribs.c:339 File size of restored file /foo/bar not correct. Original [file size], restored [large, bogus file size]. Comparing the restores against the live data, I see that the restored files have lots of random garbage inserted/appended to them. However, when I manually find the jobIDs of the full/diffs/incrs and restore them individually with restore option 3, there is no corruption and the files all seem fine. Most of the corrupt files are older than the last full; Perhaps there's something in the diff/incr jobs that corrupts the files from the full job. However, most of the corrupt files are older than the last full and so are not even present in the diff/incr jobs. Has anyone seen behavior like this or have any ideas about where to look? Thanks!
-- Theron Toomey, System Administrator NSEES-IT (919-613-8148)
btape-fill.txt.gz
Description: GNU Zip compressed data
btape-test.txt.gz
Description: GNU Zip compressed data
