Re: [Bacula-users] Failed to connect to Client -fd

[Martin Simmons]

Did you run the failing bconsole command while the bacula-dir and the remote
bacula-fd were running with these command line args?  That should make it
print more debug information for both of them.

__Martin


> On Thu, 2 May 2019 11:15:16 +0530, preash raj said:
> 
> Hi Guys,
> 
> I've tried debugging after stopping the services, please check the server
> and client results below. Any clue?
> 
> 
> Bacula Server:
> =
> [root@bacula ~]# bacula-dir -f -d 100
> bacula-dir: dird.c:223-0 Debug level = 100
> bacula-dir: jcr.c:140-0 read_last_jobs seek to 192
> bacula-dir: jcr.c:147-0 Read num_items=10
> bacula-dir: dir_plugins.c:160-0 Load dir plugins
> bacula-dir: dir_plugins.c:162-0 No dir plugin dir!
> bacula-dir: mysql.c:709-0 db_init_database first time
> bacula-dir: mysql.c:177-0 mysql_init done
> bacula-dir: mysql.c:202-0 mysql_real_connect done
> bacula-dir: mysql.c:204-0 db_user=bacula db_name=bacula
> db_password=admin@123
> bacula-dir: mysql.c:227-0 opendb ref=1 connected=1 db=5578f76a53a0
> bacula-dir: mysql.c:249-0 closedb ref=0 connected=1 db=5578f76a53a0
> bacula-dir: mysql.c:256-0 close db=5578f76a53a0
> bacula-dir: dird.c:1215-0 Unlink:
> /var/spool/bacula/bacula-dir.bacula-dir.1653251192.mail
> bacula-dir: pythonlib.c:102-0 No script dir. prog=DirStartUp
> bacula-dir: bnet_server.c:112-0 Addresses host[ipv4:127.0.0.1:9101]
> bacula-dir: job.c:1334-0 wstorage=File
> bacula-dir: job.c:1343-0 wstore=File where=Job resource
> bacula-dir: job.c:1034-0 JobId=0 created
> Job=*JobMonitor*.2019-05-02_01.37.47_01
> 
> [root@bacula ~]# bacula-sd -f -d 100
> bacula-sd: stored_conf.c:704-0 Inserting director res: bacula-mon
> bacula-sd: jcr.c:140-0 read_last_jobs seek to 192
> bacula-sd: jcr.c:147-0 Read num_items=10
> bacula-sd: stored.c:564-0 calling init_dev /bacula/backup
> bacula-sd: bnet_server.c:112-0 Addresses host[ipv4::9103]
> bacula-sd: dev.c:318-0 init_dev: tape=0 dev_name=/bacula/backup
> bacula-sd: stored.c:566-0 SD init done /bacula/backup
> 
> [root@bacula ~]# bacula-fd -f -d 100
> bacula-fd: filed_conf.c:452-0 Inserting director res: bacula-mon
> bacula-fd: jcr.c:140-0 read_last_jobs seek to 192
> bacula-fd: jcr.c:147-0 Read num_items=10
> bacula-fd: pythonlib.c:102-0 No script dir. prog=FDStartUp
> bacula-fd: filed.c:276-0 filed: listening on port 9102
> bacula-fd: bnet_server.c:112-0 Addresses host[ipv4:0.0.0.0:9102]
> 
> 
> Bacula Client:
> =
> root@client [~]# bacula-fd -f -d 100
> bacula-fd: filed_conf.c:452-0 Inserting director res: bacula-mon
> staff.hostdime.in-fd: jcr.c:140-0 read_last_jobs seek to 192
> staff.hostdime.in-fd: jcr.c:147-0 Read num_items=0
> staff.hostdime.in-fd: pythonlib.c:104-0 No script dir. prog=FDStartUp
> staff.hostdime.in-fd: filed.c:275-0 filed: listening on port 9102
> staff.hostdime.in-fd: bnet_server.c:96-0 Addresses host[ipv4:
> 103.13.242.170:9102]
> 
> 
> On Wed, May 1, 2019 at 7:43 PM Martin Simmons  wrote:
> 
> > The output says: "bacula-dir is already running" -- you need to stop the
> > existing process first.
> >
> > __Martin
> >
> >
> > > On Wed, 1 May 2019 17:44:53 +0530, preash raj said:
> > >
> > > Hi,
> > >
> > > I've tried running the Bacula in debug mode and got the below results;
> > I've
> > > checked with the DB and make sure the passwords are correct. Can you guys
> > > please guide me through this.
> > > The bacula files are located under /etc/bacula
> > > =
> > > [root@bacula]# bacula-dir -f -d 100
> > > bacula-dir: dird.c:223-0 Debug level = 100
> > > 01-May 08:12 bacula-dir: ERROR TERMINATION at bsys.c:484
> > > bacula-dir is already running. pid=571
> > > Check file /var/run/bacula-dir.9101.pid
> > >
> > > [root@bacula]# bacula-sd -f -d 100
> > > bacula-sd: stored_conf.c:704-0 Inserting director res: bacula-mon
> > > 01-May 08:12 bacula-sd: ERROR TERMINATION at bsys.c:484
> > > bacula-sd is already running. pid=32149
> > > Check file /var/run/bacula-sd.9103.pid
> > >
> > > [root@bacula]# bacula-fd -f -d 100
> > > bacula-fd: filed_conf.c:452-0 Inserting director res: bacula-mon
> > > 01-May 08:12 bacula-fd: ERROR TERMINATION at bsys.c:484
> > > bacula-fd is already running. pid=32119
> > > Check file /var/run/bacula-fd.9102.pid
> > > =
> > >
> > > On Wed, May 1, 2019 at 3:43 AM Dimitri Maziuk via Bacula-users <
> > > bacula-users@lists.sourceforge.net> wrote:
> > >
> > > > On 4/30/19 11:42 AM, William Muriithi wrote:
> > > > > Heitor,
> > > > >
> > > > > He is using Centos, and version 5.2.13 ended up being whats shipped
> > by
> > > > RedHat. Very understandable
> > > > >
> > > > > Do you know why RedHat does ship something newer?  Like even version
> > 7?
> > > >
> > > > RedHat gets paid for supporting their customers. Presumably they have
> > > > reasons for not supporting newer bacula versions. At least 5.2.13 is
> > > > still in base, there have been several instances where they dropped
> > > 

