On 07/09/12 11:37, Martin Simmons wrote:
>>>>>> On Fri, 06 Jul 2012 11:12:35 -0700, Stephen Thompson said:
>>
>> On 07/06/2012 11:01 AM, Martin Simmons wrote:
>>>>>>>> On Thu, 05 Jul 2012 11:35:15 -0700, Stephen Thompson said:
>>>>
>>>> Hello again,
>>>>
>>>> Here's something even stranger... Another Full job logs that it's
>>>> written to a volume in the Full pool (FB0956), but then the status
>>>> output of the job lists a volume in the Incremental pool (IM0093). This
>>>> Incremental volume was never even mentioned in the log as a volume to
>>>> which the job despooled.
>>>
>>> It could be a database problem (the volumes listed in the status output come
>>> from a query). What is the output of the sql commands below?
>>>
>>> SELECT VolumeName,JobMedia.* FROM JobMedia,Media WHERE
>>> JobMedia.JobId=242323 AND JobMedia.MediaId=Media.MediaId;
>>>
>>> SELECT MediaId,VolumeName FROM Media WHERE Media.VolumeName in
>>> ('IM0093','FB0956');
>>>
>>
>> Looks like it did in fact write to the Incremental tape IM0093 instead
>> of the requested Full tape BUT logged that it wrote to a Full tape
>> FB0956. This begs the questions 1) Why is it writing to a tape in
>> another pool? and 2) Why is logging that it wrote to a different tape
>> than it did?
>
> You could verify that IM0093 contains the data by using bls -j with the tape
> loaded (but not mounted in Bacula).
>
> It looks like you have concurrent jobs (non-consecutive JobMediaId values).
> Was another job trying to use IM0093? Maybe IM0093 was in another drive and
> Bacula mixed up the drives somehow?
Yes, I believe that FB0956 was in one drive and IM0093 in the other,
though I do not understand how bacula 'mixed up' which volume to use, or
which drive a particular volume was in.
Not sure how closely related this is, but I've seen cases occasionally
where bacula will say that it cannot mount a certain volume in Drive0
and requires user intervention, only to find that the volume requested
is already mounted and in use in Drive1 by other jobs. So it is
possible for bacula either to lose track of which drive a volume is in
or to not be sure if a volume is already in use.
I did a partial restore of the job and it did in fact load and read off
IM0093 successfully. So in some sense I know what happened, I just
don't know why it happened or how to prevent it (other than isolating
jobs, but that defeats the point of concurrency).
Stephen
>
> __Martin
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>
--
Stephen Thompson Berkeley Seismological Laboratory
stephen AT seismo.berkeley DOT edu 215 McCone Hall # 4760
404.538.7077 (phone) University of California, Berkeley
510.643.5811 (fax) Berkeley, CA 94720-4760
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
