Here aresome log snippets in case it jogs someone's memory.
During Consolidate, it finds jobs to consolidate, but these are job IDs
from job fatboy-local-AI not fatboy-sshfs-AI.
25-Mar 14:59 bareos-dir JobId 8119: Looking at always incremental job
fatboy-sshfs-AI
25-Mar 14:59 bareos-dir JobId 8119: fatboy-sshfs-AI: considering jobs older
than 11-Mar-2026 14:59:02 for consolidation.
25-Mar 14:59 bareos-dir JobId 8119: before ConsolidateFull: jobids:
6283,7605,5519,5639
25-Mar 14:59 bareos-dir JobId 8119: check full age: full is 16-Nov-2025
01:42:54, allowed is 25-Feb-2026 13:59:02
25-Mar 14:59 bareos-dir JobId 8119: Full is older than
AlwaysIncrementalMaxFullAge -> also consolidating Full jobid 6283
25-Mar 14:59 bareos-dir JobId 8119: after ConsolidateFull: jobids:
6283,7605,5519,5639
25-Mar 14:59 bareos-dir JobId 8119: fatboy-sshfs-AI: Start new consolidation
25-Mar 14:59 bareos-dir JobId 8119: Using Catalog "MyCatalog"
25-Mar 14:59 bareos-dir JobId 8119: Job queued. JobId=8120
25-Mar 14:59 bareos-dir JobId 8119: Consolidating JobId 8120 started.
In the virtual full job, it tries to consolidate to a volume in
fatboy-sshfs-AI's pool. The job fails when it can't read the first volume
from the fatboy-local-AI's pool (different storage, different media type).
25-Mar 14:59 bareos-dir JobId 8120: Version: 25.0.3~pre68.e4a45c2dc (23
March 2026) Debian GNU/Linux 13 (trixie)
25-Mar 14:59 bareos-dir JobId 8120: Start Virtual Backup JobId 8120,
Job=fatboy-sshfs-AI.2026-03-25_14.59.03_09
25-Mar 14:59 bareos-dir JobId 8120: Bootstrap records written to
/var/lib/bareos/bareos-dir.restore.26.bsr
25-Mar 14:59 bareos-dir JobId 8120: Consolidating JobIds
6283,7605,5519,5639 containing 184965 files
25-Mar 14:59 bareos-dir JobId 8120: Connected Storage daemon at
bareos.onnela.feep.org:9103, encryption: TLS_CHACHA20_POLY1305_SHA256
TLSv1.3
25-Mar 14:59 bareos-dir JobId 8120: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
25-Mar 14:59 bareos-dir JobId 8120: Using Device "bareos-sshfs1" to read.
25-Mar 14:59 bareos-sd JobId 8120: Using just in time reservation for job
8120
25-Mar 14:59 bareos-dir JobId 8120: Using Device "JustInTime Device" to
write.
25-Mar 14:59 bareos-sd JobId 8120: Moving to end of data on volume
"fatboy-sshfs-AI-Consolidated-1542"
25-Mar 14:59 bareos-sd JobId 8120: Ready to append to end of Volume
"fatboy-sshfs-AI-Consolidated-1542" size=262
25-Mar 14:59 bareos-sd JobId 8120: stored/acquire.cc:156 Changing read
device. Want Media Type="File" have="File-sshfs"
device="bareos-sshfs1" (/var/lib/bareos/storage-sshfs)
25-Mar 14:59 bareos-sd JobId 8120: Releasing device "bareos-sshfs1"
(/var/lib/bareos/storage-sshfs).
25-Mar 14:59 bareos-sd JobId 8120: Fatal error: stored/acquire.cc:206 No
suitable device found to read Volume "fatboy-local-AI-Consolidated-0052"
25-Mar 14:59 bareos-sd JobId 8120: Releasing device
"bareos-sshfs-consolidated1" (/var/lib/bareos/storage-sshfs).
25-Mar 14:59 bareos-sd JobId 8120: Releasing device "bareos-sshfs1"
(/var/lib/bareos/storage-sshfs).
25-Mar 14:59 bareos-dir JobId 8120: Replicating deleted files from jobids
6283,7605,5519,5639 to jobid 8120
25-Mar 14:59 bareos-dir JobId 8120: Error: Bareos bareos-dir
25.0.3~pre68.e4a45c2dc (23Mar26):
I realize this could possibly be worked around by making a copy of the file
set and changing one of the job definitions. But I still wonder if this
behavior is intentional, or whether the consolidate query should also
consider job name.
For reference, job configurations. Pools and storages are also separate,
and I can include those configs if relevant.
Job {
Name = "fatboy-local-AI"
Description = "fatboy shares"
Client = "spot-enc-fd"
JobDefs = "AlwaysIncrementalJob"
FileSet = "fatboyShares"
Schedule = "Daily at 22:30"
Always Incremental Job Retention = 62 days
Always Incremental Keep Number = 62
Always Incremental Max Full Age = 76 days
Pool = fatboy-local-AI-Incremental
Incremental Backup Pool = fatboy-local-AI-Incremental
Full Backup Pool = fatboy-local-AI-Consolidated
}
Job {
Name = "fatboy-sshfs-AI"
Description = "fatboy shares"
Client = "spot-enc-fd"
JobDefs = "AlwaysIncrementalJob"
FileSet = "fatboyShares"
Schedule = "Daily at 23:30"
Always Incremental Job Retention = 14 days
Always Incremental Keep Number = 14
Always Incremental Max Full Age = 28 days
Pool = fatboy-sshfs-AI-Incremental
Incremental Backup Pool = fatboy-sshfs-AI-Incremental
Full Backup Pool = fatboy-sshfs-AI-Consolidated
}
Josh
On Wednesday, March 25, 2026 at 4:11:19 PM UTC-4 Joshua Myles wrote:
I have two AI jobs that have the same client and fileset but different
pools (and storages, media types, etc.) Today I saw that when my
consolidate job ran it picked up a list of job IDs to consolidate but ran
them for the wrong job and thus tried to consolidate to a volume in the
wrong pool. Could this be because the AccurateGetJobids function does not
consider the job?
https://github.com/bareos/bareos/blob/7b4067ecb525c6fc1b26fe75794371a1ae8398a9/core/src/cats/sql_get.cc#L1355-L1368
I'd previously thought it was the combination of Job/FileSet/Client that
defined uniqueness but the query for finding jobs to consolidate doesn't
seem to consider the job.
Josh
--
You received this message because you are subscribed to the Google Groups
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bareos-users/8f9ee721-3f9e-402e-8747-935a29693a10n%40googlegroups.com.