Re: [Bacula-users] bacula and SQLite

[Dimitri Maziuk via Bacula-users]

On 5/2/19 1:35 PM, Tilman Schmidt wrote:
> Am 02.05.2019 um 00:14 schrieb Phil Stracchino:
>> Surely you could have just bscanned the media you had?
> 
> s/just/hired a few temps who'd/ :-)

Might still be cheaper than hiring one database guru to hand-edit
catalog.sql for psql. ;)

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu



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 and SQLite

[Tilman Schmidt]

Am 02.05.2019 um 00:14 schrieb Phil Stracchino:
> Surely you could have just bscanned the media you had?

s/just/hired a few temps who'd/ :-)



___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Big job keeps failing after server replacement

[Gary Stainburn]

Hi Kern,

Thank you for your response.

On Thursday 02 May 2019 14:23:54 Kern Sibbald wrote:
> Hello,
> 
> Sorry you are having problems.  I note the following things:
> 
> 1. You are running on a *very* old Bacula version.

I am aware of this, but it is the latest version that installs from the Centos 
repositories, and more importantly is only a few revisions higher than was on 
the old (dead) box ensuring that the database format etc would be compatible.

> 2. I am not sure that version of Bacula supports Windows 7, where you
> are getting failures.

This version has successfully worked on Win-Xp, Win7, Win8 and Win10.  I have 
approc 150 workstations all with one of these versions. I also have various 
ages of Linux server which all also work

> 3. As for the errors, it looks like the SD does not have permission to
> open /var/bacula/crownest

When this was first set up I had forgotten to set the owner:group on the 
directory. I did fix this, and the files that are now in that directory have 
the correct owner:group, and were written by the SD (see OP). 

I am aware that this is what the errors are saying, but that does not explain 
how the files are still being created.


> 4. Is /var/bacula/crownnest a network mount (this could explain the
> failures).

This is a file  storage device configured in the SD on the same box as the 
Director.  The directory itself is local to that box

> 5. It looks like it is taking a bit over 2 hours for the SD to mount the
> volume for the backup, and
>     this is approximately the network inactivity timeout period.  So
> possibly the FD<->SD connection
>     is timing out

The client device and the storage device are on different sites, with a 30GB 
connection, doing a 18GB full backup. This would explain the 2 hour run time.

> 6. Try adding HeartBeatInterval = 300 to the Dir, FD, and SD.  I think
> there are 5 places where it must
>     be done (note this is the default in more recent Baculas).

I will investigate where this needs to go and will apply it.

> 
> Recommendations:
> 1. Make sure the SD either has full permissions on all disk files or
> runs as root.

The SD runs as bacula:tape which is the default configuration from the RPM's 
and matches the old box.

