Re: [Bacula-users] bacula-fd appearing to use wrong storage server
Thanks man You nailed it down. I did comment out this setting and it worked immediately. I did completely overlooked this before. I have now removed it form all my client files and also the template that is used by my client auto-install script. Many thanks, Gaston -Original Message- From: Bill Arlofski via Bacula-users Sent: Friday, 26 April, 2024 00:24 To: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] bacula-fd appearing to use wrong storage server On 4/25/24 3:55 PM, gaston.gloesener--- via Bacula-users wrote: > Thanks for the rplies, > > I include here some of the requested informations. > > First abouth the "bconsole reload", yes I did not do, but I did restart the > director, the storage and file deamons several times after the config change. > Also because I did run them in forground with debug. Hello Gaston, I am re-sending this since the last one I sent I had included a screenshot which will not translate well for search engines, etc... The problem had pointed out in the screenshot was that it looks like you are using the `FDStorageAddress` setting in this client. I believe this is causing your issue.: 8<> *show job=Backup-james1 > Job: name=Backup-james1 JobType=66 level=Incremental Priority=10 Enabled=1 > MaxJobs=1 NumJobs=0 Resched=0 Times=0 Interval=1,800 Spool=0 > WritePartAfterJob=1 > Accurate=1 >--> Client: Name=james1-fd Enabled=1 Address=james1.home > FDport=9102 MaxJobs= 1 NumJobs=0 > JobRetention=6 months FileRetention=2 months AutoPrune=1 > FDStorageAddress=bacula.home > <--- HERE >--> Catalog: name=MyCatalog address=*None* DBport=0 db_name=bacula >db_driver=PostgreSQL db_user=bacula MutliDBConn=0 >--> FileSet: name=Full Set IgnoreFileSetChanges=0 8< If this is not it, we will look a little deeper. :) Hope this helps, Bill -- Bill Arlofski w...@protonmail.com ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-fd appearing to use wrong storage server
On 4/25/24 3:55 PM, gaston.gloesener--- via Bacula-users wrote: Thanks for the rplies, I include here some of the requested informations. First abouth the "bconsole reload", yes I did not do, but I did restart the director, the storage and file deamons several times after the config change. Also because I did run them in forground with debug. Hello Gaston, I am re-sending this since the last one I sent I had included a screenshot which will not translate well for search engines, etc... The problem had pointed out in the screenshot was that it looks like you are using the `FDStorageAddress` setting in this client. I believe this is causing your issue.: 8<> *show job=Backup-james1 Job: name=Backup-james1 JobType=66 level=Incremental Priority=10 Enabled=1 MaxJobs=1 NumJobs=0 Resched=0 Times=0 Interval=1,800 Spool=0 WritePartAfterJob=1 Accurate=1 --> Client: Name=james1-fd Enabled=1 Address=james1.home FDport=9102 MaxJobs= 1 NumJobs=0 JobRetention=6 months FileRetention=2 months AutoPrune=1 FDStorageAddress=bacula.home <--- HERE --> Catalog: name=MyCatalog address=*None* DBport=0 db_name=bacula db_driver=PostgreSQL db_user=bacula MutliDBConn=0 --> FileSet: name=Full Set IgnoreFileSetChanges=0 8< If this is not it, we will look a little deeper. :) Hope this helps, Bill -- Bill Arlofski w...@protonmail.com signature.asc Description: OpenPGP digital signature ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-fd appearing to use wrong storage server
efix=*None* LabelType=0
RecyleOldest=0 PurgeOldest=0 ActionOnPurge=0
MaxVolJobs=1 MaxVolFiles=0 MaxVolBytes=200
MaxPoolBytes=0
MigTime=0 secs MigHiBytes=0 MigLoBytes=0
CacheRetention=0 secs
JobRetention=0 secs FileRetention=0 secs
Catalog=MyCatalog
--> Autochanger: name=vTape2 address=nas1.home SDport=9103 MaxJobs=2 NumJobs=0
DeviceName=vChanger2 MediaType=vtape2 StorageId=5 Autochanger=1
AC group=5 ShareStore=*none*
--> Messages: name=Standard
mailcmd=/opt/bacula/bin/bsmtp -h smtp.pt.lu -f "(Bacula) <%r>" -s
"Bacula: %t %e of %c %l" %r
opcmd=/opt/bacula/bin/bsmtp -h smtp.pt.lu -f "(Bacula) <%r>" -s "Bacula:
Intervention needed for %j" %r
For me thsio all look slike expected.
In the client definition file (below) I did basically only change vTape1 to
vTape2 storage in the pools.
#
# Specification:
#
# ? : Only include if VAR is not empty
# %{}: reüplace by contents of var
# : ^ : capitalize
# : ^^ : upper case
Client {
Name = "james1-fd"
Address = "james1.home"
FdStorageAddress = "bacula.home"
FdPort = 9102
Password = "xxx"
Catalog = "MyCatalog"
FileRetention = 5184000
JobRetention = 15552000
AutoPrune = yes
}
Job {
Name = "Backup-james1"
Type = "Backup"
Client = "james1-fd"
JobDefs = "DefaultJob"
ReRunFailedLevels = yes
Accurate = yes
FullBackupPool = "james1-Full-Pool"
IncrementalBackupPool = "james1-Incr-Pool"
DifferentialBackupPool = "james1-Diff-Pool"
}
Pool {
Name = "james1-Full-Pool"
Description = "Pool for client james1 full backups"
PoolType = "Backup"
LabelFormat = "james1-full-"
MaximumVolumeJobs = 1
MaximumVolumeBytes = 200
VolumeRetention = 8726400
Storage = "vTape2"
Catalog = "MyCatalog"
}
Pool {
Name = "james1-Diff-Pool"
Description = "Pool for client james1 diff backups"
PoolType = "Backup"
LabelFormat = "james1-diff-"
MaximumVolumeJobs = 1
MaximumVolumeBytes = 200
VolumeRetention = 8726400
Storage = "vTape2"
Catalog = "MyCatalog"
}
Pool {
Name = "james1-Incr-Pool"
Description = "Pool for client james1 incremental backups"
PoolType = "Backup"
LabelFormat = "james1-incr-"
MaximumVolumeJobs = 5
MaximumVolumeBytes = 200
VolumeRetention = 3369600
Storage = "vTape2"
Catalog = "MyCatalog"
}
-Original Message-
From: Bill Arlofski via Bacula-users
Sent: Thursday, 25 April, 2024 20:40
To: bacula-users@lists.sourceforge.net
Subject: Re: [Bacula-users] bacula-fd appearing to use wrong storage server
On 4/25/24 3:17 AM, gaston.gloesener--- via Bacula-users wrote:
>
> Until now I did run bacula in a virtual machine running the director
> and storage deamon. The storage daemon was stroing data to files on a shared
> directory as the storage is on a NAS.
>
> Now I have build bacula-sd for the NAS to avoid this duplicate
> transfer. I have configured one client to use the new storage but while it
> uses it, it claims to still contact the “old” storage daemon on the bacula
> node.
Hello Gaston,
A bconsole `show job=` will show what the Director knows about this job.
It is quite possible, and my guess that one of two possible things has happened:
#1: You forgot to issue the bconsole reload command
#2: The Director has reached its default configuration reload limit of 32 and
is no longer reloading
You can check with:
* status director
...and look at the header line:
`Daemon started 24-Apr-24 18:55, conf reloaded 24-Apr-2024 18:55:27`
If the `conf reloaded` time is not recent, then you have hit #2 above and
simply need to restart the Director.
Hope this helps,
Bill
--
Bill Arlofski
w...@protonmail.com
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-fd appearing to use wrong storage server
On 4/25/24 3:17 AM, gaston.gloesener--- via Bacula-users wrote: > Until now I did run bacula in a virtual machine running the director and storage deamon. The storage daemon was stroing data to files on a shared directory as the storage is on a NAS. Now I have build bacula-sd for the NAS to avoid this duplicate transfer. I have configured one client to use the new storage but while it uses it, it claims to still contact the “old” storage daemon on the bacula node. Hello Gaston, A bconsole `show job=` will show what the Director knows about this job. It is quite possible, and my guess that one of two possible things has happened: #1: You forgot to issue the bconsole reload command #2: The Director has reached its default configuration reload limit of 32 and is no longer reloading You can check with: * status director ...and look at the header line: `Daemon started 24-Apr-24 18:55, conf reloaded 24-Apr-2024 18:55:27` If the `conf reloaded` time is not recent, then you have hit #2 above and simply need to restart the Director. Hope this helps, Bill -- Bill Arlofski w...@protonmail.com signature.asc Description: OpenPGP digital signature ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] bacula-fd appearing to use wrong storage server
It would be useful to see the bacula-dir.conf Job and Client resources for
this job and also the full job log.
__Martin
> On Thu, 25 Apr 2024 11:17:18 +0200, gaston gloesener--- via Bacula-users
> said:
>
> Until now I did run bacula in a virtual machine running the director and
> storage deamon. The storage daemon was stroing data to files on a shared
> directory as the storage is on a NAS.
>
> Now I have build bacula-sd for the NAS to avoid this duplicate transfer. I
> have configured one client to use the new storage but while it uses it, it
> claims to still contact the “old” storage daemon on the bacula node.
>
> Using bacula 13.0.4
>
> Here is the storage definition in bacula-dir.conf (vTape1 is the original 1,
> vTape2 the new one):
> Storage {
> Name = "vTape1"
> SdPort = 9103
> Address = "bacula.home "
> Password = "…deleted…"
> Device = "vChanger1"
> MediaType = "vtape1"
> Autochanger = "vTape1"
> MaximumConcurrentJobs = 2
> }
> Storage {
> Name = "vTape2"
> SdPort = 9103
> Address = "nas1.home "
> Password = "…deleted…"
> Device = "vChanger2"
> MediaType = "vtape2"
> Autochanger = "vTape2"
> MaximumConcurrentJobs = 2
> }
>
> The client pool definition looks now like:
>
> Pool {
> Name = "james1-Full-Pool"
> Description = "Pool for client james1 full backups"
> PoolType = "Backup"
> LabelFormat = "james1-full-"
> MaximumVolumeJobs = 1
> MaximumVolumeBytes = 200
> VolumeRetention = 8726400
> Storage = "vTape2"
> Catalog = "MyCatalog"
> }
>
> I have tried a manual and the scheduled job with same result:
>
> *(James1-fd says:
>
> 25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server
> Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103
> s=0x7fa01c01ac88
> 2
>
> The full log:
>
> 25-Apr-2024 01:00:00 james1-fd: bnet_server.c:235-0 Accept
> socket=10.1.10.111.9102:10.1.200.12.45200 s=0x563bfba72728
> 25-Apr-2024 01:00:00 james1-fd: authenticate.c:67-0 authenticate dir: Hello
> Director bacula-dir calling 10002 tlspsk=100
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:365-0 TLSPSK Remote need
> 100
> 25-Apr-2024 01:00:00 james1-fd: authenticate.c:90-0 *** No FD compression to
> DIR
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-0 TLSPSK Local need
> 100
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:563-0 TLSPSK Start PSK
> 25-Apr-2024 01:00:00 james1-fd: bnet.c:96-0 TLS server negotiation
> established.
> 25-Apr-2024 01:00:00 james1-fd: cram-md5.c:68-0 send: auth cram-md5 challenge
> <2032624038.1713999600@james1-fd> ssl=0
> 25-Apr-2024 01:00:00 james1-fd: cram-md5.c:156-0 sending resp to challenge:
> L6/ZMB/xti+re9kmB4sR+D
> 25-Apr-2024 01:00:00 james1-fd: events.c:48-0 Events: code=FC0002
> daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir
> text=Director connection
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:1714-7062 Instantiate
> plugin_ctx=563bfbb34378 JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378
> JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0
> plugin=bpipe-fd.so plen=5
> 25-Apr-2024 01:00:00 james1-fd: job.c:2499-7062 level_cmd: level = full
> mtime_only=0
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378
> JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0
> plugin=bpipe-fd.so plen=5
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378
> JobId=7062
> 25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0
> plugin=bpipe-fd.so plen=5
> 25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server
> Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103
> s=0x7fa01c01ac88
> 25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-7062 TLSPSK Local
> need 100
> 25-Apr-2024 01:00:05 james1-fd: hello.c:183-7062 Recv caps from SD failed.
> ERR=Success
> 25-Apr-2024 01:00:05 james1-fd: hello.c:185-7062 Recv caps from SD failed.
> ERR=Success
> 25-Apr-2024 01:00:05 james1-fd: events.c:48-7062 Events: code=FC0001
> daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir
> text=Director disconnection
> 25-Apr-2024 01:00:05 james1-fd: fd_plugins.c:1749-7062 Free instance
> plugin_ctx=563bfbb34378 JobId=7062
>
> The job log on the director confirms:
>
> 2024-04-25 01:00:00 bacula-dir JobId 7062: Connected to Storage "vTape2" at
> bacula.home:9103 with TLS
>
> So correct storage but bad server. Note that vTape 2 has always been pointing
> to nas1 (not bacula) and the director (as well as james1-fd and both storage
> deamons) was restarted several times
>
> The storage daemon on nas1 reports only a connection from the director, the
> ip address of the client (10.1.10.111) is never seen:
>
> 25-Apr-2024 01:00:00 nas1-sd: bnet_server.c:235-0 Accept
>
[Bacula-users] bacula-fd appearing to use wrong storage server
Until now I did run bacula in a virtual machine running the director and
storage deamon. The storage daemon was stroing data to files on a shared
directory as the storage is on a NAS.
Now I have build bacula-sd for the NAS to avoid this duplicate transfer. I have
configured one client to use the new storage but while it uses it, it claims to
still contact the “old” storage daemon on the bacula node.
Using bacula 13.0.4
Here is the storage definition in bacula-dir.conf (vTape1 is the original 1,
vTape2 the new one):
Storage {
Name = "vTape1"
SdPort = 9103
Address = "bacula.home "
Password = "…deleted…"
Device = "vChanger1"
MediaType = "vtape1"
Autochanger = "vTape1"
MaximumConcurrentJobs = 2
}
Storage {
Name = "vTape2"
SdPort = 9103
Address = "nas1.home "
Password = "…deleted…"
Device = "vChanger2"
MediaType = "vtape2"
Autochanger = "vTape2"
MaximumConcurrentJobs = 2
}
The client pool definition looks now like:
Pool {
Name = "james1-Full-Pool"
Description = "Pool for client james1 full backups"
PoolType = "Backup"
LabelFormat = "james1-full-"
MaximumVolumeJobs = 1
MaximumVolumeBytes = 200
VolumeRetention = 8726400
Storage = "vTape2"
Catalog = "MyCatalog"
}
I have tried a manual and the scheduled job with same result:
James1-fd says:
25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server
Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103
s=0x7fa01c01ac88
2
The full log:
25-Apr-2024 01:00:00 james1-fd: bnet_server.c:235-0 Accept
socket=10.1.10.111.9102:10.1.200.12.45200 s=0x563bfba72728
25-Apr-2024 01:00:00 james1-fd: authenticate.c:67-0 authenticate dir: Hello
Director bacula-dir calling 10002 tlspsk=100
25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:365-0 TLSPSK Remote need 100
25-Apr-2024 01:00:00 james1-fd: authenticate.c:90-0 *** No FD compression to DIR
25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-0 TLSPSK Local need 100
25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:563-0 TLSPSK Start PSK
25-Apr-2024 01:00:00 james1-fd: bnet.c:96-0 TLS server negotiation established.
25-Apr-2024 01:00:00 james1-fd: cram-md5.c:68-0 send: auth cram-md5 challenge
<2032624038.1713999600@james1-fd> ssl=0
25-Apr-2024 01:00:00 james1-fd: cram-md5.c:156-0 sending resp to challenge:
L6/ZMB/xti+re9kmB4sR+D
25-Apr-2024 01:00:00 james1-fd: events.c:48-0 Events: code=FC0002
daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir
text=Director connection
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:1714-7062 Instantiate
plugin_ctx=563bfbb34378 JobId=7062
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378
JobId=7062
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0
plugin=bpipe-fd.so plen=5
25-Apr-2024 01:00:00 james1-fd: job.c:2499-7062 level_cmd: level = full
mtime_only=0
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378
JobId=7062
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0
plugin=bpipe-fd.so plen=5
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:254-7062 plugin_ctx=563bfbb34378
JobId=7062
25-Apr-2024 01:00:00 james1-fd: fd_plugins.c:147-7062 name= len=0
plugin=bpipe-fd.so plen=5
25-Apr-2024 01:00:00 james1-fd: bsockcore.c:472-7062 OK connected to server
Storage daemon bacula.home:9103. socket=10.1.10.111.60144:10.1.200.12.9103
s=0x7fa01c01ac88
25-Apr-2024 01:00:00 james1-fd: authenticatebase.cc:335-7062 TLSPSK Local need
100
25-Apr-2024 01:00:05 james1-fd: hello.c:183-7062 Recv caps from SD failed.
ERR=Success
25-Apr-2024 01:00:05 james1-fd: hello.c:185-7062 Recv caps from SD failed.
ERR=Success
25-Apr-2024 01:00:05 james1-fd: events.c:48-7062 Events: code=FC0001
daemon=james1-fd ref=0x7fa01c00b0a8 type=connection source=bacula-dir
text=Director disconnection
25-Apr-2024 01:00:05 james1-fd: fd_plugins.c:1749-7062 Free instance
plugin_ctx=563bfbb34378 JobId=7062
The job log on the director confirms:
2024-04-25 01:00:00 bacula-dir JobId 7062: Connected to Storage "vTape2" at
bacula.home:9103 with TLS
So correct storage but bad server. Note that vTape 2 has always been pointing
to nas1 (not bacula) and the director (as well as james1-fd and both storage
deamons) was restarted several times
The storage daemon on nas1 reports only a connection from the director, the ip
address of the client (10.1.10.111) is never seen:
25-Apr-2024 01:00:00 nas1-sd: bnet_server.c:235-0 Accept
socket=10.1.11.1.9103:10.1.200.12.40796 s=0x555d9b1de468
25-Apr-2024 01:00:00 nas1-sd: dircmd.c:195-0 Got a DIR connection at
25-Apr-2024 01:00:00
25-Apr-2024 01:00:00 nas1-sd: authenticatebase.cc:365-0 TLSPSK Remote need 100
25-Apr-2024 01:00:00 nas1-sd: authenticatebase.cc:335-0 TLSPSK Local need 100
25-Apr-2024 01:00:00 nas1-sd: authenticatebase.cc:563-0 TLSPSK Start PSK
