On Monday, February 9, 2026 6:44:25 PM CET Anders Gustafsson wrote:
> Thanks for all your help. I think part of the issue is that I was being
> stupid ������ I was using a scratch installation of debian to test as I
> am planning to build a small "replicant" with a Raspberry Pi.
I used to run a Bacula backup system with a MySQL database on a Raspberry
Pi for a small organization, and it worked for years without issues (the
MMC card failed once or twice).
I stored everything except the OS and Bacula configuration on an external
USB disk.
A USB hub with its own power supply was necessary to ensure that the
electrical current was stable enough for the Raspberry Pi board.
This was years ago (probably Bacula 5.x).
> Our install f Bacula is 13.0.1 and yes. I know it is time to upgrade.. The
> version of debian was more recent than that and dir and sd absolutely
> need to be the same version.
Yes, that's correct.
> I reinstalled the target box and installed the same version of sd and that
> works so much better!
>
>
> 4421 Incr 1 628.8 M OK 09-Feb-26 19:30 CopyLocal2Remote
> 4422 Full 1 628.8 M OK 09-Feb-26 19:30 BackupCatalog
Glad to hear it worked for you.
> That was just a test of the copying of the catalog backup, so if you would
> be so kind as to help me get the rest going...
>
> The sample job in the docs:
>
> Job {
> Name = "CopyLocal2Remote"
> Type = "Copy"
> JobDefs = "DefaultJob"
> NextPool = "Remote-Pool"
> Pool = "Local-Pool"
> SelectionType = PoolUncopiedJobs
> Storage = "Local-Storage"
> WriteBootstrap = "/opt/bacula/bsr/%c_%n.bsr"
> }
>
> That copies all jobs in the Local-Pool to the Remote-Pool, that I
> understand, but In my scenario do I have four pools:
>
> Full-Pool
> Diff-Pool
> Inc-Pool
> Cat-Pool
>
> for Full, Diferential, Incremental and then a separate for the catalogue.
> Do I need to have the same on the remote replica and have one job for
> each?
When copying a job in Bacula and using SelectionType = PoolUncopiedJobs,
you can have only a single pool as a source and it has to contain NextPool
option pointing to the single destination pool.
Next Pool could be set in the definition of all of the four pools you have,
or it could be set in the job resource, as you have shown above.
In your case where you have four pools, the easiest way is to create
multiple copy jobs (one for each pool on the local site) and continue
using SelectionType = PoolUncopiedJobs.
Whether you are going to create four pools on the destination (remote)
site, it's up to you.
Alternatively, you could use a single job but you would have to use
Selection Type = SQLQuery. In this case, you would have to write SQL
query that returns job ids that haven't been copied yet, from all
four pools.
Volume Media Type of the source pool is not a concern for copy jobs.
In the destination pool, all the volume must have the same Media Type.
From the Bacula documentation:
https://bacula.org/9.6.x-manuals/en/main/Migration_Copy.html
-----BEGIN-----
Important Migration Considerations
Each Pool into which you migrate Jobs or Volumes must contain
Volumes of only one Media Type.
-----END-----
-----BEGIN-----
If you keep Volumes of different Media Types in the same Pool,
it is not clear how well migration will work. We recommend only
one Media Type per pool.
-----END-----
https://docs.baculasystems.com/BEConfiguration/BestPractices/ActionsToAvoid/index.html#media-types-for-different-storage-locations
While I did quite some acrobatics with Bacula features to satisfy some
business requests, I never configured Bacula to separate Full, Differential,
and Incremental jobs into dedicated pools because I never saw a clear
benefit in such a setup. It reminds me of the 1990s, when tape sizes and
data volumes justified this kind of solution.
I hope somebody else could jump in with their experience/opinion on the
matter and possibly confirm or disprove what I wrote in this post.
--
Josip Deanovic
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
