Re: [Bacula-users] Recycling and scratch pool
Le Vendredi 14 Avril 2006 09:12, Kern Sibbald a écrit : > On Friday 07 April 2006 16:06, pierre dibon wrote: > > Hello. > > New bacula user asking one question after reading pages of docs and > > mailing list archives. > > > > > > Got a question about 1.38.6 recycle algorithm : > > here is my problem: > > > > On the pdf doc of the release 1.38.5 it's said that the recycle algo uses > > tapes from the scratch pool AFTER checking for any recyclable volume > > > > but now in the new html doc (1.38.6 or 7) it is the opposite : bacula > > uses the scratch pool BEFORE checking recyclable volumes (and it's the > > way 138.6 does ) > > > > do i mis-understand a thing or is it a normal behaviour, is there any way > > to go backward to 1.38.5 behaviour with an option i missed? > > To rectify what I previously said in response to this question, the > algorithm for 1.38.8 (to be released today or more likely tomorrow) will go > back to the 1.38.5 behavior but with one bug fix. > > > thank you in advance. > > with you KERN "thank you in advance" was a good investment So.. thank you --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Recycling and scratch pool
On Friday 07 April 2006 16:06, pierre dibon wrote:
> Hello.
> New bacula user asking one question after reading pages of docs and mailing
> list archives.
>
>
> Got a question about 1.38.6 recycle algorithm :
> here is my problem:
>
> On the pdf doc of the release 1.38.5 it's said that the recycle algo uses
> tapes from the scratch pool AFTER checking for any recyclable volume
>
> but now in the new html doc (1.38.6 or 7) it is the opposite : bacula uses
> the scratch pool BEFORE checking recyclable volumes (and it's the way 138.6
> does )
>
> do i mis-understand a thing or is it a normal behaviour, is there any way
> to go backward to 1.38.5 behaviour with an option i missed?
To rectify what I previously said in response to this question, the algorithm
for 1.38.8 (to be released today or more likely tomorrow) will go back to the
1.38.5 behavior but with one bug fix.
>
> thank you in advance.
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Best regards,
Kern
(">
/\
V_V
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Recycling and scratch pool
Hello. New bacula user asking one question after reading pages of docs and mailing list archives. Got a question about 1.38.6 recycle algorithm : here is my problem: On the pdf doc of the release 1.38.5 it's said that the recycle algo uses tapes from the scratch pool AFTER checking for any recyclable volume but now in the new html doc (1.38.6 or 7) it is the opposite : bacula uses the scratch pool BEFORE checking recyclable volumes (and it's the way 138.6 does ) do i mis-understand a thing or is it a normal behaviour, is there any way to go backward to 1.38.5 behaviour with an option i missed? thank you in advance. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Recycling and scratch pool
Le Vendredi 7 Avril 2006 22:57, Ludovic Strappazon a écrit : > Hello, > > I'm still running 1.38.5, and I agree with Pierre, I think the use of > the scratch pool was at the right place in 1.38.5. > The last mail I read about the place of scratch pool in the recycling > algorithm was this one : > thank you, I love people agreeing with me ;) But if I understand your response (no time to read archives this week-end) and if this was the last mail about recycle algo changes, there is an important difference with the real actual algo because in this mail of Ludovic the scratch pool usage come on point 8 after the recycling of expired volume so ? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Recycling and scratch pool
Hello,
I'm still running 1.38.5, and I agree with Pierre, I think the use of
the scratch pool was at the right place in 1.38.5.
The last mail I read about the place of scratch pool in the recycling
algorithm was this one :
Ludovic.
Kern Sibbald a écrit :
> >On Monday 28 November 2005 12:26, Ludovic Strappazon wrote:
> >
> >
>> >>This is maybe more readable :
>> >>
>> >>
> >
> >Yes, thanks, it keeps it all on one line.
> >
> >So, thanks for the example, this seems pretty clear.
> >
> >Here is the algorithm that Bacula uses to get the next volume (as
written in
> >the manual):
> >
> >1. 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).
> >2. 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).
> >3. Try recycling any purged Volumes.
> >4. Prune volumes applying Volume retention period (Volumes with
VolStatus
> > Full, Used, or Append are pruned).
> >5. Search the Pool for a Volume with VolStatus=Purged
> >6. If InChanger was set, go back to the first step above, but
> > this second time, ignore the InChanger flag in step 2.
> >7. Attempt to create a new Volume if automatic labeling enabled
> > If Python is enabled, a Python NewVolume even is generated before
> > the Label Format check is used.
> >8. If a Pool named "Scratch" exists, search for a Volume and if found
> > move it to the current Pool for the Job and use it.
> >9. Prune the oldest Volume if RecycleOldestVolume=yes (the Volume
with the
> > oldest LastWritten date and VolStatus equal to Full, Recycle,
Purged,
> >Used,
> > or Append is chosen). This record ensures that all retention
periods are
> > properly respected.
> >10. Purge the oldest Volume if PurgeOldestVolume=yes (the Volume
with the
> > oldest LastWritten date and VolStatus equal to Full, Recycle,
Purged,
> > Used, or Append is chosen). We strongly recommend against the
use of
> > PurgeOldestVolume as it can quite easily lead to loss of current
backup
> > data.
> >
> >Please look it over carefully, but it seems to me that if I move
item 8 before
> >item 7 (i.e. exchange the two), Bacula will do what you want. I
agree this
> >would be much more logical ...
> >
> >Please let me know what you think.
> >
> >
> >
> >
>> >>I have a pool with two full tapes :
>> >>
>> >>Tape_1|Full|1 week|Recycle=yes|LastWritten=5/11/2005
>> >>Tape_2|Full|1 week|Recycle=yes|LastWritten=23/11/2005
>> >>
>> >>
>> >>And a Scratch Pool with Tape_3.
>> >>
>> >>
>> >>If I run a job, this is what happen :
>> >>
>> >>Tape_1|Full|1 week|Recycle=yes|LastWritten=5/11/2005
>> >>Tape_2|Full|1 week|Recycle=yes|LastWritten=23/11/2005
>> >>Tape_3|Append|1 year|1Recycle=yes|LastWritten=23/11/2005
>> >>
>> >>
>> >>I was expecting :
>> >>
>> >>Tape_1|Purged|1 week|Recycle=yes|LastWritten=5/11/2005
>> >>Tape_2|Full|1 week|Recycle=yes|LastWritten=23/11/2005
>> >>
>> >>So Bacula don't really need Tape_3 as it can use Tape_1.
>> >>
>> >>Ludovic.
>> >>
>> >>
>> >>
- The retention of the volume added from the Scratch Pool
should be the
retention of its new pool instead of one year.
>>> >>>Yes, this is a good idea. The Volume should take on the
retention period
>>> >>>of the new pool. Noted ...
>>> >>>
>>> >>>
> >
> >
Dibon Pierre wrote:
Kern Sibbald <[EMAIL PROTECTED]> a écrit :
> Hello,
>
> There was indeed a change in 1.38.x (perhaps as you say 1.38.6).
However, it
> applies only if the InChanger flag is set in the Media record, which
means
> that in principle we are dealing with an Autochanger, and in that
case, I
> believe that the behavior is correct.
>
> There is no way to disable the new behavior except by setting the
InChanger
> flag in each Volume to zero.
>
thanks for your answer but I can't say that i really understand the
new way
for me the first was the good way : imagine you have a pool big
enough to do for example 3 full backup during 3 weeks with a volume
retention of 3 weeks, with the first alogrithm when the data remain
relatively constant the volumes are recycled normally each 3 weeks, if
the amount of data is growing enough (for any reason ) to reach the
capacity of the pool before the end of retention period of the oldest
volume then bacula will pick a tape in the scratch pool an then
continue working from weeks to weeks
with the second algorithm bacula will pick and pick tapes in the
scratch pools to the end of its capacity without checking the
retention date of the normal pool killing the beautifull prevision you
make ? this is particularly critical if the goal is to optimise
Re: [Bacula-users] Recycling and scratch pool
Kern Sibbald <[EMAIL PROTECTED]> a écrit : > > I think you should discuss this with the users who requested this feature. It > was openly discussed on this list some time ago, and had what seemed to me to > be rather unanimous agreement. >thank you, I'll try to find this thread in order to understand - Webmail IUT Bayonne, Pays Basque.
Re: [Bacula-users] Recycling and scratch pool
On Friday 07 April 2006 20:37, Dibon Pierre wrote:
> Kern Sibbald <[EMAIL PROTECTED]> a écrit :
> > Hello,
> >
> > There was indeed a change in 1.38.x (perhaps as you say 1.38.6).
>
> However, it
>
> > applies only if the InChanger flag is set in the Media record,
>
> which means
>
> > that in principle we are dealing with an Autochanger, and in that
>
> case, I
>
> > believe that the behavior is correct.
> >
> > There is no way to disable the new behavior except by setting the
>
> InChanger
>
> > flag in each Volume to zero.
>
> thanks for your answer but I can't say that i really understand the
> new way
>
> for me the first was the good way : imagine you have a pool big
> enough to do for example 3 full backup during 3 weeks with a volume
> retention of 3 weeks, with the first alogrithm when the data remain
> relatively constant the volumes are recycled normally each 3 weeks,
> if the amount of data is growing enough (for any reason ) to reach
> the capacity of the pool before the end of retention period of the
> oldest volume then bacula will pick a tape in the scratch pool an
> then continue working from weeks to weeks with the second algorithm
> bacula will pick and pick tapes in the
> scratch pools to the end of its capacity without checking the
> retention date of the normal pool killing the beautifull prevision
> you make ? this is particularly critical if the goal is to optimise
> the utilisation of a minimal number of tapes in the autochanger in
> order to anticipate the future growth of datas
>
> is there a thing I misunderstand
I think you should discuss this with the users who requested this feature. It
was openly discussed on this list some time ago, and had what seemed to me to
be rather unanimous agreement.
>
> -
> Webmail IUT Bayonne, Pays Basque.
--
Best regards,
Kern
(">
/\
V_V
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Recycling and scratch pool
Kern Sibbald <[EMAIL PROTECTED]> a écrit : > Hello, > > There was indeed a change in 1.38.x (perhaps as you say 1.38.6). However, it > applies only if the InChanger flag is set in the Media record, which means > that in principle we are dealing with an Autochanger, and in that case, I > believe that the behavior is correct. > > There is no way to disable the new behavior except by setting the InChanger > flag in each Volume to zero. >thanks for your answer but I can't say that i really understand the new wayfor me the first was the good way : imagine you have a pool big enough to do for example 3 full backup during 3 weeks with a volume retention of 3 weeks, with the first alogrithm when the data remain relatively constant the volumes are recycled normally each 3 weeks, if the amount of data is growing enough (for any reason ) to reach the capacity of the pool before the end of retention period of the oldest volume then bacula will pick a tape in the scratch pool an then continue working from weeks to weeks with the second algorithm bacula will pick and pick tapes in the scratch pools to the end of its capacity without checking the retention date of the normal pool killing the beautifull prevision you make ? this is particularly critical if the goal is to optimise the utilisation of a minimal number of tapes in the autochanger in order to anticipate the future growth of datas is there a thing I misunderstand - Webmail IUT Bayonne, Pays Basque.
Re: [Bacula-users] Recycling and scratch pool
Hello,
There was indeed a change in 1.38.x (perhaps as you say 1.38.6). However, it
applies only if the InChanger flag is set in the Media record, which means
that in principle we are dealing with an Autochanger, and in that case, I
believe that the behavior is correct.
There is no way to disable the new behavior except by setting the InChanger
flag in each Volume to zero.
On Friday 07 April 2006 16:53, [EMAIL PROTECTED] wrote:
> Hello.
> New bacula user asking one question after reading pages of docs and mailing
> list archives.
>
>
> Got a question about 1.38.6 recycle algorithm :
> here is my problem:
>
> On the pdf doc of the release 1.38.5 it's said that the recycle algo uses
> tapes from the scratch pool AFTER checking for any recyclable volume
>
> but now in the new html doc (1.38.6 or 7) it is the opposite : bacula uses
> the scratch pool BEFORE checking recyclable volumes (and it's the way 138.6
> does )
>
> do i mis-understand a thing or is it a normal behaviour, is there any way
> to go backward to 1.38.5 behaviour with an option i missed?
>
> thank you in advance.
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
--
Best regards,
Kern
(">
/\
V_V
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] Recycling and scratch pool
Hello. New bacula user asking one question after reading pages of docs and mailing list archives. Got a question about 1.38.6 recycle algorithm : here is my problem: On the pdf doc of the release 1.38.5 it's said that the recycle algo uses tapes from the scratch pool AFTER checking for any recyclable volume but now in the new html doc (1.38.6 or 7) it is the opposite : bacula uses the scratch pool BEFORE checking recyclable volumes (and it's the way 138.6 does ) do i mis-understand a thing or is it a normal behaviour, is there any way to go backward to 1.38.5 behaviour with an option i missed? thank you in advance. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
