Re: VF and pools

Hey, guys.  This email was in response to an earlier email I sent.  For 
some reason, this one came thru the list before it's parent.  Maybe 
because it has an attachment?  But you can see the text of the delayed 
parent email below, if needed.


Lloyd


On 4/15/26 10:18, Lloyd Brown wrote:
> 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