Hello Josip, I am not sure it is possible to implement what you want. The PKI encryption is Client based, thus unless the real (or original) Client (FD) is involved, it is impossible to perform or change data encryption in any way. SD->SD transfers are only Copy and Migration jobs and not original backups involving the Client, so there is no way the SD can do anything with data encryption other than reading the data and either sending it unmodified to an FD or writing it on some Volume.
Best regards, Kern On 06/09/2014 10:31 AM, Josip Deanovic wrote: > Quoting message written on Monday 2014-06-09 10:23:39 by Kern: >> It is two independent jobs on the SD side: 1. A SD restore job sending >> the data to what it thinks is a "FD" via a comm line. 2. A SD job >> receiving the restore data by simulating a FD but instead of restoring >> the data, it also acts as a SD doing a backup on a device. So each job >> (read, backup) can have its own pool. This is exactly how it works, but >> with a single Director job that controls two SD jobs. > I was thinking about the problem and I believe that PKI directives > responsible for the data encryption would best fit if they would be > set in a pool resource. > > That way it would be possible to enable optional encryption of the > data in case we want to copy data from one pool to another as well > in the case we want to copy data from one poll on another pool dedicated > to a remote storage daemon. > > Regards > ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
