Hi.
I'll only suggest what to try to check if your tapes are ok for bacula.
Tom Morgan wrote:
...lots of stuff snipped
...15-Apr 09:17 drakul-sd: Please mount Volume "mp0008" on Storage Device "Sun L280" for Job hella.2005-04-15_01.05.06 15-Apr 09:19 drakul-sd: hella.2005-04-15_01.05.06 Fatal error: Fatal device error: ERR=label.c:202 Expecting Volume Label, got FI=0 Stream=0 len=64412
This is what I am getting when I try to mount the volume:
*mount mp0006
Nah... you don't give the volume name, hat's read from the tape, you give the device name...
... but in this case it didn't matter.Storage resource "mp0006": not found Automatically selected Storage: DLT-7000
3905 Device /dev/nst0 open but no Bacula volume is mounted. If this is not a blank tape, try unmounting and remounting the Volume.
Sorry, I'll not go through the whole of your configuration...
Well, I hat similar cases: For some reason, bacula wouldn't recognize the volumes in tape drives.
I found out the following:
- Tapes can - obviously - be damaged, though this should not happen with all your tapes.
- Sometimes, especially with certain tape drives, the drives choke when bacula tries to mount a device while it's still loading or calibrating a tape. More info below.
- Block sizes. I had tapes written with other block sizes than what I finally used, and once you insert one of these tapes you need to relabel them.
- The SD can choke. I think I saw this once or twice, but since I don't usually run the daemons with logging that's hard to verify, and I've never tried to reproduce such errors.
- Sometimes tha SD seems to be stuck when a tape drive is trated in a way it doesn't like, like doing a forced eject and loading of another tape while the device is opened by bacula. This might be scsi driver dependent, but see below...
A procedure I use when a tape is not recognized, which most often happens after I did something I should not have done:
1. Unmount using the console. When the console hangs and you are impatient, quit it using C-c and kill it from the shell. Restart, verify with "status storage". Wait. Wait longer, verify status again, sometimes the SD recovers.
2. mount from the console. When you get a status like "device in acquire" you need time and good nerves. Read further at 10.
3. If the tape label is not recognized as being a bacula label, unmount or release the device.
4. Use, from the shell, mt to verify the tape drives state and, very important, block size setting.
4.a) If it's wrong, unmount the tape and reload it, Check again.
4.b) If it's still wrong, use mt with the tape loaded to set the right values.
5. Use btape to try to read the tape label.
6. If btape doesn't give the proper label and you are sure that tape can be overwritten, like when the catalog says the tape is purged or recycled, use the label command from btape to assign the same label to he tape again.
7. Use readlabel from btape to verify the label. Note, preferrably on it's label, that the tape is probably damaged. If you again encounter problems with it, remove it from your pool.
8. Unload the tape, reload it, use mt and btape to verify it can be read now.
9. From baculas console, mount the tape. It should work now.
10. This situation took some effort to recover :-)
First, wait and see if the situation recovers by itself. Repeat until you run out of time or nerves.
11. If you don't mind, simply restart the computer with the tape attached. Goto step 2.
11. If that is not an option, but you can restart the SD alone, do that: use kill or bacula stop to stop bacula-sd. Verify all instances are shut down, then restart it. Start again at step 2.
12. If your tape drive is an external one, you can try turning it off, waiting a while, and turning it on again. Do _not_ remove SCSI cables, unless you know the stuff is meant for hot-plugging.
13. Verify the tape device is available to the kernel. Under linux, for example, do 'cat /proc/scsi/scsi' or dmesg. You can use commands like 'echo scsi add-single-device 0 0 4 0 > /proc/scsi/scsi' or similar to inform the kernel of it's presence if it is not listed. (Seriously, I had one such case: A hard disk on the scsi bus with some tape drives died, the scsi HBA reset and reset and reset, finally gave up, when one tape drive decided it wouldn't like that. Then, I managed to take the disk out of its volume group, reset the tape drive by power-cycling, added it o the driver like described, and my backup continued. Later verification showed the backup was ok. And yes, I do like old and unreliable hardware ;-)
14. Continue at step 2.
Well, that's an outline that should be modified according to your systemand knowledge. Looking in the systems log files might help, and having scsi drivers which can log their problems in a way you understand is also very helpful. I at least had some very interesting time reading the source code of linux' aic7xxx driver to see what the thousands of error log lines were telling me.
In fact, I was impressed how robust a linux system can be. Bacula itself also recovers from many hardware problems, but the timeouts in the drivers can be really long.
Of course, you will find that most problems come from damaged tapes, misconfiguration, and operator work in conjunction with funny hardware like tape drives that don't like being talked to while they load a tape.
Arno
-- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
