I now filed a bug report here: https://bugs.bareos.org/view.php?id=290
On Do, 2014-05-01 at 17:49 +0200, Alexander E. Fischer wrote: > After a lot of work testing different scenarios, the only way I found so > far to make storage to storage copy jobs work at all is to completely > disable TLS in the storage resource of both storage daemons taking part > in the copy job. If you do that it works as described. > > The things I tried included different approaches to CA Certificate > directives, disabling IPv6, using all kinds of different jobs to be > copied and probably some more mutations of my setup. > > Transport security is an absolute necessity for my backups and therefore > this renders storage to storage copy jobs completely useless to me. > > So is this expected not to work with TLS? Why isn't that mentioned > anywhere? Will this be fixed? As Bacula recently announced the storage > to storage copy feature as well, do they use the same code with the same > limitations? > > On Di, 2014-04-08 at 00:39 +0200, Alexander E. Fischer wrote: > > Hello, > > > > I intend to switch my small Bacula setup to Bareos because of the > > addition of the storage to storage copy jobs. After backing up on a > > local network I want to copy the data to an off-site location. All my > > Bareos components are talking to each other through TLS. I set up a > > test, but I can't get the copy job to actually work. After a copy job is > > started, the two storage daemons seem to authenticate each other and > > then absolutely nothing happens anymore. I'll post my configuration in > > hope of advice how to make it run. > > > > The machine Alpha is the backup server including the Bareos director and > > on-site storage daemon. Beta is a system to be backed up and therefore > > includes a Bareos file daemon. Gamma is supposed to be the off-site > > backup storage consists of yet another Bareos storage daemon. The > > configurations for all the systems and debug log files for both storage > > daemons just after the copy job is executed on the director are attached > > to this mail. Note that some sections have been anonymized for privacy > > and secrity reasons. > > > > Sorry for the previous post. It seems posting through Gmane causes problems > > with attachments.
smime.p7s
Description: S/MIME cryptographic signature
