On Monday 11 January 2010 11:47:33 Richard Hartmann wrote: > Hi all, > > we are deploying Bacula on more and more hosts and up to now, we like > what we see :)
Good. > > We added some functionality around Bacula in order customize it. Amongst > others, we created trigger for our monitoring solution that inform us of > any failed jobs. > > Trying to keep relevant data as close to the original source as > possible, I am lacking a system to ACK failed jobs. I.e. I need a > mechanism to store the information that someone looked at a specific > backup job and decided that it's OK (or at least, that it is being > handled). > > To achieve this end, I can imagine several solutions: > > 1) Add a field timestamp field called 'ManualVerification' to the Job > table. If set to non-NULL, it means that someone verified the job > at this specific date. > > 2) Add a BOOL and a timestamp, analogous to the above (this less > implicit data storage might appeal to some people) > > 3) Add a table JobState with the fields > JobId (foreign key) > Type (ENUM; ACKJobFailure, ACKJobWarning, ...) > Name (text; of the person verifying, maybe a proper foreign key to a > new Table called User) > Timestamp (timestamp) > Comment (text) > > > For future expandability, I would lean towards option 3, but I would > obviously prefer to do something that will be integrated and used in > mainline so I want to start a discussion about the relative merits of > these, and other, solutions. > > > Also, and this is a very important question to me, does Bacula do any > kind of internal verification or make any assumptions which could be > broken by adding custom fields or tables? You can add new tables, but take care to use names (e.g. XXXJobState) that will not conflict with tables we might create in the future. I strongly discourage you from adding any new columns (fields) to Bacula tables. In some cases, it might work, but if we upgrade a table that you have modified, the whole process will probably fail. We are adding a single "Comment" field to the job record in the next release that can be used by users. Its primer purpose is for operators to leave notes about particular jobs (why they re-ran it, ...). This field might be useful for you. I am not too keen on adding additional user fields as you suggest for the same reasons that others have already expressed. Best regards, Kern > > > > Thanks, > Richard > > --------------------------------------------------------------------------- >--- This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
