On Sunday 16 April 2006 21:16, Francisco Reyes wrote: > Landon Fuller writes: > > Using the code in CVS it is possible to encrypt data at the FD, prior to > > being sent to the Storage Daemon. > > Thanks much for the info. Just trying to learn as much as I can both about > the operational side as well as the concepts. > > > This FD encryption will be (as far as I know) in the next release. > > Great. will likely start using it then. I am too much of a newbie to do CVS > code. :-)
I always am happy to have users use the current CVS development code, but please be aware that it is code under development, which means that it will definitely have more bugs than the officially released code. > > > don't know if I'll have time to implement SD encryption before the next > > release. > > Why would you want encryption on the SD? I could imagine three good reasons for this: 1. You want *all* data to be encrypted and you don't want to worry about setting up the encryption in every Client. I.e. it is one point of control for encryption. 2. You want to control the encryption key(s) on a single machine (SD encryption) rather than on all machines (FD encryption). This can significantly increase security of the encrypted data as the only way to compromise it would be to compromise the SD rather than any one of a number of clients. 3. If you want *everything* on the Volume encrypted, you must do it in the SD. With FD encryption, only the data is encrypted, but the "attributes" (i.e. filenames, permissions, ...) are not and cannot be encrypted, as they must be readable by the SD to extract the data. > By having encryption in the FD you distribute the work load. I don't know > how (or even if you do) compression done on the FD is alwo where I would > think it make the most sense. > > I may be missguided, but I see it this way. > > FD encryption may benefit the most, larger organizations where there are > numerous clients to be backed up and often times several backup jobs run at > the same time. In this case distributing the load for encryption and > compression is more efficient than having to spend on a big machine. > > SD encryption I think may benefit organizations that have a large number of > clients to backup, but that the clients may be either very taxed or old. > This way just investing good machine(s) for the SD server(s) may be more > effcient. > > Obviously if one could specify where it can be done then that is the most > flexible setup. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Best regards, Kern ("> /\ V_V ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
