Knoax -

You are welcome for the detailed information.  It is not published in the 
manual.  I retrieved that sequence information from the source code, which is 
pretty well commented.

What you are trying to do it outside the norm.  Perhaps somebody else on the 
forum will answer your question more directly about a backup job without 
writing any data.  It seems to me that all you're trying to do there is trigger 
the prune/purge operation, so I would be more inclined to just write a script 
to do that directly instead.

A couple of details where we're not on the same wavelength, perhaps just 
semantics on wording or a continued misunderstanding of your configuration ...

1) I did not day that "do not delete any volume or job even if the volume is in 
the "purged" state".  I said that "does not delete any volume or job even if 
the volume is expired".  There's a big difference between being expired and 
being purged.

2) From my testing and my code review, "Action On Purge = Truncate" only works 
when it is executed from the command line.  Volumes that are purged as a result 
of the AutoPrune function in the pool will not be truncated.  There's another 
recent thread on this user group that discusses that in more detail.  Scripting 
the deletion of purged volume isn't ideal, but I understand why you might do 
it.  From my testing I don't think it will hurt anything since the volume will 
re recreated when it is recycled.

3) Truncating a volume does not delete it.  It relabels it, which shrinks the 
volume down to a few hundred bytes.

4) You should be recycling your volumes, not creating new volumes.  Recycled 
volumes are truncated before reuse, so you are starting over with an empty 
volume.

5) Interleaving of data would occur if multiple backups were simultaneously 
writing data to the same volume.  If you use a volume for multiple backups of 
the server, the data is appended, not interleaved.  If you desire to not have a 
volume used for more than one backup job, you can accomplish that by setting 
"MaximumVolumeJobs=1" in your pool definition.  You likely have already done 
this, but I figured I'd mention it in case you haven't.  As an aside, even 
interleaving of data is not much of a concern on random access disk storage.

6) The very reason I've answered you twice with same answer, that setting the 
Volume Retention properly in your pool definition will resolve your issue, is 
because that attribute will cause the volume to be recycled BEFORE Bareos 
allocates the volume(s) for the 3rd backup, not after.  I know this to be the 
case from experience and a code review.  The other settings, as you've pointed 
out, happen after the volume is allocated (I've never tested that as I don't 
use those settings).  So if that isn't resolving your issue it would indicate 
that your volumes are not expired at the time that your job starts.

Long winded again.  Good luck.  Perhaps somebody else has a solution for you.

Dan

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to