Never mind. By running `backupsddemo1` with the `-d 200` logging, I
can now verify that the director is asking *it* to connect with
`FileStorage-demo2-dev1`, which is not on that host. So, despite the
fact that the director *claimed* it was talking to `backupsddemo2-sd`,
it was actually trying to communicate with `backupsddemo1-sd`.
Lloyd
log excerpt:
backupsddemo1-sd: dircmd.c:254-21 Do command: bootstrap
backupsddemo1-sd: dircmd.c:1897-21 === Bootstrap file ===
backupsddemo1-sd: dircmd.c:1899-21 Storage="backupsddemo1-sd"
backupsddemo1-sd: dircmd.c:1899-21 Volume="Full-0001"
backupsddemo1-sd: dircmd.c:1899-21 MediaType="File1"
backupsddemo1-sd: dircmd.c:1899-21 Device="FileStorage-demo1-dev1"
backupsddemo1-sd: dircmd.c:1899-21 VolSessionId=3
backupsddemo1-sd: dircmd.c:1899-21 VolSessionTime=1776263278
backupsddemo1-sd: dircmd.c:1899-21 VolAddr=1016684-2033139
backupsddemo1-sd: dircmd.c:1899-21 FileIndex=1-1781
backupsddemo1-sd: dircmd.c:1899-21 FileIndex=1783-1803
backupsddemo1-sd: dircmd.c:1899-21 Count=1802
backupsddemo1-sd: dircmd.c:1899-21 Storage="backupsddemo2-sd"
backupsddemo1-sd: dircmd.c:1899-21 Volume="Inc-0017"
backupsddemo1-sd: dircmd.c:1899-21 MediaType="File2"
backupsddemo1-sd: dircmd.c:1899-21 Device="FileStorage-demo2-dev1"
backupsddemo1-sd: dircmd.c:1899-21 VolSessionId=1
backupsddemo1-sd: dircmd.c:1899-21 VolSessionTime=1776263582
backupsddemo1-sd: dircmd.c:1899-21 VolAddr=251-969
backupsddemo1-sd: dircmd.c:1899-21 FileIndex=1-2
backupsddemo1-sd: dircmd.c:1899-21 Count=2
backupsddemo1-sd: dircmd.c:1907-21 === end bootstrap file ===
Next : 0x38010da8
Root bsr : 0x38010be8
VolumeName : Full-0001
MediaType : File1
Device : FileStorage-demo1-dev1
Slot : 0
SessId : 3
SessTime : 1776263278
VolAddr : 1016684-2033139
FileIndex : 1-1781
FileIndex : 1783-1803
count : 1802
found : 0
done : no
positioning : 1
fast_reject : 1
Next : 0x0
Root bsr : 0x38010be8
VolumeName : Inc-0017
MediaType : File2
Device : FileStorage-demo2-dev1
Slot : 0
SessId : 1
SessTime : 1776263582
VolAddr : 251-969
FileIndex : 1-2
count : 2
found : 0
done : no
positioning : 0
fast_reject : 0
backupsddemo1-sd: vol_mgr.c:152-21 add read_vol=Full-0001 JobId=21
backupsddemo1-sd: vol_mgr.c:152-21 add read_vol=Inc-0017 JobId=21
backupsddemo1-sd: dircmd.c:240-21 <dird: use storage=backupsddemo2-sd
media_type=File2 pool_name=IncPool pool_type=Backup append=0 copy=0
stripe=0 wait=1
backupsddemo1-sd: dircmd.c:254-21 Do command: use storage=
backupsddemo1-sd: reserve.c:286-21 <dird: use storage=backupsddemo2-sd
media_type=File2 pool_name=IncPool pool_type=Backup append=0 copy=0
stripe=0 wait=1
backupsddemo1-sd: reserve.c:315-21 <dird device: use
device=FileStorage-demo2-dev1
backupsddemo1-sd: reserve.c:248-21 Inx=1 mntVol=1 exact=1 chgonly=0
low_use=1 any=0
backupsddemo1-sd: reserve.c:466-21 Start find_suit_dev PrefMnt=1
exact=1 suitable=0 chgronly=0 any=0
backupsddemo1-sd: reserve.c:591-21 search res for FileStorage-demo2-dev1
backupsddemo1-sd: reserve.c:673-21 Try match res=FileStorage-demo1-dev1
backupsddemo1-sd: reserve.c:567-21 No usable device found.
backupsddemo1-sd: reserve.c:577-21 Leave find_suit_dev: no dev found.
backupsddemo1-sd: reserve.c:248-21 Inx=2 mntVol=1 exact=0 chgonly=1
low_use=1 any=0
backupsddemo1-sd: reserve.c:466-21 Start find_suit_dev PrefMnt=1
exact=0 suitable=0 chgronly=1 any=0
backupsddemo1-sd: reserve.c:591-21 search res for FileStorage-demo2-dev1
backupsddemo1-sd: reserve.c:567-21 No usable device found.
backupsddemo1-sd: reserve.c:577-21 Leave find_suit_dev: no dev found.
backupsddemo1-sd: reserve.c:248-21 Inx=3 mntVol=1 exact=0 chgonly=1
low_use=0 any=1
backupsddemo1-sd: reserve.c:466-21 Start find_suit_dev PrefMnt=1
exact=0 suitable=0 chgronly=1 any=1
backupsddemo1-sd: reserve.c:591-21 search res for FileStorage-demo2-dev1
backupsddemo1-sd: reserve.c:567-21 No usable device found.
backupsddemo1-sd: reserve.c:577-21 Leave find_suit_dev: no dev found.
backupsddemo1-sd: reserve.c:248-21 Inx=4 mntVol=1 exact=1 chgonly=0
low_use=1 any=0
backupsddemo1-sd: reserve.c:466-21 Start find_suit_dev PrefMnt=1
exact=1 suitable=0 chgronly=0 any=0
backupsddemo1-sd: reserve.c:591-21 search res for FileStorage-demo2-dev1
backupsddemo1-sd: reserve.c:673-21 Try match res=FileStorage-demo1-dev1
backupsddemo1-sd: reserve.c:567-21 No usable device found.
...
backupsddemo1-sd: reserve.c:248-21 Inx=7 mntVol=1 exact=0 chgonly=0
low_use=0 any=1
backupsddemo1-sd: reserve.c:466-21 Start find_suit_dev PrefMnt=1
exact=0 suitable=0 chgronly=0 any=1
backupsddemo1-sd: reserve.c:591-21 search res for FileStorage-demo2-dev1
backupsddemo1-sd: reserve.c:673-21 Try match res=FileStorage-demo1-dev1
backupsddemo1-sd: reserve.c:567-21 No usable device found.
backupsddemo1-sd: reserve.c:577-21 Leave find_suit_dev: no dev found.
backupsddemo1-sd: reserve.c:417-21 Fail. !suitable_device ||
!wait_for_device
backupsddemo1-sd: reserve.c:432-21 >dird: 3924 Device
"FileStorage-demo2-dev1" not in SD Device resources or no matching
Media Type or is disabled.
backupsddemo1-sd: dircmd.c:257-21 Command use storage= requests quit
backupsddemo1-sd: vol_mgr.c:197-21 remove_read_vol=Full-0001 JobId=21
found=1
backupsddemo1-sd: vol_mgr.c:197-21 remove_read_vol=Inc-0017 JobId=21
found=1
backupsddemo1-sd: jcr.c:184-21 write_last_jobs seek to 192
On 4/15/26 09:52, Lloyd Brown wrote:
Thanks everyone for your responses. I'm working on creating a
demonstration system with a few VMs, to see what I can figure out.
I'm definitely running into a problem, but the messages are confusing,
so I'm hoping that someone here can spot it. All 3 hosts are running
bacula 15.0.3 on Debian 13, installed from the Debian 13/Trixie
repository. If anyone has any ideas what could be going wrong, I'd
love to hear them.
I'll attach the relevant config files, stripped of the unnecessary
comments, etc., and with passwords redacted. Here's the general
structure:
Host: backupdir - backup director, running `bacula-dir`
Host: backupsddemo{1,2} - running both `bacula-sd` and `bacula-fd`
Both `backupsddemo*` hosts have a single local disk pool stored at
`/backupdata`. There are 2 pools defined as "FullPool" (on
`bacupsddemo1`) and "IncPool" (on `backupsddemo2`). I was able to run
a Full and an Incremental for job `Test-backupsddemo1`. I wrote a
file between the Full and the Incremental, so I could do the restore
for each type and differentiate. The restores went perfectly, and I
could tell by the presence/absence of that file, that it restored the
correct one.
When I try to run the VirtualFull, though, it fails. The relevant
error seems to be the following, taken from the director running with
`-d 200`:
backupdir-dir: msgchan.c:297-14 Rstore=backupsddemo2-sd
backupdir-dir: msgchan.c:308-14 rstore >stored: use
storage=backupsddemo2-sd media_type=File2 pool_name=IncPool
pool_type=Backup append=0 copy=0 stripe=0 wait=1
backupdir-dir: msgchan.c:315-14 >stored: use
device=FileStorage-demo2-dev1
backupdir-dir: getmsg.c:152-14 bget_dirmsg n=-1 msglen=-6 is_stop=0:
backupdir-dir: getmsg.c:152-14 bget_dirmsg n=106 msglen=106
is_stop=0: 3924 Device "FileStorage-demo2-dev1" not in SD Device
resources or no matching Media Type or is disa
bled.
backupdir-dir: msgchan.c:321-14 <stored: 3924 Device
"FileStorage-demo2-dev1" not in SD Device resources or no matching
Media Type or is disabled.
For reference, the corresponding SD running with `-d 200` is showing
no output at all when the VirtualFull tries to run, but does show
output for things like `status storage...`, and when I do the
Incremental to it, or the restore from it.
At this point, I'm confused by the "3924 Device
"FileStorage-demo2-dev1" not in SD Device resources or no matching
Media Type or is disabled.". As far as I can tell, the Media Type
("File2"), the pool ("IncPool") and the device
("FileStorage-demo2-dev1"), are all correct for that SD.
If there were any evidence that it was failing because it was trying
to read the Full backup (or the corresponding `Full-*` file) from SD2,
that would make sense, and confirm that I can't do the VFs this way.
But that's not the evidence I'm seeing.
Thanks,
Lloyd
On 4/8/26 13:24, Lloyd Brown wrote:
Hey, all. I'm in the middle of designing the next generation of our
backup system, which will likely be based on Bacula 15. This time,
we'll be using both disk and tape, vs the disk-only we've run before,
which brings up a question or two that I haven't encountered before.
When running VirtualFull jobs, does the source material (previous
Full, latest Differential, subsequent Incrementals), need to all
reside in the same Pool? In multiple pools but available to the same
SD?
For this system, we're planning on 2 SD hosts, with local disks, and
a tape library attached to one of them. We thought that we could
keep the Fulls/VFs entirely on tape, only store the incrementals on
disk, and write new VFs directly to tape. As a result, we trimmed
down the size of our disk pool for cost reasons (HDDs and SSD are
both crazy expensive right now). I don't think I'll have enough
space in the disk pool to store Incrementals *and* a previous
Full/VF. If that's true, I need to re-think my design a bit. It may
mean we just do true Fulls to tape, and Incrementals on disk, and not
get to use VFs at all.
Thanks,
Lloyd
--
Lloyd Brown
HPC Systems Administrator
Office of Research Computing
Brigham Young University
http://rc.byu.edu
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
