Re: [Bacula-devel] Re: Feature Requests

[Arno L. <al...@it...>]

Hello,

On 20.11.2005 22:13, Frank wrote:

> Arno Lehmann wrote:
> 
>>> Concerning the second part, namely the ability to initiate a backup 
>>> using the connection from the Client.  This is a project that I would 
>>> like to see done, and there are probably a few lines of code already 
>>> written for it, but it was never completed.  If you submit a Feature 
>>> Request for this, I will be happy to include it.   One big problem, 
>>> however, that this request will not solve is that the File daemon 
>>> must be able to contact the Storage daemon. If the Storage daemon is 
>>> behind the firewall and NATed, that would double the size of the 
>>> project.  Please include this aspect in your request if you need it ...
>>
>>
>>
>> Hmm. A good manual section about VPN setup could solve these problems :-)
>>
>> Seriously, using a VPN to backup data would be one good option as long 
>> as transport encryption is not fully implemented. Once transport 
>> encryption is stable, things look different... One possible solution 
>> might be a bacula proxy to run on the firewall... or simply port 
>> forwarding through the firewall (or NAT device)... but, of course, 
>> that doesn't do everything the client initiated backup does: the 
>> schedules would remain a DIR thingie (just right in my opinion ;-)
>>
>> Arno
> 
> 
> Yes, I agree that a VPN setup would solve a lot of problems. However if 
> you work on customer premises, you often are resticted to use their 
> security policy with respect to Internet access. Many companies do not 
> allow you to make a VPN connection to the Internet.

True, and a good thing too. Although I would argue that, if you work on 
customer premises and can't connect to your own system freely, that 
situation is not the best one for backup purposes to start with. Rather, 
I'd expectyour customer to supply the necessary computers or, if 
necessary, server space that would be backed up by them.

> If we could make bacula work using client -> server connections only, 
> then we could use bacula to backup a system in many situations. Even 
> better, we might be able to run a "calling home daemon" on e.g. port 443 
> of the director/storage daemon, because this port is usually open 
> towards the Internet, or you can use a proxy on the customers network to
> access Internet sites via https.

Good idea. Although, for many firewall / IDS setups, it might be 
necessary to encapsulate the whole Bacula connection (actually, both of 
them) into something that looks like http initated by the FD. Many 
firewalls don't allow arbitrary CONNECTs but only HEAD, GET and PUT. 
Mine, for example :-)

> Furthermore, setting op VPN behind a NAT-ing firewall is often a problem 
> which can be solved by this approach as well.

Right.

> With respect to the schedules, I agree: the directory should be in 
> control. However, if the client connects, the "message" can be "call 
> back at this or that time to be backuped", or the connection can be kept 
> idle until the director decides it is time for this client.

To point this out more clearly: I would support your request, but only 
wanted to show that some of the mentioned problems could be solved today.

> Regards,
> 
> Frank
> 

Arno

-- 
IT-Service Lehmann                    al...@it...
Arno Lehmann                  http://www.its-lehmann.de