Hi,

22.11.2007 19:02,, Ralf Gross wrote::
> Hi,
> 
> I may have misunderstood recycling or the different retention periods. So I
> need some clarification.
> 
> At the moment I'm looking for the reason why a volume in my Differential pool
> wasn't recycled and a volume from the Scratch pool was used.
> 
> What I want:
> 
> * daily incr. backups to the Incremantal pool
>  * volume can be wiped after 14 days -> volume retention 14 days
>  
> * weekly diff. backups to the Differential pool
>  * volume can be wiped after 31 days -> volume retention 31 days
>  
> * monthly full backups to the Full pool
>  * volume can be wiped after 180 days -> volume retention 180 days
> 
> 
> I've set the following for the client:
> 
>   File Retention = 90 days
>   Job Retention = 6 months
> 
> And the different volume retention periods above.

Ok. Looks familiar :-)

> The short question is: what prevents volume 06D125L (more details below) from
> being recycled?  
> 
> Does File or Job retention periods which are larger than the Volume retention
> period prevent recycling?

No, they don't. Or at least they shouldn't.

> 
> 
> My understanding of the different retention periods an recycling is:
> 
> * the shortest retention period defines if a volume can be recycled
>   -> example: a volume in the Differential pool can be recycled and reused if
>      its state is Used and the first written date is older than 31 days 
> (volume
>      retention period of that pool). It doesn't matter if 'File Retention' or
>      'Job Retention' is set to more than 31 days.

I may be wrong, but I think LastWritten is what counts for recycling. 
Anyway, File or JobRetention really don't matter.

> 
> Some parts of the manual, which makes me think I'm right:
> 
> http://www.bacula.org/rel-manual/Configuring_Director.html#SECTION0014130000000000000000
> | File records may actually be retained for a shorter period than you specify
> | on this directive if you specify either a shorter Job Retention or a
> | shorter Volume Retention period. The shortest retention period of the three
> | takes precedence.

Yup... although, reading this quote, I think File Retention is not the 
point here.

> http://www.bacula.org/rel-manual/Automatic_Volume_Recycling.html
> # If the request is for an Autochanger device, look only for Volumes in the
> Autochanger (i.e. with InChanger set and that have the correct Storage 
> device).
> # Search the Pool for a Volume with VolStatus=Append (if there is more than
> one, the Volume with the oldest date last written is chosen. If two have the
> same date then the one with the lowest MediaId is chosen).
> # Search the Pool for a Volume with VolStatus=Recycle and the InChanger flag 
> is
> set true (if there is more than one, the Volume with the oldest date last
> written is chosen. If two have the same date then the one with the lowest
> MediaId is chosen).
> # Try recycling any purged Volumes.
> ----> # Prune volumes applying Volume retention period (Volumes with 
> VolStatus Full,
> Used, or Append are pruned). Note, even if all the File and Job records are
> pruned from a Volume, the Volume will not be marked Purged until the Volume
> retention period expires. 
> 
> 
> 
> Now there is volume 06D125L3, which I think sould be recycled.
> 
> 
> Pool: Differential
> +---------+------------+-----------+---------+----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> | mediaid | volumename | volstatus | enabled | volbytes       | volfiles | 
> volretention | recycle | slot | inchanger | mediatype | lastwritten         |
> +---------+------------+-----------+---------+----------------+----------+--------------+---------+------+-----------+-----------+---------------------+
> |       6 | 06D125L3   | Used      |       1 |  9,816,468,480 |       11 |    
> 2,678,400 |       1 |    6 |         1 | LTO3      | 2007-10-14 00:25:18 |

Volume retention 31 days, LastWritten on Oct 14... yup, looks like 
this one qualifies. It's also Used, Enabled, and Recycling is allowed.

> 
> 
> There is a job record (BackupCatalog) on that volume that is a Full backup the
> other two are differential backups.

They shouldn't matter, because Volume retention is over anyway.

> Enter Volume name: 06D125L3
> +-------+---------------+---------------------+------+-------+-------+---------------+--------+
> | jobid | name          | starttime           | type | level | files | bytes  
>        | status |
> +-------+---------------+---------------------+------+-------+-------+---------------+--------+
> |   743 | SMTCZB0003    | 2007-10-14 00:07:06 | B    | D     | 7,241 | 
> 1,195,019,960 | T      |
> |   744 | VU0EM003      | 2007-10-14 00:13:38 | B    | D     | 6,467 | 
> 7,716,783,290 | T      |
> |   745 | BackupCatalog | 2007-10-14 00:25:03 | B    | F     |     1 |   
> 894,160,054 | T      |
> +-------+---------------+---------------------+------+-------+-------+---------------+--------+
> 
> 
> Instead of recycling this volume a fresh volume from the Scratch pool was 
> used.

I haven't done much experimenting with a scratch pool recently. But I 
do recall there are more or less philosophical discussions from time 
to time.

The key question is: In a situation you describe, is using a scratch 
volume the right move?

Bacula simply tries to keep usable data as long as possible. In this 
case, as the volume from Diff pool is not yet pruned, using a scratch 
volume is a way to achieve this.

I would have to re-read the manual chapters on recycling very 
carefully to compare the behaviour you observe with the documentation...

But I would expect Bacula to recycle the used volume if there is no 
other usable volume *in the autochanger*. I.e., first make sure 
backups continue, so prefer volumes in the autochanger. If the scratch 
volume was in the autochanger, using that looks ok to me.

What I really think we need is
a) a better documentation of the current recycling algorithm. It's 
really too complicated...
b) ways to configure the recycling behavior, so you can prefer to 
re-use volume over using scratch volumes, and vice versa.

Arno

-- 
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to