Hi,
On Tuesday 11 December 2007, Arno Lehmann wrote:
> 10.12.2007 12:58,, Bastian Friedrich wrote::
> >
> > The "run" statements in job definitions seem to be a great way to
> > accomplish backing up multiple distinguished subsets of a file system. By
> > adding FileSet parameters, one job can back up a machine and still keep
> > information about more abstract system components.
>
> I don't think I understand what you want to do here, so if you feel
> like it, a more detailed explanation (perhaps with an example ;-)
> would be nice.
the systems I am about to back up contain distinguished subsets of files -
imagine "data belonging to the e-mail system" vs. "home directories" vs. "a
network filesystem". To individually restore these subsets, it seems sensible
to use single filesets for each of these subsets. Thus, I plan to use a
config like this:
===============================
# Empty fileset
FileSet {
Name = "empty"
}
# Fileset 1
FileSet {
Name = "email"
Include {
File="/var/spool/imap"
[...]
}
[...]
}
# Fileset 2
FileSet {
Name = "homedirs"
Include {
File="/home/"
}
[...]
}
# Global Job
Job {
Name = "MyBackup"
FileSet = "empty"
run = "MyBackup Fileset=email"
run = "MyBackup Fileset=homedirs"
[...]
}
===============================
Running the Job "MyBackup" results in backups of all of the subsystems.
Some of these subsystems may require a preprocessing step with the "RunScript"
statement (or its relatives). I'd like to use something like
Run Before Job = "/my/script/path/preprocess %f"
to preprocess the filesets (given %f being the fileset name). The
preprocessing script/program knows about the referenced filesets and the
required preprocessing.
Obviously, I could add additional job statements to be executed by the "run"
statements, each including exactly one fileset. I'd rather stick with the
described one job/multiple fileset design described above - if possible.
> > Unfortunately, the relevant low level/source structures don't allow for a
> > simple adding of such a reference, as far as I can see...
> >
> > Is there any chance to access the current file set name in a run script?
>
> I think adding that to the job codes' interpretation should be
> reasonably easy. Have a look into src/lib/util.c and you'll find the
> function edit_job_codes(). That's where the work is done. Getting the
> name of the current file set might be a bit difficult; the JCR
> contains a pointer to a JOB object, which in turn contains a pointer
> to the fileset.
The jcr class only contains the relevant pointers if compiled in the director
context (i.e. DIRECTOR_DAEMON is set); util.c needs to be independent of that
flag. Thus, I cannot find a reference to the job or fileset ressources there:(
> If you have problems accessing the file set name, you should ask on
> the -devel mailing list.
I'll ask there, thanks :)
Thanks for your support,
Bastian
--
Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany
p: +49 (0) 761-45684-24
f: +49 (0) 761-45684-10 www.collax.com
Geschäftsführer: William K. Hite / Boris Nalbach
AG München HRB 158898 . Ust.-IdNr: DE 814464942
\ I am. Therefore, I think. I think.
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
