On Tuesday 11 April 2006 13:06, Alan Brown wrote:
> On Mon, 10 Apr 2006, Kern Sibbald wrote:
> >> I'd like to add a third. I don't use scratch pools at all, currently,
> >> but I can't see why I'd want a new volume being added to the pool when
> >> I've got one in there that's supposed to be used. Wouldn't that mean
> >> that it would ALWAYS choose a scratch volume if there is one available
> >> and all of your tapes are full (even if one should be recycled)? In my
> >> setup, this would be the case anyway.
> >
> > If I remember the argument correctly, it was: "Why overwrite volumes if
> > there are scratch volumes available? That is what scratch volumes are
> > for."
>
> If existing pool volumes are purged/recyclable, then they are available
> for the purposes of backups.
>
> To my mind:
>
> In a large/multiple pool situation, scratch volumes should only be there
> only there for emergency use when no volumes are available in the pool.
Yes, I agree with you.
In reality what the users were complaining about was that if no volume was
available, Bacula would request to mount a volume that was not in the
autochanger, so they added Scratch volumes to the autochanger and Bacula did
not use those Scratch volumes. They rightfully complained about that, and
suggested that move the search for Scratch volume up to before the recycling
code. Their complaints were warranted, but the solution in hindsight was
probably not the best. Hopefully with what I now have for 1.38.8, we will be
back on track.
>
> The instances of this happening are when a backup set grows in size
> unexpectedly rapidly, or starts changing a lot, resulting in large
> incremental files being recorded.
>
> Scratch volumes should exist as a temporary buffer, and should be returned
> to scratch when the data on them expires.
I had planed on doing this, but put the new database columns in the wrong
table for 1.38.0. I was hoping to implement it in 1.38.x, but do to the need
to change the database, it will need to wait for 1.39 or possibly later.
> Longer term pool growth should
> be catered to by permanently allocating volumes to the pool.
>
> This is important in a setup like ours, as different pools have vastly
> different retention periods (ranging from 3 months to 5 years) and I have
> to budget tape usage as part of ongoing operational expenses. If a scratch
> pool tape is ever used, it means something unexpected has happened(*) or
> my calculations are out.
>
> (*) Last time, it turned out that 1 user was using a designated archival
> filesystem for temporary storage of deep sky observation processing,
> resulting in more than 5Tb of data being put into long-term storage
> instead of being ignored for backup purposes....
Surprise !
>
>
> AB
--
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
