*it's nice TO have

======================================================================= 
Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified 
Administrator II 
15 a 26 de junho: Treinamento Telepresencial Bacula: 
http://www.bacula.com.br/?p=2174 
61 8268-4220 
Site: www.bacula.com.br | Facebook: heitor.faria | Gtalk: heitorfaria AT gmail 
DOT com 
========================================================================

----- Mensagem original -----
> De: "Heitor Faria" <heitor AT bacula.com DOT br>
> Para: "Bill Arlofski" <waa-bacula AT revpol DOT com>
> Cc: bacula-users AT lists.sourceforge DOT net
> Enviadas: Sábado, 16 de maio de 2015 13:43:20
> Assunto: Re: [Bacula-users] Feature Requests - FileSet Variable & Diff, Inc, 
> Full Run Scripts

> Hey Bill,
> 
> What's up?
> 
>> Hmmm, for debugging purposes this might be helpful at times.   But I wonder
>> what would be in the FileSet variable?
>> 
>> Option 1: Just it's name like:  "LinuxSystemsFileSet"
> 
> Option 1.
> 
>> Having just the name in the job's log is helpful, but a job can be run with a
>> FileSet, and then someone can edit the FileSet's resource later... Then if 
>> you
>> go back for debugging, you might be comparing a job's outcome (e.g.: the 
>> files
>> backed up) against a fileset name whose current contents can be entirely
>> different.
> 
> That's exactly the beauty of having a show fileset every backup job. This is 
> the
> problem I'm trying to solve.
> Not for me, but Bacula newbies. It's easy to forget to set the correct FileSet
> when creating a new Job.
> 
>> If the FileSet name and full FileSet resource (as passed to the FD at job
>> start time) are logged for every job, you know exactly what the FD was told 
>> to
>> backup, but the job logs may become unnecessarily long, or more of a chore to
>> read.
> 
> Yes, but I think it may be important. FileSet can change along the time. Even
> for auditing purposes it's nice two have that information, optionally of
> course. I think it's a crucial information for support.
> I don't think it's too much information. Typical show fileset output brings
> what, 12 lines?
> 
>> Personally, I kind of like the idea though because my backup logs are handled
>> by my helpdesk software, so I only have to read a log occasionally when
>> notified of something out of the ordinary. :)
> 
> It would be optional. You could make a script to show fileset=var every job, 
> or
> not.
> 
>> Quick workaround:  Use the bconsole "show job=JobName" as a Run Before Run
>> Script command. This tells you everything about the job.
> 
> Yes, but this way the output would be huge. =)
> 
>>> 2. Different Run Scripts Per Backup level
>>> 
>>> Add the keyword full, diff, inc etc. to the Run Script Resource, so the
>>> administrator can set different scripts per backup job Level.
>> 
>> You can already (manually) implement this feature in your Run Scripts
>> themselves.   Bacula has the %l variable to indicate the Level. If you use a
>> shell script or other script as a Run Script command, you can just pass %l 
>> and
>> then test for it in the shell scrip and act on it accordingly..
> 
> Yes, it would work nice. I just think it would be easier for people that does
> not know scripting to use it.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users