Hi, I will try to explain in other words.

Lots of people use bacula more for its Tape feature than for disk
backups. But there are more and more disk to disk to tape backup
strategy where tapes take the role of off site archiving
Theses two models are really different and if you use the disk backup
strategy that come with Bacula ( chapter 27 of the main doc ) you got
the example of 6 jobs per volume an a 7 volume limit for the
incremental pool. The problem is that if you need to cancel a job or
if it fails, the next incremental sequence will start on a bad volume
because the previous incremental sequence wont reach the maximum
volume job limit.

Moreover you can use the volume use duration to rotate ( your
incremental sequence )from a volume to another (the solution that I
use for the moment) . In this case you can imagine that your last job
fails and then the volume retention is not updated at the end of the
last job (because this one failed).

Another problem is that with such a strategy you cant use one Job per Volume :
Indeed, if you use 1 volume per job and auto-pruning and recycling.
And then you want to restore the last job ( considering that you use
Full + diffs + incs jobs).
The incremental volume used for one incremental job will have a
defined retention period. After this retention period you can consider
that the volume is lost (it can be pruned at anytime)
The next day you do the next incremental. The retention period for
this volume/job will be the same that for the previous one and so it
will be purgeable one day after the previous job.

=> : lifetime of a volume

diff  : ==================>
inc  :   =======>
inc  :     =======>x
inc  :       =======>

You wont be able to do a reliable restoration at point "x" because
your first incremental could have been purged and recycled.

Does anyone see this problem ?

2011/5/5 Dan Langille <dan AT langille DOT org>:
> On May 4, 2011, at 3:26 AM, Graham Keeling wrote:
>
>> On Fri, Apr 29, 2011 at 11:11:24AM +0200, Hugo Letemplier wrote:
>>> 2011/4/29 Jérôme Blion <jerome.blion AT free DOT fr>:
>>>> On Thu, 28 Apr 2011 17:33:48 +0200, Hugo Letemplier
>>>> <hugo.let.35 AT gmail DOT com>
>>>> wrote:
>>>>> After the job ran many times: I have the following volume <=> job
>>>> matching
>>>>> Vol name   Level      Time
>>>>> Test1         Full        15:50
>>>>> 324            Inc         16:00
>>>>> 325            Inc         16:10
>>>>> 326            Inc         16:20
>>>>> 324            Inc         16:30
>>>>> Test2         Full        16:40
>>>>> 325            Inc         16:50
>>>>> 326            Inc         17:00
>>>>>
>>>>> This is problematic because Vol324 is recycled instead of creating a new
>>>>> one
>>>>> I am not sure to understand the various retention periods : File, job,
>>>>> volume
>>>>> I think that I can increase the retention times but the problem will
>>>>> always be the same.
>>>>> ex : if I keep my incremental one hour then my first ones will always
>>>>> be purged first
>>>>> In a good strategy you purge the full sequence of incremental at the
>>>>> same time because you need to recycle you volume and don't want to
>>>>> keep a recent volume (incremental) without the previous ones.
>>>>
>>>> You would waste your tape/disk space.
>>>>
>>>>> To do that I imagine that I need to create one pool per day and reduce
>>>>> progressively the retention periods. It doesn't makes sense !
>>>>>  I turned the problem on all its sides but I cant find a good
>>>>> solution. Maybe the other retention period are the solution but I
>>>>> didn't succeeded ?
>>>>> Thanks in advance
>>>>
>>>> That means that your upper backup levels should have greater retentions to
>>>> be sure that at any time, you can use the full + diff + inc if needed.
>>>> Keeping incremental without full backup can be useful to restore only
>>>> specific files.
>>> Yes, but this problem is the same between incremental backups:
>>> Lots of people recommended me to use one pool per level:
>>> It works for Full and differentials, but not for inc pool
>>> Maybe one inc-pool per "incremental run of a scheduling cycle" should
>>> be good ? But it 's not simple
>>> I think that a new feature that add dependency between various job
>>> levels for the next versions of bacula could be cool.
>>> The idea is to allow pruning only for volume/jobs that aren't needed
>>> by other ones whatever are the retention time.
>>> As a consequence : you can prune a full only (((if the differential is
>>> pruned) if the XXX incrementals are pruned) if the last incremental is
>>> pruned )
>>> So you you can say that the maximum retention time for a full is at
>>> least equal to the retention time of the last inc + the delay between
>>> the full and the this last inc so you have something like this :
>>> full  : ========================>>>>>>>>
>>> inc  :   =========>>>>>
>>> inc  :     =========>>>>
>>> inc  :       =========>>>
>>> inc  :         =========>>
>>> inc  :           =========>
>>> inc  :             =========
>>> diff  :               ================>
>>> inc  :                 =========>>>>>
>>> inc  :                   =========>>>>
>>> inc  :                     =========>>>
>>> inc  :                       =========>>
>>> inc  :                         =========>
>>> inc  :                           =========
>>> diff  :                             ================>
>>> inc  :                               =========>>>>>
>>> inc  :                                 =========>>>>
>>> inc  :                                   =========>>>
>>> inc  :                                     =========>>
>>> inc  :                                       =========>
>>> inc  :                                         =========
>>>
>>> and not like that :
>>> diff  : ==================>
>>> inc  :   =======>
>>> inc  :     =======>
>>> inc  :       =======>
>>>
>>> What do you think about such a feature ?
>>
>> A while ago, I made a patch that does it. Nobody seemed to want it though.
>> http://www.adsm.org/lists/html/Bacula-users/2011-01/msg00308.html
>
>
> Just because you didn't find anyone that wanted it does not make it a bad 
> idea.
>
> Ideas are sometimes difficult to comprehend.  I didn't follow the above in a 
> 30 second scanning....
>
> If you think it's a good idea. Pursue it.  Give examples.  Describe the 
> issues, in brief, and then in general.  Build a case that others can 
> comprehend with minimal effort.
>
> If you think it's a good idea, something will come of it.  But nothing will 
> come of it if you don't persist.
> --
> Dan Langille - http://langille.org
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users