Hello,
In general, if the definitions of the jobs are not available, Bacula
will not have the
information it needs to perform a migration (Next Pool, ...). I agree
with what
Josh says -- if you want to access a Job for any reason, it is better to
keep the
Job definition and possibly disable it or have no schedule.
That said, it appears that a bug was overlooked by Bacula Systems (me
included),
in that if the Job definition is not available, the Migration job should
be failed, and
it was not.
There is an Enterprise fix for this oversight that I will apply to the
community version.
I will also update the documentation to mention this point.
Best regards,
Kern
On 1/14/19 12:49 PM, Alan Brown wrote:
If you are using Bacula for any form of archival work, or migrating OLD
backups, then you need to be aware of of this issue.
The Migrate feature only migrates jobs in a volume that are in the
configuration file.
What this means is that if you have jobs old jobs that are no longer
backed up and have been removed from the configuration, but still exist
on archive media then you will LOSE those jobs when you migrate them to
new media.
This is critically important to be aware of for instance if you are
moving your archive volumes from older to newer version of LTO tapes.
Just because jobs exist in the database and can be restored, does NOT
mean they will be migrated.
To make matters worse, the migrate job will FAIL, but the job will then
be falsely tagged as migrated.
I raised this with Baculasystems over a year ago (we have Enterprise
edition) but the developers don't consider this to be a bug and won't
fix it.
_______________________________________________
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
