Forcing Bacula to use particular tapes is not my objective.
(That would be easy - just put every tape in a pool of its own.)

What I'm asking for is a sensible way to handle the situation when
Bacula requests an unavailable volume. That does happen. It's more
frequent with standalone drives but it occurs occasionally with
autochangers, too. The specific instance I described was just one example.

So what is the appropriate action when Bacula decides to use a tape that
for whatever reason is not available for use?

Thanks,
Tilman

Am 07.02.2018 um 10:21 schrieb Kern Sibbald:
> Bacula is designed to decide itself which tapes to use and when. If you
> are trying to force it to use particular tapes it is possible, but it is
> outside the design envelop, so you will almost surely run into problems.
> 
> 
> 
> On 06.02.2018 00:54, Tilman Schmidt wrote:
>> Just encountered the situation again.
>> Bacula requested last month's tape "Januar" since its use period hadn't
>> expired yet, but it's the next full backup which should go onto the new
>> month's tape "Februar".
>> Tape "Januar" has VolStatus=Append.
>> Tape "Februar" has VolStatus=Used with VolFiles=0 since it's way beyond
>> any applicable retention periods, but Bacula rejects it because of its
>> Status and never considers promoting it to "Purged" .
>>
>> Running bconsole command "prune volume=Februar" asks for confirmation,
>> then emits the message
>>
>>    Found no Job associated with the Volume "Februar" to prune
>>
>> and does nothing. Bacula continues to reject the tape.
>>
>> Running bconsole command "purge volume=Februar" emits an alarming message
>>
>>    This command can be DANGEROUS!!!
>>
>> then proceeds, *without* waiting for confirmation, to update VolStatus
>> of tape "Februar" to Purged. Now Bacula accepts the tape.
>>
>> Is all that how it should be?
>>
>> Is there a way to run the purge command automatically for volumes that
>> have reached the "VolStatus=Used && VolFiles=0" state?
>>
>> Thanks,
>> Tilman
>>
>> Am 08.01.2018 um 00:34 schrieb Tilman Schmidt:
>>> Hello Heitor,
>>>
>>> Am 15.12.2017 um 15:41 schrieb Heitor Faria:
>>>>> running Bacula 7.4.4 (same problem with version 5.2.13) on openSUSE
>>>>> Leap
>>>>> 42.3 with a standalone LTO tape drive.
>>> Note: Meanwhile upgraded to 9.0.6.
>>>
>>>>> [Sometimes Bacula requests] a tape that for some
>>>>> reason cannot or should not be used for that job.
>>>>> Then if I mount a different tape, Bacula will immediately eject it
>>>>> again, claiming that it is in the wrong state ("Used" instead of
>>>>> "Recycle") and insisting I mount the one it requested.
>>>>> How can I convince Bacula to recycle and use the tape I give it?
>>>> You can forccefully recycle this tape with the purge command.
>>> Ok, that worked, but I'm not quite happy with that solution yet.
>>>
>>> * The situation has occurred again today, Bacula requesting volume
>>> "Mai-2" instead of "Januar" which I wanted it to use.
>>> * I first checked volume "Januar" which had not been in use for way
>>> beyond its retention period of 91 days, and was listed in the catalog
>>> with VolFiles=0, so it should be available for recycling:
>>>
>>> *llist volume=Januar
>>>            MediaId: 52
>>>         VolumeName: Januar
>>>               Slot: 0
>>>             PoolId: 1
>>>          MediaType: LTO-2
>>>        MediaTypeId: 0
>>>       FirstWritten: 1970-01-01 01:00:00
>>>        LastWritten: 2017-01-30 00:39:15
>>>          LabelDate: 2017-01-02 20:49:20
>>>            VolJobs: 0
>>>           VolFiles: 0
>>>          VolBlocks: 0
>>>           VolParts: 0
>>>      VolCloudParts: 0
>>>     CacheRetention: 0
>>>          VolMounts: 25
>>>           VolBytes: 1
>>>          VolABytes: 0
>>>        VolAPadding: 0
>>>       VolHoleBytes: 0
>>>           VolHoles: 0
>>>      LastPartBytes: 0
>>>          VolErrors: 0
>>>          VolWrites: 20,112,985
>>>   VolCapacityBytes: 0
>>>          VolStatus: Used
>>>            Enabled: 1
>>>            Recycle: 1
>>>       VolRetention: 7,862,400
>>>     VolUseDuration: 2,678,400
>>>         MaxVolJobs: 0
>>>        MaxVolFiles: 0
>>>        MaxVolBytes: 0
>>>          InChanger: 0
>>>            EndFile: 92
>>>           EndBlock: 5,628
>>>            VolType: 0
>>>          LabelType: 0
>>>          StorageId: 4
>>>           DeviceId: 0
>>>    MediaAddressing: 0
>>>        VolReadTime: 0
>>>       VolWriteTime: 39,796,045,456
>>>         LocationId: 0
>>>       RecycleCount: 6
>>>       InitialWrite: 0000-00-00 00:00:00
>>>      ScratchPoolId: 0
>>>      RecyclePoolId: 0
>>>      ActionOnPurge: 0
>>>          ExpiresIn: 0
>>>            Comment: NULL
>>>
>>> * I tried to prune the volume. Bacula asked me whether I was sure, then
>>> told me there was nothing to do:
>>>
>>> *prune volume=Januar
>>> The current Volume retention period is: 3 months 1 day
>>> Continue? (yes/mod/no): yes
>>> Found no Job associated with the Volume "Januar" to prune
>>>
>>> After that, Bacula would still eject the volume, asking I insert volume
>>> "Mai-2" instead.
>>>
>>> * Only when I actually purged the volume Bacula marked it as purged and
>>> subsequently accepted to use it:
>>>
>>> *purge volume=Januar
>>>
>>> This command can be DANGEROUS!!!
>>>
>>> It purges (deletes) all Files from a Job,
>>> JobId, Client or Volume; or it purges (deletes)
>>> all Jobs from a Client or Volume without regard
>>> to retention periods. Normally you should use the
>>> PRUNE command, which respects retention periods.
>>> There are no more Jobs associated with Volume "Januar". Marking it
>>> purged.
>>>
>>> *llist volume=Januar
>>>            MediaId: 52
>>>         VolumeName: Januar
>>>               Slot: 0
>>>             PoolId: 1
>>>          MediaType: LTO-2
>>>        MediaTypeId: 0
>>>       FirstWritten: 1970-01-01 01:00:00
>>>        LastWritten: 2017-01-30 00:39:15
>>>          LabelDate: 2017-01-02 20:49:20
>>>            VolJobs: 0
>>>           VolFiles: 0
>>>          VolBlocks: 0
>>>           VolParts: 0
>>>      VolCloudParts: 0
>>>     CacheRetention: 0
>>>          VolMounts: 25
>>>           VolBytes: 1
>>>          VolABytes: 0
>>>        VolAPadding: 0
>>>       VolHoleBytes: 0
>>>           VolHoles: 0
>>>      LastPartBytes: 0
>>>          VolErrors: 0
>>>          VolWrites: 20,112,985
>>>   VolCapacityBytes: 0
>>>          VolStatus: Purged
>>>            Enabled: 1
>>>            Recycle: 1
>>>       VolRetention: 7,862,400
>>>     VolUseDuration: 2,678,400
>>>         MaxVolJobs: 0
>>>        MaxVolFiles: 0
>>>        MaxVolBytes: 0
>>>          InChanger: 0
>>>            EndFile: 92
>>>           EndBlock: 5,628
>>>            VolType: 0
>>>          LabelType: 0
>>>          StorageId: 4
>>>           DeviceId: 0
>>>    MediaAddressing: 0
>>>        VolReadTime: 0
>>>       VolWriteTime: 39,796,045,456
>>>         LocationId: 0
>>>       RecycleCount: 6
>>>       InitialWrite: 0000-00-00 00:00:00
>>>      ScratchPoolId: 0
>>>      RecyclePoolId: 0
>>>      ActionOnPurge: 0
>>>          ExpiresIn: 0
>>>            Comment: NULL
>>>
>>> Isn't that the wrong way around?
>>> Shouldn't Bacula ask for confirmation on the *dangerous* command, and
>>> execute the *safe* one without asking?
>>> And shouldn't there be a non-dangerous way to promote a volume that
>>> *already* has no more jobs associated with it from status Used to
>>> Purged?
>>>
>>> Thanks,
>>> Tilman
>>>
> 

-- 
Tilman Schmidt                              E-Mail: til...@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to