Re: [Bacula-users] Backing Up a Remote Client

2024-06-26 Thread Bill Arlofski via Bacula-users 

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

2024-06-26 Thread Chris Wilkinson 
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

2024-06-26 Thread Chris Wilkinson 
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

2024-06-26 Thread Bill Arlofski via Bacula-users 

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

2024-06-26 Thread Chris Wilkinson 
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

Re: [Bacula-users] volumes, pools, media types and labels

2024-06-26 Thread Stefan G. Weichinger 

Am 21.06.24 um 16:31 schrieb Radosław Korzeniewski:

Hello,

czw., 20 cze 2024 o 17:46 Stefan G. Weichinger > napisał(a):



Well, it looks for a volume named "Vol-xxx" in the tape loader,
which is
wrong.


Any chance you can share your job log here?


Sure ... quite busy at the moment AND in the last days this didn't 
happen anymore. I have to travel the next 2 days, so I decided to switch 
to "daily" only for now



 > Your configuration seems to be fine, but what Bacula says about your
 > configuration - check bconsole command show job=...
 > Did you reload your configuration after any change?

I restarted the daemons now and then, if that's the same.

 > Are your volumes labeled correctly?

I think so. That one "ghost volume" is created by Bacula somehow.


Any chance you can share your tape volume list here?


For the 2 pools "daily" and "File" (= storage Tape and File) ?
Can do in an hour or two.


There are multiple places it could be wrong. You will never know unless 
you will get a whole picture.

Now we only have a few puzzle pieces which do not match together.


I understand
Will try to come up with more pieces soon ;-)





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