Re: [Bacula-devel] Feature Request: Storage deamon config option OfflineOnPoll

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

Hello Marc,

For the next time, please always copy the list.


On Wednesday 30 May 2007 02:18, Marc Levy wrote:
> Hello Kern,
> 
> 
> For point #1:
> Let me explain a litle longer my needs:
>  - No manual operator interaction with bacula (via bconsole, ...)

That is already possible with existing tools.

>  - the possibility to store many different backup jobs without the
> same start date/time & priority (scheduled all night long) on the same
> tape,

I obviously don't understand the above because for me that is exactly what 
Bacula does.

>  - the availibility to tell the operator (without mailing it and so
> on) that there is a problem (Only done with the visual status of the
> tape drive).

Sorry, but I  *strongly* discourage you from doing so.  There are many other 
ways to make needed action clear to operators (email, sms, fax, print output, 
shell scripts, ...)

> 
> Below is an example of existing environements:
> - Pool#1 (name it 'DailyPool' for convenience) defined as:
>   VolumeUseDuration=22 hours and (for example) VolumeRetentionPeriod=4 weeks
> - Pool#2 (name it 'WeeklyPool') defined as:
>   VolumeUseDuration=22 hours (and VolumeRetentonPeriod=4 weeks)
> Pool#1 is used to store the incremental backups (1 tape per day, 4
> days per week say monday-thursday for one site#1 and 1 tape for
> monday-thursday for site#2[with VolumeUseDuration=6 days of course]),
> Pool#2 the full backup (1 tape per week say friday) (Of course, if
> there is no full backup for a job in the catalog, Bacula convert the
> incemental to a full backup and that is fine!)
> The jobs are scheduled to start running from 21:00 to 23:00 every
> mon-fri night (with a 5 minutes delay as said in the manual + spooling
> data is on and concurrent jobs is well defined), using Pool#1 on
> monday-thursday and pool#2 on friday.

I didn't read the above as it doesn't seem to be relevant to your patch.

> What I need: every morning, the operator change the tape in the drive
> (take out the tape currently in the drive and insert a new one for the
> next night); in fact about 10 hours before Bacula really need it.

This is already possible with the existing Bacula code and requires no changes 
just understanding how Bacula functions and a bit of organization.

> 
> What I tested (with of course a restart of the storage daemon between
> every configuration change):
>  - Set AlwaysOpen=yes, OfflineOnUnmount=yes (I agree, this is really
> OfflineOnClose acording to the code!), CloseOnPoll=yes
>   => with this config, the only time where the SD ejects the tape is
> when it need a different tape
>    a/  from _another_ pool and in my case at about 21:00 (every
> mon-fri night for site#1; on thursday & monday night for site#2),
> ...time where obviously there is no more an operator on site!,
>   b/ or when it need a different volume from the _same_ pool to finish
> its jobs (previous tape full)
>       This behavior would be 'not so bad' if the operator was able to
> manually eject the current loaded tape during the day but, as the
> drive is AlwaysOpen by Bacula
>   a/ the activity led of the drive is continuously lit (inducing the
> operator in error thinking there is a tape activity)
>   b/ the only way to eject the drive is to press the eject button for
> a long time (thus in fact sending a reset to the drive).
> 
>  - Set AlwaysOpen=no, OfflineOnUnmount=yes
>   ==> The SD eject the tape after every job! not good for me but I
> anderstand that this is the correct behaviour.
> 
>  - So tried Set AlwaysOpen=yes, OfflineOnUnmount=no, CloseOnPoll=yes
>   ==> The SD never ejects the tape!  (and after having read the code)
> this is the correct behaviour too.
> 
> I really need AlwaysOpen=no because when set to yes:
>  a/ the AlertCommand (either tapeinfo nor smartctl) fails ( <== can't
> access the drive because it is locked by bacula),
>  b/ the activity led of the drive is always lit (and this is confusing
> the operator)
> (By the way, remember that I only have single tape drives (/dev/nst0),
> no autochanger device (/dev/sg0))
> I really don't want to implement some kind of AdminJob or
> pseudo-schedule job to eject the tape in the morning (I have already
> thunk about that but it is too hazardous)
> 
> So with the option OfflineOnPoll, the only time a tape is ejected from
> the drive is in an error/fault condition (I agree this is only my
> point of view and the conventions taken at my offices) ie wrong tape
> inserted and/or need a new tape because previous one is full and in
> this case the operator must inform the admin.
> 
> I hope that this is a litle clearer for you.

No, it is not clear.  You need to work your response down to paragraph.

> 
> For Point#2
> I thank that it would be easier to understand with differents diffs
> output; I was mistaken, afflicted :-(
> 
> For Point#3
> I was thinking that I could not send any attachement to the list for
> security restrictions. I will do that.

Why should there be security restrictions. The source code is *fully* open and 
visible by everyone.

> 
> For Point#4
> Ok, I will do it this way as soon as I will be at the office (next morning).

I suggest you hire a professional support person to work this out for you, and 
rather than tell him exactly what Bacula should do, listen to his advice 
about how to best get something that will function for your situation.

Regards,

Kern

> 
> Best regards,
> 
> Marc.
> 
> 
> 
> 2007/5/29, Kern Sibbald <ke...@si...>:
> > Hello,
> >
> > I saw your feature request with a patch, but cannot answer it because I
> > receive the email batched.  Please do the following things:
> >
> > 1. Explain why your OfflineOnPoll is different from:
> >     OfflineOnUnMount = yes
> >     CloseOnPoll = yes
> >
> >    Note, OfflineOnUnMount should really be named OfflineOnClose.
> >
> > 2. Possibly resubmit your patch, but using a single
> >
> >    diff -u format output redirected to a file named xxxx.patch where you
> >             replace xxxx with some descriptive name.
> >
> > 3. Attach your patch to the email rather than inlining it.
> >
> > 4. Send it to the bacula-devel list, and copy me.  You don't absolutely 
need
> > to be subscribed, but if not your mail gets held until our anti-spam 
person
> > Russell approves it --thanks Russell :-)
> >
> > Regards,
> >
> > Kern
> >
>