Bacula-users

Re: [Bacula-users] Remote backup through NAT?

2016-01-27 14:01:52
Subject: Re: [Bacula-users] Remote backup through NAT?
From: Michael Munger <michael AT highpoweredhelp DOT com>
To: 'Wanderlei Huttel' <wanderleihuttel AT gmail DOT com>
Date: Wed, 27 Jan 2016 18:55:58 +0000
Just as a follow up, moving to 7.4.x solved the problem. The secret is FD 
Storage Address.

For future searchers / Googlers:

The FD Storage  Address is defined for a given client, and that client will 
then use it to send all the storage requests to.

Thus:
       If FD Storage Address is defined for a client:
        a. It should show the WAN address for the firewall / border device to 
your network
        b. You must have port forwarding set appropriately


Michael Munger, dCAP, MCPS, MCNPS, MBSS
High Powered Help, Inc.
Microsoft Certified Professional
Microsoft Certified Small Business Specialist
Digium Certified Asterisk Professional
michael AT highpoweredhelp DOT com

From: Wanderlei Huttel [mailto:wanderleihuttel AT gmail DOT com] 
Sent: Tuesday, January 26, 2016 4:32 PM
To: Michael Munger
Cc: bacula-users AT lists.sourceforge DOT net
Subject: Re: [Bacula-users] Remote backup through NAT?

Hello Michael

I'm not sure if is it possible in older versions like yours.
Take a look below

------------------------------------------------------------------------------------------
New Features in 7.2.0

FD Storage Address

When the Director is behind a NAT, in a WAN area, to connect to the 
StorageDaemon, the Director uses an ``external'' ip address, and the FileDaemon 
should use an ``internal'' IP address to contact the StorageDaemon.

The normal way to handle this situation is to use a canonical name such as 
``storage-server'' that will be resolved on the Director side as the WAN 
address and on the Client side as the LAN address. This is now possible to 
configure this parameter using the new directive FDStorageAddress in the 
Storage or Client resource.

Storage {
     Name = storage1
     Address = 65.1.1.1
     FD Storage Address = 10.0.0.1
     SD Port = 9103
     ...
}
 Client {
      Name = client1
      Address = 65.1.1.2
      FD Storage Address = 10.0.0.1
      FD Port = 9102
      ...
 }
Note that using the Client FDStorageAddress directive will not allow to use 
multiple Storage Daemon, all Backup or Restore requests will be sent to the 
specified FDStorageAddress.
------------------------------------------------------------------------------------------

Bacula is already in 7.4.0 version.
It's highly recommended upgrading.

Best Regards
Wanderlei


2016-01-26 19:00 GMT-02:00 Michael Munger <michael AT highpoweredhelp DOT com>:
Hello everyone, this is my first time mailing this list, so guidance on 
etiquette is welcomed.

TLDR; = I have a server outside the firewall (john-fd is on 173.165.161.165) 
trying to backup to a storage daemon inside my LAN (d8-sd is on 
192.168.250.202). I have port forwarded (in my Monowall) tcp/9103, and I can 
successfully telnet from the remote server to the local sd. But, the console is 
forever saying: "...waiting on storage file" when I run the job.

What I've done:
* Scoured the docs and tutorials
* Exhausted Google (and DuckDuckGo)
* Confirmed The software versions are all 5.6.2 (learned that one the hard way 
dealing with a Windows client!)
* Shutdown bacula-sd and confirmed telnet no longer connects, and when I 
restart bacula-sd it DOES connect.
* shutdown the firewall (everywhere - for testing) no joy
* opened 9101 and 9102 on our firewall and forwarded them to 192.168.250.202 
just in case any bacula service wants to communicate.
* used netstat -tanop to watch the telnet connections come in from the remote 
server to confirm that NAT is working properly.

What I think is going on:
D8-FD (the file director on the server where bacula-sd, the pools, and volumes 
reside) can connect to the remote server, and can issue commands to run the 
backup job. But, when the remote fd tries to connect back (through the firewall 
from "outside -> in") to the storage daemon, it's failing - despite the fact 
that the NAT is setup properly, and I can telnet through it.

That doesn't make sense to me because it should either work or be broken. So, 
I'm thinking that if I can telnet to it, then the remote fd should also be able 
to work with it. Nmap also shows the port as open and reachable.

How else can I troubleshoot this "waiting on storage" problem?

PS. I am about 18 hours in to working with Bacula. Fantastic product, but don't 
be afraid to assume I have missed something rudimentary. I have two machines on 
the LAN working and backing up, so I have had some success, but it's still 
possible I've missed something simple...

Michael Munger, dCAP, MCPS, MCNPS, MBSS
High Powered Help, Inc.
Microsoft Certified Professional
Microsoft Certified Small Business Specialist
Digium Certified Asterisk Professional
michael AT highpoweredhelp DOT com


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users