Hello Kern,
- If I did not cc the list last time, this was only because you send me a private mail and I did not feel free to make it contents public. >From now, I DO copy the lists. - For the 'security restrictions' I was just thinking about the listserver blocking any attachement to prevent the spread of infected files, that's all. - Perhaps you misunderstood my post: I didn't want to, in no case, to criticize the functionalities of Bacula. Yes, this is a pretty nice piece of code, and yes it works much better than many other softwares I had tested (including many costly 'commercial' ones), and finally yes, it suits my needs most of the time. I already have deployed it to 4 sites since one year now ( more than 200 Win32/Linux workstations & 15 Win2k+/Linux servers of which 'the vital essence is sucked every night' :-; ) with all the classic configuration options (AlwaysOpen,...). On each of those sites, an operator is responsible of taking care of the backup system; every operation is well done via bconsole (unmount, mount,...) and the alert system (email) works well too: no problemo! - The problem I had to solve was for one of my customers who has a remote site without absolutly any IT person on site (and they all think that every computer is only there to spy what they do like Big Brother!) therefore I absolutly had to find a workaround. So, I could had started a thread in the [bacula-users] list with "How to..." but I didn't want to annoy the readers with that, thus I worked a litle bit and finally made this patch, which is now deployed on two of my sites. I then said to myself that the least of the things I had to do was to give back this patch to the community (in case of someone, somewhere, had the same problem): consider this as just my very very litle 2 cents' contribution to the project. - May be this wasn't the good time to post this, as I understand that you much be very busy with the new upcoming 2.2 release, may be I didn't explain clearly Why and What, but never mind, I pause the discussion at this point. As soon as I'll have more time (not before 2 or three weeks) I will, if you agree with this, start a new thread with this topic and take the time to make it clearer. Regards, Marc. 2007/5/30, Kern Sibbald <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]>: > > > 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 > > > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
