On Mon, Mar 09, 2009 at 01:09:47PM -0400, Phil Stracchino wrote: > Graham Keeling wrote: > > Hello, > > > > I have come across some problems involving a single client, a single > > fileset, > > and more than one job definition. > > > > My setup... > > > > Client: myclient > > FileSet: myfileset > > > > Job: myjob1 > > Job: myjob2 > > > > myjob1 and myjob2 both backup myclient using myfileset, but the schedules, > > pools, and storages differ. > > > Might I ask why, exactly, you're doing it this way? Perhaps if you were > to explain your rationale and what you're trying to accomplish, we could > suggest a better way to do it (for instance, replicating your Full jobs > to storage2 with a copy job).
I would like to be able to backup my fileset to my local storage daemon, and then do another backup to a remote storage daemon. I would then like to be able to restore from either storage daemon at will. As I understand it, a 'copy job' is very similar to a 'migration job', only the original does not get deleted. I have looked at the 'copy job' documentation, and it seems that it would not help. Some reasons from the documentation as to why I think a 'copy job' won't help: a) "the copy is treated as a copy rather than a backup job, and hence is not directly available for restore." b) "Migration is only implemented for a single Storage daemon. You cannot read on one Storage daemon and write on another." ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
