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