Re: [Bacula-users] Backing Up a Remote Client
On 6/27/24 8:50 AM, Chris Wilkinson wrote: Oops - typo in my message. It should be *Set storage resource 'FDStorageAddress=' Which is what actually have but wrote it here wrong.âšī¸ No worries. I saw that and knew what you meant. :) I'm not aware of NAT reflection being set in the router; no such option that I can find. I can't see sending local backup data out and back is an issue since the data is encrypted but anyway it's set up now as you suggested so moot. Well, what I mean is that your local FD -> SD traffic would hit the firewall, pass through it to its external IP, then be NAT'ted back into your local network. So, nothing going to the Internet from local, but still using up the firewall's network bandwidth and CPU cycles unnecessarily. I think you seem to be in good shape now. :) Best regards, 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] Backing Up a Remote Client
Oops - typo in my message. It should be *Set storage resource 'FDStorageAddress=' Which is what actually have but wrote it here wrong.âšī¸ I'm not aware of NAT reflection being set in the router; no such option that I can find. I can't see sending local backup data out and back is an issue since the data is encrypted but anyway it's set up now as you suggested so moot. -Chris- On Thu, 27 Jun 2024, 15:19 Bill Arlofski, wrote: > On 6/27/24 2:54 AM, Chris Wilkinson wrote: > > I made the additional changes you suggested. > > > > *Removed FD port open on remote router > > *Set storage resource 'Address=' > > *Set storage resource 'FDStorageAddress=' > > > > I re-tested local and remote backups and these seem to be working fine. > > Excellent! \o/ > > Next up Client Initiated Backups! heh > > > > These changes were not absolutely required as local backups continued to > work when I had storage resource 'Address= > FQDN of remote site>' and without the 'FDStorageAddress=' directive. I > presume this was because I had opened ports 9101-9103 > > to the DIR/SD host on the local router as part of my previous attempts > and I haven't undone any of them. > > I didn't say it yesterday, but I was suspecting that if local and remote > FD -> SD connections for backups were all still > working after you set the Storage's Address to the external IP of the > firewall, then it mu > st be that NAT reflection was > set/enabled on your firewall. > > Yes sure, that will work, but do you really want all of your backup data > traversing your firewall? :) > > > > Thanks for your help > > > > -Chris- > > You're welcome! > > I am glad that my curiosity to set this exact configuration up last week > (for fun) was well timed. :) > > > Best regards, > 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] Backing Up a Remote Client
On 6/27/24 2:54 AM, Chris Wilkinson wrote: I made the additional changes you suggested. *Removed FD port open on remote router *Set storage resource 'Address=' *Set storage resource 'FDStorageAddress=' I re-tested local and remote backups and these seem to be working fine. Excellent! \o/ Next up Client Initiated Backups! heh These changes were not absolutely required as local backups continued to work when I had storage resource 'Address=FQDN of remote site>' and without the 'FDStorageAddress=' directive. I presume this was because I had opened ports 9101-9103 to the DIR/SD host on the local router as part of my previous attempts and I haven't undone any of them. I didn't say it yesterday, but I was suspecting that if local and remote FD -> SD connections for backups were all still working after you set the Storage's Address to the external IP of the firewall, then it mu st be that NAT reflection was set/enabled on your firewall. Yes sure, that will work, but do you really want all of your backup data traversing your firewall? :) Thanks for your help -Chris- You're welcome! I am glad that my curiosity to set this exact configuration up last week (for fun) was well timed. :) Best regards, 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] Backing Up a Remote Client
I made the additional changes you suggested. *Removed FD port open on remote router *Set storage resource 'Address=' *Set storage resource 'FDStorageAddress=' I re-tested local and remote backups and these seem to be working fine. These changes were not absolutely required as local backups continued to work when I had storage resource 'Address=' and without the 'FDStorageAddress=' directive. I presume this was because I had opened ports 9101-9103 to the DIR/SD host on the local router as part of my previous attempts and I haven't undone any of them. Thanks for your help -Chris- On Wed, 26 Jun 2024, 22:50 Bill Arlofski, wrote: > On 6/26/24 3:31 PM, Chris Wilkinson wrote: > > > > Your tips were bang on. I implemented this and it is working. > > Excellent! \o/ > > > > The other steps required were to forward ports on the routers at each > end > > This should not be necessary at the remote site(s). The remote clients > will be making outbound calls to the Internet, unless > you have NAT inside NAT or something "interesting" going on at the remote > site(s). :) > > > > and change the DIR storage resource Address= from a local lan address > to the public FQDN. > > Uff yes, sorry, I missed a step! :) > > > The part I missed (which you solved differently, but not the best way if > this Storage is needed to be used by other internal > Clients) is to instead leave the SD's `Address = ` alone and set the > `FDStorageAddress = firewall>` in the Director's configuration resource for this (and any > other external) Clients. > > This way, all your normal internal backups/clients that use this same SD > can conn > ect to it using its normal `Address = internal IP or FQDN>` and only these external clients will have the > FDStorageAddress set to connect to the Main site's > external firewall IP or FQDN. > > > > Thank you. > > > > -Chris- > > You're welcome! > > Hope these additional tips help to clean things up even more. > > Best regards, > 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] Backing Up a Remote Client
On 6/26/24 3:31 PM, Chris Wilkinson wrote: > Your tips were bang on. I implemented this and it is working. Excellent! \o/ The other steps required were to forward ports on the routers at each end This should not be necessary at the remote site(s). The remote clients will be making outbound calls to the Internet, unless you have NAT inside NAT or something "interesting" going on at the remote site(s). :) > and change the DIR storage resource Address= from a local lan address to the public FQDN. Uff yes, sorry, I missed a step! :) The part I missed (which you solved differently, but not the best way if this Storage is needed to be used by other internal Clients) is to instead leave the SD's `Address = ` alone and set the `FDStorageAddress = firewall>` in the Director's configuration resource for this (and any other external) Clients. This way, all your normal internal backups/clients that use this same SD can conn ect to it using its normal `Address = internal IP or FQDN>` and only these external clients will have the FDStorageAddress set to connect to the Main site's external firewall IP or FQDN. Thank you. -Chris- You're welcome! Hope these additional tips help to clean things up even more. Best regards, 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] Backing Up a Remote Client
Your tips were bang on. I implemented this and it is working. The other steps required were to forward ports on the routers at each end and change the DIR storage resource Address= from a local lan address to the public FQDN. Thank you. -Chris- On Wed, 26 Jun 2024, 18:18 Bill Arlofski via Bacula-users, < bacula-users@lists.sourceforge.net> wrote: > On 6/26/24 10:44 AM, Chris Wilkinson wrote: > > I'm seeking some advice on configuring the backup of a remote client. > > > > Up till now all clients were located on the same local lan that hosts > the Director, File and Storage Daemons. The whole lan > > is behind a nat'd router. One of these clients has now moved to a remote > site, also behind a nat'd router so my existing FD > > for this client doesn't work. > > > > As I understand Bacula, the sequence of operations is: > > DIR > FD : command to begin > > FD > SD : send data from fd to sd > > and there will be messages to the DIR also. > > Hello Chris, > > > It is more like: > > 1: DIR --> SD > 2: DIR --> FD (unless FD is configured to connect to the DIR), then it > is FD --> DIR > 3: FD --> SD (unless the Director's Client resource has "SDCallsClient > = yes"), then it is SD --> FD > > > > For this to work for a remote client, all Daemons must be addressable by > FQDNs and therefore the use of local addresses is > > not possible. > > > > One thought that occurs to me is that router ports 9101-9103 can be > opened to address the Daemons as :port. This > > won't work for the SD which a mounted cifs share due to the storage > being a locked down NAS with no possibility of installing > > an SD. > > > > Appreciate any thoughts or suggestions you might have. > > The "best" way to do this is configure your remote FD(s) to call into the > Director. They can be configured to make the > connection on a schedule, or to try to make the connection and stay > connected - reconnecting at startup, and when disconnected. > > You will need to configure the firewall on the SD side to allow and > forward the connection into the DIR and the SD. > > There is a section int he manual about Clients behind NAT, and also Client > initiated backups. If you get stuck, just ask... > > For fun, I recently just configured and tested this exact type of "FD > calls Director" configuration here. > > I know, who does this for fun, right? lol đđ¤ˇđ¤Ļ > > > Best regards, > Bill > > -- > Bill Arlofski > w...@protonmail.com > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Backing Up a Remote Client
That's very helpful. On reflection, the storage being a cifs share shouldn't be a show stopper as I first thought. The SD (and thus the storage) should be contactable via a port opening. I'll look at my current attempt again in the light of your explication. -Chris- On Wed, 26 Jun 2024, 18:18 Bill Arlofski via Bacula-users, < bacula-users@lists.sourceforge.net> wrote: > On 6/26/24 10:44 AM, Chris Wilkinson wrote: > > I'm seeking some advice on configuring the backup of a remote client. > > > > Up till now all clients were located on the same local lan that hosts > the Director, File and Storage Daemons. The whole lan > > is behind a nat'd router. One of these clients has now moved to a remote > site, also behind a nat'd router so my existing FD > > for this client doesn't work. > > > > As I understand Bacula, the sequence of operations is: > > DIR > FD : command to begin > > FD > SD : send data from fd to sd > > and there will be messages to the DIR also. > > Hello Chris, > > > It is more like: > > 1: DIR --> SD > 2: DIR --> FD (unless FD is configured to connect to the DIR), then it > is FD --> DIR > 3: FD --> SD (unless the Director's Client resource has "SDCallsClient > = yes"), then it is SD --> FD > > > > For this to work for a remote client, all Daemons must be addressable by > FQDNs and therefore the use of local addresses is > > not possible. > > > > One thought that occurs to me is that router ports 9101-9103 can be > opened to address the Daemons as :port. This > > won't work for the SD which a mounted cifs share due to the storage > being a locked down NAS with no possibility of installing > > an SD. > > > > Appreciate any thoughts or suggestions you might have. > > The "best" way to do this is configure your remote FD(s) to call into the > Director. They can be configured to make the > connection on a schedule, or to try to make the connection and stay > connected - reconnecting at startup, and when disconnected. > > You will need to configure the firewall on the SD side to allow and > forward the connection into the DIR and the SD. > > There is a section int he manual about Clients behind NAT, and also Client > initiated backups. If you get stuck, just ask... > > For fun, I recently just configured and tested this exact type of "FD > calls Director" configuration here. > > I know, who does this for fun, right? lol đđ¤ˇđ¤Ļ > > > Best regards, > Bill > > -- > Bill Arlofski > w...@protonmail.com > > ___ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Backing Up a Remote Client
On 6/26/24 10:44 AM, Chris Wilkinson wrote: I'm seeking some advice on configuring the backup of a remote client. Up till now all clients were located on the same local lan that hosts the Director, File and Storage Daemons. The whole lan is behind a nat'd router. One of these clients has now moved to a remote site, also behind a nat'd router so my existing FD for this client doesn't work. As I understand Bacula, the sequence of operations is: DIR > FD : command to begin FD > SD : send data from fd to sd and there will be messages to the DIR also. Hello Chris, It is more like: 1: DIR --> SD 2: DIR --> FD (unless FD is configured to connect to the DIR), then it is FD --> DIR 3: FD --> SD (unless the Director's Client resource has "SDCallsClient = yes"), then it is SD --> FD For this to work for a remote client, all Daemons must be addressable by FQDNs and therefore the use of local addresses is not possible. One thought that occurs to me is that router ports 9101-9103 can be opened to address the Daemons as :port. This won't work for the SD which a mounted cifs share due to the storage being a locked down NAS with no possibility of installing an SD. Appreciate any thoughts or suggestions you might have. The "best" way to do this is configure your remote FD(s) to call into the Director. They can be configured to make the connection on a schedule, or to try to make the connection and stay connected - reconnecting at startup, and when disconnected. You will need to configure the firewall on the SD side to allow and forward the connection into the DIR and the SD. There is a section int he manual about Clients behind NAT, and also Client initiated backups. If you get stuck, just ask... For fun, I recently just configured and tested this exact type of "FD calls Director" configuration here. I know, who does this for fun, right? lol đđ¤ˇđ¤Ļ Best regards, 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
[Bacula-users] Backing Up a Remote Client
I'm seeking some advice on configuring the backup of a remote client. Up till now all clients were located on the same local lan that hosts the Director, File and Storage Daemons. The whole lan is behind a nat'd router. One of these clients has now moved to a remote site, also behind a nat'd router so my existing FD for this client doesn't work. As I understand Bacula, the sequence of operations is: DIR > FD : command to begin FD > SD : send data from fd to sd and there will be messages to the DIR also. For this to work for a remote client, all Daemons must be addressable by FQDNs and therefore the use of local addresses is not possible. One thought that occurs to me is that router ports 9101-9103 can be opened to address the Daemons as :port. This won't work for the SD which a mounted cifs share due to the storage being a locked down NAS with no possibility of installing an SD. Appreciate any thoughts or suggestions you might have. TIA -Chris Wilkinson ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
