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 <d...@langille.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.bl...@free.fr>: >>>>> On Thu, 28 Apr 2011 17:33:48 +0200, Hugo Letemplier >>>>> <hugo.let...@gmail.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@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
