Re: Remote Client Backup Failing

I have answered my own question. My error was to set the fdaddress
directive in the fd(s) to the remote hostname(s). My /etc/hosts files have
the line

127.0.1.1 <hostname>

The fdaddress directives did exactly that. This is a typical /etc/hosts on
Debian and derivative systems I understand. This directive should be
omitted to force the fd to bind to address 0.0.0.0. With that change port
9102 is open and the remote client backup is working again.

I can't think of a situation where you would not want the fd to bind to
<any> address.

On Sat, 7 Sep 2024, 13:02 Chris Wilkinson, <[email protected]> wrote:

> I have a remote client whose backup is now failing because the FD doesn't
> return a status. Till now it was OK.
>
>  2024-09-07 06:09:28 raspberrypi-dir JobId 7330: Error: Bacula
> raspberrypi-dir 11.0.6 (10Mar22):
>  Build OS: aarch64-unknown-linux-gnu debian 11.3
>  JobId: 7330 Job: nuc2.2024-09-07_06.04.16_55
>  Backup Level: Incremental, since=2024-09-06 03:50:03
>  Client: "nuc2" 11.0.6 (10Mar22) x86_64-pc-linux-gnu,debian,12.1
>  FileSet: "nuc2" 2023-09-26 03:50:00
>  Pool: "nuc2-incremental" (From Job IncPool override)
>  Catalog: "MyCatalog" (From Pool resource)
>  Storage: "remote-clients" (From Command input)
>  Scheduled time: 07-Sep-2024 06:04:16
>  Start time: 07-Sep-2024 06:04:18
>  End time: 07-Sep-2024 06:09:28
>  Elapsed time: 5 mins 10 secs
>  Priority: 10
>  FD Files Written: 0
>  SD Files Written: 0
>  FD Bytes Written: 0 (0 B)
>  SD Bytes Written: 0 (0 B)
>  Rate: 0.0 KB/s
>  Software Compression: None
>  Comm Line Compression: None
>  Snapshot/VSS: no
>  Encryption: no
>  Accurate: no
>  Volume name(s):
>  Volume Session Id: 205
>  Volume Session Time: 1724622798
>  Last Volume Bytes: 156,319,421 (156.3 MB)
>  Non-fatal FD errors: 1
>  SD Errors: 0
>  FD termination status: Error
>  SD termination status: Waiting on FD
>  Termination: *** Backup Error ***
>  2024-09-07 06:09:28 raspberrypi-dir JobId 7330: Fatal error: No Job
> status returned from FD.
>  2024-09-07 06:04:18 raspberrypi-dir JobId 7330: Using Device "qnap-usb3"
> to write.
>  2024-09-07 06:04:18 raspberrypi-dir JobId 7330: Start Backup JobId 7330
> Job=nuc2.2024-09-07_06.04.16_55
>
> I have port 9102 (FD) open on the remote router but when I look at netstat
> on the remote client I see the local address is 127.0.1.1 for port 9102
> whereas it is 0.0.0.0 for other ports.
>
> ~$ netstat -tln
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 127.0.0.1:61209 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:5201 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:22000 0.0.0.0:* LISTEN
> tcp 0 0 127.0.1.1:9102 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:12865 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:8384 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
>
> The other data point is that pointing a port open tool at the public IP of
> the client comes back as 9102 closed which explains the failure. The other
> opened ports are correctly showing as open. I'm guessing that the reason
> for that is the 127.0.1.1.
>
> This all came about after the remote client router was changed from an
> ADSL one to VDSL. I haven't been able to figure out why this one port would
> have a different local address than the others.
>
> This is probably more of a networking question but perhaps someone here
> might have an insight.
>
> Many Thanks
>
> -Chris Wilkinson
>
-Chris Wilkinson

_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users