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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users