On May 5, 2011, at 5:29 AM, Hugo Letemplier wrote:

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

In what way is not *not* a problem easily solved by using a slightly different 
configuration?

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

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