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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users