I can second the 'copy job' route---it's great for disk-to-disk-to-tape
scenarios and means the data transfer is only between SDs.
Just use console command "list jobs copies" to see their IDs.
The manual's description of the "Copy" type is pretty good:
https://www.bacula.org/13.0.x-manuals/en/main/Migration_Copy.html#SECTION0033100000000000000000
Bacula will always try to restore from the original job first if it
exists, then automatically promotes the copy otherwise. You can always
force a restore from copies using their IDs (useful for those essential
copy job test restores :D).
--
Graham Sparks
On Thu, 18 May 2023, Chris Wilkinson wrote:
I'm not sure I'm getting the motivation for using a copy job in preference
to a duplicate job to a second SD. This would also create a second backup.
The only reason I can think of is that a duplicate job might be different if
the files changed in between. That shouldn't be an issue.
I read that a copy job cannot be used for a restore but if the source backup
job becomes unavailable then the copy will be automatically promoted to a
regular backup which can be used for a restore. I can see that if a job or
its pools are deleted or pruned out in the database that would work, but
under a failure scenario, e.g. a storage fails, then it seems unlikely
Bacula could be smart enough to do this.
Am I being paranoid!?
Chris
On Thu, 18 May 2023, 4:45 pm Bill Arlofski via Bacula-users,
<bacula-users@lists.sourceforge.net> wrote:
On 5/18/23 08:07, Chris Wilkinson wrote:
> I have not used a copy job before so I thought I would try
one. I used Baculum v11 to set one up that copies a job from a
> local USB drive to a NAS. The setup was straightforward. I
created a new pool to receive the copy, defined the source and
> destination job, pool and SD/storage. This worked just fine
creating the new volumes on the destination storage.
>
> The thing I'm not clear about is whether a copy job copies
only the pool specified as the source, in my case a full, or
> whether all of full/diff/incr pools for the job are copied.
>
> My suspicion is that only the full is copied and I would need
additional jobs for the diff/incr.
>
> Given that there is a 1:1 correspondence between a job
definition and its pools, Bacula should be able to deduce one
from the
> other but it seems to be required to specify both.
>
> Could anyone help me understand this?
>
> Chris Wilkinson
Hello Chris,
A Copy job will copy
what you tell it to. :)
What I mean is there are several ways to tell a Copy job what
jobs to copy. The simplest being the `SelectionType =
PoolUncopiedJobs`
Using this option, Bacula will only look to the Pool specified
in the Copy job itself for jobids which have not yet been
copied and it will spawn n-1 new iterations of itself - each one
to copy one job - and it will take the last jobid found and
copy it itself.
At the beginning of the Copy job, Bacula will list the jobids it
has identified to be copied.
When setting up Copy jobs for the first time on an existing pool
with a lot of jobs existing it is a good idea to set the
`MaximumSpawnedJobs = 1` while testing to make sure things
look/work OK so you are not spawning hundreds or thousands of
Copy
jobs which may not work or need to be canceled. :)
Then, once things are OK, that number can be raised or the
setting can be removed entirely.
You can also just specify a specific jobid to be copied on the
comm
and line:
* run job=CopyJobNAme jobid=12345
And this one jobid would be copied - regardless of the `Pool =`
setting the the Copy job.
You can use `SelectionType = SQLQuery` and then the
`SelectionPattern =` can be used to specify *any* jobs you want
to be
copied, also overriding the pool set in the Copy job itself.
If you have Full, Inc, and Diff pools, you might have three copy
jobs, one for each pool, or you could simply call the Copy
job three times and override the `pool=xxx` on the command line
or in a Schedule.
Something I have helped customers with is to set up a Copy job
to be run immediately after the backup job itself has
completed. In this use case, you just call a small script in a
RunScript {} section in your job:
Job {
...All normal job stuff goes here...
RunScript {
RunsOnCLient = no
RunsWhen = after
Command = "path/to/triggerCopyJobsScript.sh %i '%n' %l"
}
}
...and that script simply starts the copy job wit
h the jobid=xxxx option:
----8<----
#!/bin/bash
#
# $1 = jobid, $2 = Job name, $3 = Level
#
if [ "$3" = "Full" ]; then
echo "Jobid $3 (${2}) is a Full job, triggering a copy of
it..."
echo "run yes job=CopyJobName jobid=$1" | bconsole
else
echo "This is not a Full level job, not copying it..."
fi
----8<----
I pass the level and jobname so, as in the case of this
customer, they wanted to only copy full jobs, so we just check
the
level and decide to trigger the copy job or not.
Note: Using this method, the Priority of your Copy job needs to
be the same as the Backup job otherwise you will enter a
deadlock where the Backup job never finishes because it is
waiting on the Copy to finish, but the Copy will never start
because it is waiting on the Backup job to finish. :) (Sure,
allowing "mixed priority" can be done, but that just adds
more confusion, problems etc.)
Hope some of this helps!
Best regards,
Bill
--
Bill Arlofski
waa@proto
nmail.com
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
