Resend. Originally sent from wrong email address.

On 05/16/2015 08:56 AM, Heitor Faria wrote:
> Dear Bacula Developers / Users,
> 
> I suggested to feature requests today for your evaluation:
> 
> 1. Bacula FileSet Variable
> 
> Implement Bacula FileSet Variable to improve scripting capabilities and maybe
> do a show FileSet during backups, improving log information.

Hi Heitor!  :)

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"

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.

Or

Option 2: The Name of the FileSet like above and the actual contents of the
FileSet resource as passed to the FD when the job is started.

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.

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. :)


Quick workaround:  Use the bconsole "show job=JobName" as a Run Before Run
Script command. This tells you everything about the job.

However, this is not a great solution because the show job=JobName  command
shows the "configured" job information, not the information handed to the FD
at the start of the job. If the FileSet (or other) is manually modified just
before the job is submitted, you would not know it.


> 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..

----[snip]----
Job {
...
   Run Script {
     RunsWhen = before
     RunsOnClient = no
     Command = "/path/to/script.sh %l"
   }
}
----[snip]----


/path/to/script.sh:

----[snip]----
#!/bin/bash
level="$1"
...
case ${level} in

    Full )
       Some Full stuff here ;;

    Incremental )
       Some Incremental stuff here ;;


    Differential )
       Some Differential stuff here ;;

    VFull )
       Some Virtual Full stuff here ;;

    * )
    Some Catch-all stuff here ;;

esac
...
----[snip]----


Bill



-- 
Bill Arlofski
Reverse Polarity, LLC
http://www.revpol.com/
-- Not responsible for anything below this line --

------------------------------------------------------------------------------
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