Actually, bscan does exactly what Matthew wants, but it reads Volumes instead of reading the catalog. It might be an interesting project to make a variation of bscan that would scan a Bacula database and pull out selected parts (Jobs, Job names, Clients, ...) and then insert them into the current catalog.  Bscan knows how to change the JobIds and other pointers so that they do not clash (basically it creates new Jobs ...).    The simplest form of scanning a database could be to copy JobIds, of course, it could be much smarter than bscan which has to create new Pool, ... records without knowing what they are, but this program could find all the parts used by a Job and ensure that they are in the output catalog. There might be some tricky stuff with avoiding naming conflicts -- like two identical Job names in the two databases, but all that can be solved.

This might be a big project and I am not sure how useful it could be because I imagine that there are few people who want to consolidate Directors.  On the other hand, it could be a very nice tool for Copying or Migrating catalog data from one catalog to another one. E.g. if you wanted to take very old records out and archive them, or move old clients out to an client archive, ...

On 08/11/2018 04:47 PM, Phil Stracchino wrote:
On 08/09/18 11:47, Matthew Arguin wrote:
But then you lose the historical stuff?  Was hoping for a way to sort of
migrate everything from one to another.  I will say that I don’t expect
that this is doable with out more work than it is worth.

Moving the clients is easy.  Moving the historical data is hard.  As
others have said, you must do it manually.  You would have to start out
by changing the numeric IDs of every Job, every Volume, every Pool,
every Client, every Fileset, every Schedule, every type of resource, in
the catalog of the Director(s) you are planning to shut down to values
not used by the one you're trying to keep, and you need to do it
CONSISTENTLY, making sure every single record in the database refers to
every other record it should by the correct *NEW* row IDs.  Then you
need to import that data into the Catalog you're keeping without
overwriting any data you already have.

None of this is anything you should be attempting unless you have strong
SQL database skills and understand how the Bacula catalog tables relate
to each other.  And of course, in all cases you should back up all of
your catalog databases first.

By comparison, you will probably find it a lot simpler to just add your
Clients and their Filesets and Schedules to the Director you're keeping
and restart it, then keep the other Directors around as backups in case
you need them for restores until their historical data becomes outdated.

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Bacula-users mailing list

Reply via email to