As you can see from the directory structure, this should be correct.
[root@lou bacula]# ls -ld / /var/ /var/bacula/ /var/bacula/crownest/ 
/var/bacula/crownest/* /var/bacula/hales/ /var/bacula/hales/*
dr-xr-xr-x. 18 root   root  281 Apr  5 11:13 /
drwxr-xr-x. 27 root   root 4096 Mar  8 13:59 /var/
drwxr-xr-x. 14 bacula bacula   8192 Apr 30 11:28 /var/bacula/
drwxr-xr-x.  2 bacula bacula   4096 May  2 15:43 /var/bacula/crownest/
-rw-r-.  1 bacula tape   5368688828 Apr 30 17:20 
/var/bacula/crownest/crownest72930
-rw-r-.  1 bacula tape   5368688851 Apr 30 17:21 
/var/bacula/crownest/crownest72931
-rw-r-.  1 bacula tape   5368688789 Apr 30 17:21 
/var/bacula/crownest/crownest72932
[snip]
-rw-r-.  1 bacula tape   1745617753 May  2 15:43 
/var/bacula/crownest/crownest72965
drwxr-xr-x.  3 bacula bacula  12288 May  1 23:41 /var/bacula/hales/
-rw-r-.  1 bacula bacula 5368705600 Apr  6 03:29 
/var/bacula/hales/hales68076
-rw-r-.  1 bacula bacula 5368688843 Apr  6 03:29 
/var/bacula/hales/hales68078
-rw-r-.  1 bacula bacula 5368670610 Apr  6 03:51 
/var/bacula/hales/hales68082

(Hales is the storage device that was used previously)

> 2. Make sure any network mounts (NFS, CIFS) are mounted prior to running
> a job

I do not use network mounts

> 3. Add the Heart Beat Interval = 300 in all the required resources --
> this may be documented  in one of the white papers, but is surely documented 
> in the manual,
> look in the index ...

I have added this line to the Director, client and storage resources. I cannot 
see where else it wuold be needed.

> 4. When you get it running think seriously about upgrading.  Though
> RedHat releases an older version
>    of Bacula the builders do create packages for newer version -- or
> look on www.bacula.org for binaries.

I am aware that I am running an old version. Is there a documented upgrade 
path?  I believe the Centos 8 is imminent, and would prefer to stick to 
standard RPM's where possible


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] Big job keeps failing after server replacement

[Kern Sibbald]

Hello,

Sorry you are having problems.  I note the following things:

1. You are running on a *very* old Bacula version.
2. I am not sure that version of Bacula supports Windows 7, where you
are getting failures.
3. As for the errors, it looks like the SD does not have permission to
open /var/bacula/crownest
4. Is /var/bacula/crownnest a network mount (this could explain the
failures).
5. It looks like it is taking a bit over 2 hours for the SD to mount the
volume for the backup, and
    this is approximately the network inactivity timeout period.  So
possibly the FD<->SD connection
    is timing out
6. Try adding HeartBeatInterval = 300 to the Dir, FD, and SD.  I think
there are 5 places where it must
    be done (note this is the default in more recent Baculas).

Recommendations:
1. Make sure the SD either has full permissions on all disk files or
runs as root.
2. Make sure any network mounts (NFS, CIFS) are mounted prior to running
a job
3. Add the Heart Beat Interval = 300 in all the required resources --
this may be documented
    in one of the white papers, but is surely documented in the manual,
look in the index ...
4. When you get it running think seriously about upgrading.  Though
RedHat releases an older version
   of Bacula the builders do create packages for newer version -- or
look on www.bacula.org for binaries.

Best regards,
Kern

On 5/2/19 1:14 PM, Gary Stainburn wrote:
> A few months back, the server running my Director and main storage died.  I 
> managed to boot using a live CD and successfully copied everything onto a new 
> Centos 7 box.  I restored the latest database backup, copied the config files 
> and rsynced the storage.
>
> Amazingly all just continued to work. More amazing seeing as the failed box 
> was a Fedora 19 setup and wa quite old.
>
> The only problem is I have a small number of large jobs that are constantly 
> failing.  Everything appears to work fine, and the client status shows the 
> job as completed OK. See below.
>
> However, the job itself fails, and gets rescheduled. In the case I'm looking 
> at it keeps running a 18GB backup.
>
> In order to try to narrow down the problem, as well as aid job scheduling I 
> have set up a new storage device and pointed this job at that, but it has not 
> made any difference.  Looking at the log file, I see two things
>
> Firstly, error messages about accessing the new storage folder and backup 
> volumes. This is odd as the backup is being successfully written to this 
> device. See below.
>
> Secondly, the job appears to be trying to connect to the FD once the job is 
> complete and is then failing.  I don't konw why this is the case.
>
> Does anyone have any suggestions of what I can do to fix this?
>
> The full job log is available at https://www1.ringways.co.uk/bacula.log
>
> I'm running standard Centos 7 RPM's.  
>
> bacula-console-bat-5.2.13-23.1.el7.x86_64
> bacula-libs-5.2.13-23.1.el7.x86_64
> bacula-console-5.2.13-23.1.el7.x86_64
> bacula-common-5.2.13-23.1.el7.x86_64
> bacula-storage-5.2.13-23.1.el7.x86_64
> bacula-libs-sql-5.2.13-23.1.el7.x86_64
> bacula-client-5.2.13-23.1.el7.x86_64
> bacula-director-5.2.13-23.1.el7.x86_64
> postgresql-docs-9.2.24-1.el7_5.x86_64
> postgresql-upgrade-9.2.24-1.el7_5.x86_64
> postgresql-contrib-9.2.24-1.el7_5.x86_64
> postgresql-devel-9.2.24-1.el7_5.x86_64
> postgresql-9.2.24-1.el7_5.x86_64
> postgresql-server-9.2.24-1.el7_5.x86_64
> postgresql-plperl-9.2.24-1.el7_5.x86_64
> postgresql-libs-9.2.24-1.el7_5.x86_64
>
>
> storage direcortory
> ***
> [root@lou bacula]# ls -ld crownest/ crownest/*
> drwxr-xr-x. 2 bacula bacula   4096 May  2 10:38 crownest/
> -rw-r-. 1 bacula tape   5368688828 Apr 30 17:20 crownest/crownest72930
> -rw-r-. 1 bacula tape   5368688851 Apr 30 17:21 crownest/crownest72931
> -rw-r-. 1 bacula tape   5368688789 Apr 30 17:21 crownest/crownest72932
> -rw-r-. 1 bacula tape   5368669086 Apr 30 21:03 crownest/crownest72933
> -rw-r-. 1 bacula tape   5368676895 Apr 30 22:59 crownest/crownest72934
> -rw-r-. 1 bacula tape   5368688828 Apr 30 23:00 crownest/crownest72935
> -rw-r-. 1 bacula tape   5368688851 Apr 30 23:01 crownest/crownest72936
> -rw-r-. 1 bacula tape   5368688795 Apr 30 23:01 crownest/crownest72937
> -rw-r-. 1 bacula tape   5368696610 May  1 04:24 crownest/crownest72938
> -rw-r-. 1 bacula tape   5368688851 May  1 04:25 crownest/crownest72939
> -rw-r-. 1 bacula tape   5368688851 May  1 04:26 crownest/crownest72940
> -rw-r-. 1 bacula tape   5368696566 May  1 14:03 crownest/crownest72941
> -rw-r-. 1 bacula tape   5368688838 May  1 14:04 crownest/crownest72942
> -rw-r-. 1 bacula tape   5368688851 May  1 14:04 crownest/crownest72943
> -rw-r-. 1 bacula tape   5368688801 May  1 14:05 crownest/crownest72944
> -rw-r-. 1 bacula tape   5368701109 May  1 16:13 crownest/crownest72945
> -rw-r-. 1 bacula tape   5368688850 May  1 16:14 crownest/crownest72947
> -rw-r-. 1 bacula tape

Re: [Bacula-users] Failed to connect to Client -fd

[Alfred Weintoegl]

Try:

netstat -lnp |grep 910
(oder ss -lntp |less -S)


...should show on the Server something like:

... your ip-addr: 9101  ...LISTEN...(bacula-dir)
... 0.0.0.0:9102 ...LISTEN... (bacula-fd)
... 0.0.0.0:9103 ...LISTEN.. .(bacula-sd)


and on the Client (at the other maschine):

... 0.0.0.0:9102 ...LISTEN...

(Listening on 0.0.0.0 means listening from anywhere)

If there is a: "127.0.0.1:9102", then you have to comment out

FDAddress = 127.0.0.1

in bacula-fd.conf  (/etc/bacula/bacula.conf)

(listening on 127.0.0.1 means only listen from this very computer).

And then:
systemctl restart bacula-fd.service


Regards
Alfred


Am 02.05.2019 um 13:47 schrieb Pieter Sybesma via Bacula-users:
Maybe a silly question but do the addresses match at the client and 
director.
Does the name client.hostname from client configuration resolve to the 
address of the client system? If its a different system the ditector 
cant connect to the file daemon. Plus is i rember correctly the file 
daemon should be able to reach the director and the storage daemon in 
version 5.x. Ditector is listening on 127.0.0.1:9101


Pieter

Op 2 mei 2019 om 11:40 heeft preash raj > het volgende geschreven:



I've also tried debbuging bconsole too; please find the result attached.

# bconsole -d 100 -dt
Connecting to Director localhost:9101
02-May-2019 05:30:42 bconsole: bsock.c:236-0 Current 
host[ipv6:::1:9101] All host[ipv6:::1:9101] host[ipv4:127.0.0.1:65535 
]
02-May-2019 05:30:42 bconsole: bsock.c:236-0 Current 
host[ipv4:127.0.0.1:9101 ] All 
host[ipv6:::1:9101] host[ipv4:127.0.0.1:9101 ]
02-May-2019 05:30:42 bconsole: bsock.c:157-0 who=Director daemon 
host=localhost port=9101
02-May-2019 05:30:42 bconsole: cram-md5.c:131-0 cram-get received: 
auth cram-md5 <282828203.1556789442@bacula-dir> ssl=0
02-May-2019 05:30:42 bconsole: cram-md5.c:150-0 sending resp to 
challenge: QT/fB9/mn9woD+IqY5+XlD
02-May-2019 05:30:42 bconsole: cram-md5.c:79-0 send: auth cram-md5 
<1502355591.1556789442@bconsole> ssl=0
02-May-2019 05:30:42 bconsole: cram-md5.c:98-0 Authenticate OK 
yw+DUAdzxH/MeD9/58+PXB

02-May-2019 05:30:42 bconsole: authenticate.c:150-0 >dird: 1000 OK auth
02-May-2019 05:30:42 bconsole: authenticate.c:157-0 bacula-dir Version: 5.2.13 (19 February 2013)

1000 OK: bacula-dir Version: 5.2.13 (19 February 2013)
02-May-2019 05:30:42 bconsole: console.c:1208-0 Opened connection with 
Director daemon

Enter a period to cancel a command.
*status client
The defined Client resources are:
 1: bacula-fd
 2: -fd
 3: -fd
Select Client (File daemon) resource (1-3): 02-May-2019 05:30:48 
bconsole: console.c:329-0 Got poll BNET_SUB_PROMPT

2
Connecting to Client -fd at :9102
Failed to connect to Client -fd.

You have messages.
02-May-2019 05:31:12 bconsole: console.c:329-0 Got poll BNET_EOD


# bconsole
Connecting to Director localhost:9101
1000 OK: bacula-dir Version: 5.2.13 (19 February 2013)
Enter a period to cancel a command.
*setdebug level=100 All
Connecting to Storage daemon File at :9103
3000 OK setdebug=100
Connecting to Client bacula-fd at localhost:9102
2000 OK setdebug=100 trace=0 hangup=0
Connecting to Client -fd at :9102
Failed to connect to Client.
Connecting to Client -fd at :9102
Failed to connect to Client.


On Thu, May 2, 2019 at 11:15 AM preash raj > wrote:


Hi Guys,

I've tried debugging after stopping the services, please check the
server and client results below. Any clue?


Bacula Server:
=
[root@bacula ~]# bacula-dir -f -d 100
bacula-dir: dird.c:223-0 Debug level = 100
bacula-dir: jcr.c:140-0 read_last_jobs seek to 192
bacula-dir: jcr.c:147-0 Read num_items=10
bacula-dir: dir_plugins.c:160-0 Load dir plugins
bacula-dir: dir_plugins.c:162-0 No dir plugin dir!
bacula-dir: mysql.c:709-0 db_init_database first time
bacula-dir: mysql.c:177-0 mysql_init done
bacula-dir: mysql.c:202-0 mysql_real_connect done
bacula-dir: mysql.c:204-0 db_user=bacula db_name=bacula
db_password=admin@123
bacula-dir: mysql.c:227-0 opendb ref=1 connected=1 db=5578f76a53a0
bacula-dir: mysql.c:249-0 closedb ref=0 connected=1 db=5578f76a53a0
bacula-dir: mysql.c:256-0 close db=5578f76a53a0
bacula-dir: dird.c:1215-0 Unlink:
/var/spool/bacula/bacula-dir.bacula-dir.1653251192.mail
bacula-dir: pythonlib.c:102-0 No script dir. prog=DirStartUp
bacula-dir: bnet_server.c:112-0 Addresses host[ipv4:127.0.0.1:9101
]
bacula-dir: job.c:1334-0 wstorage=File
bacula-dir: job.c:1343-0 wstore=File where=Job resource
bacula-dir: job.c:1034-0 JobId=0 created
Job=*JobMonitor*.2019-05-02_01.37.47_01

[root@bacula ~]# bacula-sd -f -d 100
bacula-sd: stored_conf.c:704-0 Inserting director res: bacula-mon
bacula-sd: jcr.c:140-0 read_last_jobs seek to 192
bacula-sd: jcr.c:147-0 Read 

Re: [Bacula-users] Big job keeps failing after server replacement

[Josh Fisher]

On 5/2/2019 7:14 AM, Gary Stainburn wrote:

A few months back, the server running my Director and main storage died.  I 
managed to boot using a live CD and successfully copied everything onto a new 
Centos 7 box.  I restored the latest database backup, copied the config files 
and rsynced the storage.

Amazingly all just continued to work. More amazing seeing as the failed box was 
a Fedora 19 setup and wa quite old.

The only problem is I have a small number of large jobs that are constantly 
failing.  Everything appears to work fine, and the client status shows the job 
as completed OK. See below.

However, the job itself fails, and gets rescheduled. In the case I'm looking at 
it keeps running a 18GB backup.

In order to try to narrow down the problem, as well as aid job scheduling I 
have set up a new storage device and pointed this job at that, but it has not 
made any difference.  Looking at the log file, I see two things

Firstly, error messages about accessing the new storage folder and backup 
volumes. This is odd as the backup is being successfully written to this 
device. See below.

Secondly, the job appears to be trying to connect to the FD once the job is 
complete and is then failing.  I don't konw why this is the case.

Does anyone have any suggestions of what I can do to fix this?

The full job log is available at https://www1.ringways.co.uk/bacula.log

I'm running standard Centos 7 RPM's.

bacula-console-bat-5.2.13-23.1.el7.x86_64
bacula-libs-5.2.13-23.1.el7.x86_64
bacula-console-5.2.13-23.1.el7.x86_64
bacula-common-5.2.13-23.1.el7.x86_64
bacula-storage-5.2.13-23.1.el7.x86_64
bacula-libs-sql-5.2.13-23.1.el7.x86_64
bacula-client-5.2.13-23.1.el7.x86_64
bacula-director-5.2.13-23.1.el7.x86_64
postgresql-docs-9.2.24-1.el7_5.x86_64
postgresql-upgrade-9.2.24-1.el7_5.x86_64
postgresql-contrib-9.2.24-1.el7_5.x86_64
postgresql-devel-9.2.24-1.el7_5.x86_64
postgresql-9.2.24-1.el7_5.x86_64
postgresql-server-9.2.24-1.el7_5.x86_64
postgresql-plperl-9.2.24-1.el7_5.x86_64
postgresql-libs-9.2.24-1.el7_5.x86_64


storage direcortory
***



According to the job log, the permissions on these volume files do not 
allow the bacula-sd daemon r/w access. Determine what user:group 
bacula-sd is running as and either change the volume file permissions or 
else change the user:group that bacula-sd runs as.




[root@lou bacula]# ls -ld crownest/ crownest/*
drwxr-xr-x. 2 bacula bacula   4096 May  2 10:38 crownest/
-rw-r-. 1 bacula tape   5368688828 Apr 30 17:20 crownest/crownest72930
-rw-r-. 1 bacula tape   5368688851 Apr 30 17:21 crownest/crownest72931
-rw-r-. 1 bacula tape   5368688789 Apr 30 17:21 crownest/crownest72932
-rw-r-. 1 bacula tape   5368669086 Apr 30 21:03 crownest/crownest72933
-rw-r-. 1 bacula tape   5368676895 Apr 30 22:59 crownest/crownest72934
-rw-r-. 1 bacula tape   5368688828 Apr 30 23:00 crownest/crownest72935
-rw-r-. 1 bacula tape   5368688851 Apr 30 23:01 crownest/crownest72936
-rw-r-. 1 bacula tape   5368688795 Apr 30 23:01 crownest/crownest72937
-rw-r-. 1 bacula tape   5368696610 May  1 04:24 crownest/crownest72938
-rw-r-. 1 bacula tape   5368688851 May  1 04:25 crownest/crownest72939
-rw-r-. 1 bacula tape   5368688851 May  1 04:26 crownest/crownest72940
-rw-r-. 1 bacula tape   5368696566 May  1 14:03 crownest/crownest72941
-rw-r-. 1 bacula tape   5368688838 May  1 14:04 crownest/crownest72942
-rw-r-. 1 bacula tape   5368688851 May  1 14:04 crownest/crownest72943
-rw-r-. 1 bacula tape   5368688801 May  1 14:05 crownest/crownest72944
-rw-r-. 1 bacula tape   5368701109 May  1 16:13 crownest/crownest72945
-rw-r-. 1 bacula tape   5368688850 May  1 16:14 crownest/crownest72947
-rw-r-. 1 bacula tape   5368688851 May  1 16:14 crownest/crownest72948
-rw-r-. 1 bacula tape   5368647060 May  1 23:38 crownest/crownest72949
-rw-r-. 1 bacula tape   5368654487 May  2 00:29 crownest/crownest72950
-rw-r-. 1 bacula tape   5368659375 May  2 08:28 crownest/crownest72951
-rw-r-. 1 bacula tape   5368688850 May  2 08:29 crownest/crownest72952
-rw-r-. 1 bacula tape   5368688845 May  2 08:30 crownest/crownest72953
-rw-r-. 1 bacula tape   5368662716 May  2 08:52 crownest/crownest72954
-rw-r-. 1 bacula tape   5368671066 May  2 10:37 crownest/crownest72955
-rw-r-. 1 bacula tape   5368688850 May  2 10:37 crownest/crownest72956
-rw-r-. 1 bacula tape   5368688851 May  2 10:38 crownest/crownest72957
-rw-r-. 1 bacula tape   2391406983 May  2 10:38 crownest/crownest72958
[root@lou bacula]# pwd
/var/bacula
[root@lou bacula]#


Client Status
***

*status client=lsaless-fd
Connecting to Client lsaless-fd at 10.3.3.3:9102

esales4-fd Version: 5.2.10 (28 June 2012)  VSS Linux Cross-compile Win64
Daemon started 02-May-19 10:38. Jobs: run=0 running=0.
Microsoft Windows 7 Professional Service Pack 1 (build 7601), 64-bit
  Heap: heap=0 smbytes=239,813 max_bytes=262,885 bufs=409 max_bufs=438
 

Re: [Bacula-users] Failed to connect to Client -fd

[Pieter Sybesma via Bacula-users]

Maybe a silly question but do the addresses match at the client and director.
Does the name client.hostname from client configuration resolve to the address 
of the client system? If its a different system the ditector cant connect to 
the file daemon. Plus is i rember correctly the file daemon should be able to 
reach the director and the storage daemon in version 5.x. Ditector is listening 
on 127.0.0.1:9101

Pieter

> Op 2 mei 2019 om 11:40 heeft preash raj  het volgende 
> geschreven:
> 
> I've also tried debbuging bconsole too; please find the result attached.
> 
> # bconsole -d 100 -dt
> Connecting to Director localhost:9101
> 02-May-2019 05:30:42 bconsole: bsock.c:236-0 Current host[ipv6:::1:9101] All 
> host[ipv6:::1:9101] host[ipv4:127.0.0.1:65535] 
> 02-May-2019 05:30:42 bconsole: bsock.c:236-0 Current 
> host[ipv4:127.0.0.1:9101] All host[ipv6:::1:9101] host[ipv4:127.0.0.1:9101] 
> 02-May-2019 05:30:42 bconsole: bsock.c:157-0 who=Director daemon 
> host=localhost port=9101
> 02-May-2019 05:30:42 bconsole: cram-md5.c:131-0 cram-get received: auth 
> cram-md5 <282828203.1556789442@bacula-dir> ssl=0
> 02-May-2019 05:30:42 bconsole: cram-md5.c:150-0 sending resp to challenge: 
> QT/fB9/mn9woD+IqY5+XlD
> 02-May-2019 05:30:42 bconsole: cram-md5.c:79-0 send: auth cram-md5 
> <1502355591.1556789442@bconsole> ssl=0
> 02-May-2019 05:30:42 bconsole: cram-md5.c:98-0 Authenticate OK 
> yw+DUAdzxH/MeD9/58+PXB
> 02-May-2019 05:30:42 bconsole: authenticate.c:150-0 >dird: 1000 OK auth
> 02-May-2019 05:30:42 bconsole: authenticate.c:157-0  bacula-dir Version: 5.2.13 (19 February 2013)
> 1000 OK: bacula-dir Version: 5.2.13 (19 February 2013)
> 02-May-2019 05:30:42 bconsole: console.c:1208-0 Opened connection with 
> Director daemon
> Enter a period to cancel a command.
> *status client
> The defined Client resources are:
>  1: bacula-fd
>  2: -fd
>  3: -fd
> Select Client (File daemon) resource (1-3): 02-May-2019 05:30:48 bconsole: 
> console.c:329-0 Got poll BNET_SUB_PROMPT
> 2
> Connecting to Client -fd at :9102
> Failed to connect to Client -fd.
> 
> You have messages.
> 02-May-2019 05:31:12 bconsole: console.c:329-0 Got poll BNET_EOD
> 
> 
> # bconsole
> Connecting to Director localhost:9101
> 1000 OK: bacula-dir Version: 5.2.13 (19 February 2013)
> Enter a period to cancel a command.
> *setdebug level=100 All
> Connecting to Storage daemon File at :9103
> 3000 OK setdebug=100
> Connecting to Client bacula-fd at localhost:9102
> 2000 OK setdebug=100 trace=0 hangup=0
> Connecting to Client -fd at :9102
> Failed to connect to Client.
> Connecting to Client -fd at :9102
> Failed to connect to Client.
> 
> 
>> On Thu, May 2, 2019 at 11:15 AM preash raj  wrote:
>> Hi Guys,
>> 
>> I've tried debugging after stopping the services, please check the server 
>> and client results below. Any clue?
>> 
>> 
>> Bacula Server:
>> =
>> [root@bacula ~]# bacula-dir -f -d 100
>> bacula-dir: dird.c:223-0 Debug level = 100
>> bacula-dir: jcr.c:140-0 read_last_jobs seek to 192
>> bacula-dir: jcr.c:147-0 Read num_items=10
>> bacula-dir: dir_plugins.c:160-0 Load dir plugins
>> bacula-dir: dir_plugins.c:162-0 No dir plugin dir!
>> bacula-dir: mysql.c:709-0 db_init_database first time
>> bacula-dir: mysql.c:177-0 mysql_init done
>> bacula-dir: mysql.c:202-0 mysql_real_connect done
>> bacula-dir: mysql.c:204-0 db_user=bacula db_name=bacula db_password=admin@123
>> bacula-dir: mysql.c:227-0 opendb ref=1 connected=1 db=5578f76a53a0
>> bacula-dir: mysql.c:249-0 closedb ref=0 connected=1 db=5578f76a53a0
>> bacula-dir: mysql.c:256-0 close db=5578f76a53a0
>> bacula-dir: dird.c:1215-0 Unlink: 
>> /var/spool/bacula/bacula-dir.bacula-dir.1653251192.mail
>> bacula-dir: pythonlib.c:102-0 No script dir. prog=DirStartUp
>> bacula-dir: bnet_server.c:112-0 Addresses host[ipv4:127.0.0.1:9101] 
>> bacula-dir: job.c:1334-0 wstorage=File
>> bacula-dir: job.c:1343-0 wstore=File where=Job resource
>> bacula-dir: job.c:1034-0 JobId=0 created 
>> Job=*JobMonitor*.2019-05-02_01.37.47_01
>> 
>> [root@bacula ~]# bacula-sd -f -d 100
>> bacula-sd: stored_conf.c:704-0 Inserting director res: bacula-mon
>> bacula-sd: jcr.c:140-0 read_last_jobs seek to 192
>> bacula-sd: jcr.c:147-0 Read num_items=10
>> bacula-sd: stored.c:564-0 calling init_dev /bacula/backup
>> bacula-sd: bnet_server.c:112-0 Addresses host[ipv4::9103] 
>> bacula-sd: dev.c:318-0 init_dev: tape=0 dev_name=/bacula/backup
>> bacula-sd: stored.c:566-0 SD init done /bacula/backup
>> 
>> [root@bacula ~]# bacula-fd -f -d 100
>> bacula-fd: filed_conf.c:452-0 Inserting director res: bacula-mon
>> bacula-fd: jcr.c:140-0 read_last_jobs seek to 192
>> bacula-fd: jcr.c:147-0 Read num_items=10
>> bacula-fd: pythonlib.c:102-0 No script dir. prog=FDStartUp
>> bacula-fd: filed.c:276-0 filed: listening on port 9102
>> bacula-fd: bnet_server.c:112-0 Addresses host[ipv4:0.0.0.0:9102] 
>> 
>> 
>> Bacula Client:
>> =
>> root@client [~]# bacula-fd -f -d 100
>> bacula-fd: filed_conf.c

[Bacula-users] Big job keeps failing after server replacement

[Gary Stainburn]

A few months back, the server running my Director and main storage died.  I 
managed to boot using a live CD and successfully copied everything onto a new 
Centos 7 box.  I restored the latest database backup, copied the config files 
and rsynced the storage.

Amazingly all just continued to work. More amazing seeing as the failed box was 
a Fedora 19 setup and wa quite old.

The only problem is I have a small number of large jobs that are constantly 
failing.  Everything appears to work fine, and the client status shows the job 
as completed OK. See below.

However, the job itself fails, and gets rescheduled. In the case I'm looking at 
it keeps running a 18GB backup.

In order to try to narrow down the problem, as well as aid job scheduling I 
have set up a new storage device and pointed this job at that, but it has not 
made any difference.  Looking at the log file, I see two things

Firstly, error messages about accessing the new storage folder and backup 
volumes. This is odd as the backup is being successfully written to this 
device. See below.

Secondly, the job appears to be trying to connect to the FD once the job is 
complete and is then failing.  I don't konw why this is the case.

Does anyone have any suggestions of what I can do to fix this?

The full job log is available at https://www1.ringways.co.uk/bacula.log

I'm running standard Centos 7 RPM's.  

bacula-console-bat-5.2.13-23.1.el7.x86_64
bacula-libs-5.2.13-23.1.el7.x86_64
bacula-console-5.2.13-23.1.el7.x86_64
bacula-common-5.2.13-23.1.el7.x86_64
bacula-storage-5.2.13-23.1.el7.x86_64
bacula-libs-sql-5.2.13-23.1.el7.x86_64
bacula-client-5.2.13-23.1.el7.x86_64
bacula-director-5.2.13-23.1.el7.x86_64
postgresql-docs-9.2.24-1.el7_5.x86_64
postgresql-upgrade-9.2.24-1.el7_5.x86_64
postgresql-contrib-9.2.24-1.el7_5.x86_64
postgresql-devel-9.2.24-1.el7_5.x86_64
postgresql-9.2.24-1.el7_5.x86_64
postgresql-server-9.2.24-1.el7_5.x86_64
postgresql-plperl-9.2.24-1.el7_5.x86_64
postgresql-libs-9.2.24-1.el7_5.x86_64


storage direcortory
***
[root@lou bacula]# ls -ld crownest/ crownest/*
drwxr-xr-x. 2 bacula bacula   4096 May  2 10:38 crownest/
-rw-r-. 1 bacula tape   5368688828 Apr 30 17:20 crownest/crownest72930
-rw-r-. 1 bacula tape   5368688851 Apr 30 17:21 crownest/crownest72931
-rw-r-. 1 bacula tape   5368688789 Apr 30 17:21 crownest/crownest72932
-rw-r-. 1 bacula tape   5368669086 Apr 30 21:03 crownest/crownest72933
-rw-r-. 1 bacula tape   5368676895 Apr 30 22:59 crownest/crownest72934
-rw-r-. 1 bacula tape   5368688828 Apr 30 23:00 crownest/crownest72935
-rw-r-. 1 bacula tape   5368688851 Apr 30 23:01 crownest/crownest72936
-rw-r-. 1 bacula tape   5368688795 Apr 30 23:01 crownest/crownest72937
-rw-r-. 1 bacula tape   5368696610 May  1 04:24 crownest/crownest72938
-rw-r-. 1 bacula tape   5368688851 May  1 04:25 crownest/crownest72939
-rw-r-. 1 bacula tape   5368688851 May  1 04:26 crownest/crownest72940
-rw-r-. 1 bacula tape   5368696566 May  1 14:03 crownest/crownest72941
-rw-r-. 1 bacula tape   5368688838 May  1 14:04 crownest/crownest72942
-rw-r-. 1 bacula tape   5368688851 May  1 14:04 crownest/crownest72943
-rw-r-. 1 bacula tape   5368688801 May  1 14:05 crownest/crownest72944
-rw-r-. 1 bacula tape   5368701109 May  1 16:13 crownest/crownest72945
-rw-r-. 1 bacula tape   5368688850 May  1 16:14 crownest/crownest72947
-rw-r-. 1 bacula tape   5368688851 May  1 16:14 crownest/crownest72948
-rw-r-. 1 bacula tape   5368647060 May  1 23:38 crownest/crownest72949
-rw-r-. 1 bacula tape   5368654487 May  2 00:29 crownest/crownest72950
-rw-r-. 1 bacula tape   5368659375 May  2 08:28 crownest/crownest72951
-rw-r-. 1 bacula tape   5368688850 May  2 08:29 crownest/crownest72952
-rw-r-. 1 bacula tape   5368688845 May  2 08:30 crownest/crownest72953
-rw-r-. 1 bacula tape   5368662716 May  2 08:52 crownest/crownest72954
-rw-r-. 1 bacula tape   5368671066 May  2 10:37 crownest/crownest72955
-rw-r-. 1 bacula tape   5368688850 May  2 10:37 crownest/crownest72956
-rw-r-. 1 bacula tape   5368688851 May  2 10:38 crownest/crownest72957
-rw-r-. 1 bacula tape   2391406983 May  2 10:38 crownest/crownest72958
[root@lou bacula]# pwd
/var/bacula
[root@lou bacula]# 


Client Status
***

*status client=lsaless-fd
Connecting to Client lsaless-fd at 10.3.3.3:9102

esales4-fd Version: 5.2.10 (28 June 2012)  VSS Linux Cross-compile Win64
Daemon started 02-May-19 10:38. Jobs: run=0 running=0.
Microsoft Windows 7 Professional Service Pack 1 (build 7601), 64-bit
 Heap: heap=0 smbytes=239,813 max_bytes=262,885 bufs=409 max_bufs=438
 Sizeof: boffset_t=8 size_t=8 debug=0 trace=1 
Running Jobs:
JobId 296537 Job lsaless.2019-05-01_19.05.15_19 is running.
VSS Full Backup Job started: 02-May-19 11:36
Files=2,051 Bytes=4,696,598,304 Bytes/sec=2,865,526 Errors=0
Files Examined=2,051
Processing file: C:/Users/user1/AppData/Local/Micros

Re: [Bacula-users] Failed to connect to Client -fd

[preash raj]

I've also tried debbuging bconsole too; please find the result attached.

# bconsole -d 100 -dt
Connecting to Director localhost:9101
02-May-2019 05:30:42 bconsole: bsock.c:236-0 Current host[ipv6:::1:9101]
All host[ipv6:::1:9101] host[ipv4:127.0.0.1:65535]
02-May-2019 05:30:42 bconsole: bsock.c:236-0 Current host[ipv4:
127.0.0.1:9101] All host[ipv6:::1:9101] host[ipv4:127.0.0.1:9101]
02-May-2019 05:30:42 bconsole: bsock.c:157-0 who=Director daemon
host=localhost port=9101
02-May-2019 05:30:42 bconsole: cram-md5.c:131-0 cram-get received: auth
cram-md5 <282828203.1556789442@bacula-dir> ssl=0
02-May-2019 05:30:42 bconsole: cram-md5.c:150-0 sending resp to challenge:
QT/fB9/mn9woD+IqY5+XlD
02-May-2019 05:30:42 bconsole: cram-md5.c:79-0 send: auth cram-md5
<1502355591.1556789442@bconsole> ssl=0
02-May-2019 05:30:42 bconsole: cram-md5.c:98-0 Authenticate OK
yw+DUAdzxH/MeD9/58+PXB
02-May-2019 05:30:42 bconsole: authenticate.c:150-0 >dird: 1000 OK auth
02-May-2019 05:30:42 bconsole: authenticate.c:157-0 -fd
 3: -fd
Select Client (File daemon) resource (1-3): 02-May-2019 05:30:48 bconsole:
console.c:329-0 Got poll BNET_SUB_PROMPT
2
Connecting to Client -fd at :9102
Failed to connect to Client -fd.

You have messages.
02-May-2019 05:31:12 bconsole: console.c:329-0 Got poll BNET_EOD


# bconsole
Connecting to Director localhost:9101
1000 OK: bacula-dir Version: 5.2.13 (19 February 2013)
Enter a period to cancel a command.
*setdebug level=100 All
Connecting to Storage daemon File at :9103
3000 OK setdebug=100
Connecting to Client bacula-fd at localhost:9102
2000 OK setdebug=100 trace=0 hangup=0
Connecting to Client -fd at :9102
Failed to connect to Client.
Connecting to Client -fd at :9102
Failed to connect to Client.


On Thu, May 2, 2019 at 11:15 AM preash raj  wrote:

> Hi Guys,
>
> I've tried debugging after stopping the services, please check the server
> and client results below. Any clue?
>
>
> Bacula Server:
> =
> [root@bacula ~]# bacula-dir -f -d 100
> bacula-dir: dird.c:223-0 Debug level = 100
> bacula-dir: jcr.c:140-0 read_last_jobs seek to 192
> bacula-dir: jcr.c:147-0 Read num_items=10
> bacula-dir: dir_plugins.c:160-0 Load dir plugins
> bacula-dir: dir_plugins.c:162-0 No dir plugin dir!
> bacula-dir: mysql.c:709-0 db_init_database first time
> bacula-dir: mysql.c:177-0 mysql_init done
> bacula-dir: mysql.c:202-0 mysql_real_connect done
> bacula-dir: mysql.c:204-0 db_user=bacula db_name=bacula
> db_password=admin@123
> bacula-dir: mysql.c:227-0 opendb ref=1 connected=1 db=5578f76a53a0
> bacula-dir: mysql.c:249-0 closedb ref=0 connected=1 db=5578f76a53a0
> bacula-dir: mysql.c:256-0 close db=5578f76a53a0
> bacula-dir: dird.c:1215-0 Unlink:
> /var/spool/bacula/bacula-dir.bacula-dir.1653251192.mail
> bacula-dir: pythonlib.c:102-0 No script dir. prog=DirStartUp
> bacula-dir: bnet_server.c:112-0 Addresses host[ipv4:127.0.0.1:9101]
> bacula-dir: job.c:1334-0 wstorage=File
> bacula-dir: job.c:1343-0 wstore=File where=Job resource
> bacula-dir: job.c:1034-0 JobId=0 created
> Job=*JobMonitor*.2019-05-02_01.37.47_01
>
> [root@bacula ~]# bacula-sd -f -d 100
> bacula-sd: stored_conf.c:704-0 Inserting director res: bacula-mon
> bacula-sd: jcr.c:140-0 read_last_jobs seek to 192
> bacula-sd: jcr.c:147-0 Read num_items=10
> bacula-sd: stored.c:564-0 calling init_dev /bacula/backup
> bacula-sd: bnet_server.c:112-0 Addresses host[ipv4::9103]
> bacula-sd: dev.c:318-0 init_dev: tape=0 dev_name=/bacula/backup
> bacula-sd: stored.c:566-0 SD init done /bacula/backup
>
> [root@bacula ~]# bacula-fd -f -d 100
> bacula-fd: filed_conf.c:452-0 Inserting director res: bacula-mon
> bacula-fd: jcr.c:140-0 read_last_jobs seek to 192
> bacula-fd: jcr.c:147-0 Read num_items=10
> bacula-fd: pythonlib.c:102-0 No script dir. prog=FDStartUp
> bacula-fd: filed.c:276-0 filed: listening on port 9102
> bacula-fd: bnet_server.c:112-0 Addresses host[ipv4:0.0.0.0:9102]
>
>
> Bacula Client:
> =
> root@client [~]# bacula-fd -f -d 100
> bacula-fd: filed_conf.c:452-0 Inserting director res: bacula-mon
> staff.hostdime.in-fd: jcr.c:140-0 read_last_jobs seek to 192
> staff.hostdime.in-fd: jcr.c:147-0 Read num_items=0
> staff.hostdime.in-fd: pythonlib.c:104-0 No script dir. prog=FDStartUp
> staff.hostdime.in-fd: filed.c:275-0 filed: listening on port 9102
> staff.hostdime.in-fd: bnet_server.c:96-0 Addresses host[ipv4:
> 103.13.242.170:9102]
>
>
> On Wed, May 1, 2019 at 7:43 PM Martin Simmons 
> wrote:
>
>> The output says: "bacula-dir is already running" -- you need to stop the
>> existing process first.
>>
>> __Martin
>>
>>
>> > On Wed, 1 May 2019 17:44:53 +0530, preash raj said:
>> >
>> > Hi,
>> >
>> > I've tried running the Bacula in debug mode and got the below results;
>> I've
>> > checked with the DB and make sure the passwords are correct. Can you
>> guys
>> > please guide me through this.
>> > The bacula files are located under /etc/bacula
>> > =
>> > [root@bacu