[Bacula-users] Re: [Bacula-devel] RFC: "Recycle Current Volume"

[Kern S. <ke...@si...>]

Hello,

First, I'd like to say that I'm impressed. You really jumped into
the code and did a nice job of implementing the feature.

I see the problem you are having and had really not given a lot
of thought how to solve it. =20

An aside {
In a way, how you are using Bacula is not really how
it was designed. My basic idea was to minimize changing tapes
to minimize operator intervention and tape head wear (rewinding,...)
However a lot (maybe most) sites run like you do.
Ideally, you would do some similar magic so that you put a tape in,
and Bacula continues using it but perhaps warns you to change the
tape if it will not hold the next night's output. -- end aside }

Now assuming you want to keep your current scheme, I would like
to think about this feature a bit more before implementing it for
two reasons: 1. I'm really unhappy the with RecycleOldestVolume
(now named PurgeOldestVolume) mostly because it does a purge.
You, however, do a prune, which is a safe, so perhaps there=20
is no reason for me to worry here. 2. Some
day, the volume may not be pruned, and that will cause problems.

I have another idea that I would like to float by you ...

I'm wondering why you don't put the volume for each day in a
separate Pool? That is the purpose of Pools, and it will *force*
Bacula to recycle the correct daily tape using the current code.
Wouldn't this solve the problem?  This would also make it easier
to synchronize if something goes wrong one day -- simply cancel
the job and the next day, Bacula should take the correct tape.
Also, using one Pool per day, you could easily setup a two week=20
cycle by putting two tapes in the pool and setting appropriate
retention periods.  Of course, in this case, we are probably
back to wanting a Recycle Current Volume (I'll probably
rename it Prune Current Volume which is closer to what it
really does).  Maybe it would be better to have 14 Pools?

I'll keep this on hold until I hear back from you (and perhaps
some others -- I'm copying this to the users list for that
reason).

Best regards,

Kern



On Sat, 2003-07-12 at 15:06, Nic Bellamy wrote:
> Hi,
> 	I'm using Bacula 1.30a at a few client sites, backing up somewhere
> around 500GB at the moment. One problem I've run into is with clients
> that want rotation schedules that have tapes labeled for each day of the
> week, "Monday", "Tuesday", etc.
>=20
> This works fine, including volume recycling, if the tape is put in every
> day without fail. As soon as a day is forgotten, without intervention by
> myself, things quickly turn to custard.
>=20
> Eg. Monday-Thursday, differential backups against a full backup done
> each Friday. After a week where all backups ran happily, and the volumes
> were marked used via Max Volume Jobs or Volume Use Duration, things look
> like this:
>=20
> Tape      | Status
> ----------+--------
> Monday    | Used
> Tuesday   | Used
> Wednesday | Used
> Thursday  | Used
>=20
> Now, on Monday, the Monday volume is recycled, but nobody put the tape
> in, and we end up with:
>=20
> Tape      | Status
> ----------+--------
> Monday    | Recycle
> Tuesday   | Used
> Wednesday | Used
> Thursday  | Used
>=20
> When we get to Tuesday, the "Tuesday" tape is inserted. This is where
> things fall down - the director will complain "1998 Volume blah not
> Append or Recycle", and request the recycled "Monday" tape. To get the
> tapes back in sync with the real day of the week, I have to fiddle
> around updating the volumes manually.
>=20
> What I've done is whip up a patch that basically implements "Recycle
> Current Volume" - when the jobs run on a Tuesday, they'll see that
> time(now) > current_volume->lastwritten + current_volume->volretention,
> and will attempt a prune. If the prune results in all records being
> removed, it will then recycle it for immediate use.
>=20
> This is not perfect: Monday will be marked recycled, although there's
> actually still going to be valid data on the tape.
>=20
> Where the "request for comments" portion of this email comes in is here:
> =09
> 	Is this feature going to be useful enough to include in the
> 	mainline distribution, ie. should I develop it fully, adding
> 	it as a pool configuration option etc., or should I not bother
> 	developing it beyond an always-on kludge for my own use?
>=20
> Patch is attached; testing so far is not much beyond "it compiles", so
> any comments would be appreciated.
>=20
> Regards,
> 	Nic.