Normally when Bacula asks for a specific volume and the volume is not "available" it will put up a message requesting the volume. If you then put a different volume into the drive (assuming it is a tape), Bacula will use that volume if it is appropriate (correct Media Type, Pool, Volume Status, ...).

Since I haven't seen the exact messages that Bacula was displaying, it is not easy to understand why Bacula was rejecting your proposed volume(s).  Normally if you do an "llist volume=<volume Bacula is requesting"  and an "llist volume=<the one you proposed>" you should be able to see if there is or is not a match on Media Type, Pool, Volume Status, ...


Best regards,

Kern


On 02/12/2018 12:11 AM, Tilman Schmidt wrote:
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



------------------------------------------------------------------------------
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