Ingo,
Yes, your idea to completely leave to the implementation is perhaps better (URL specification eg. ?compress=on?algo=AES256). This way the backup kernel has no way of determining whether it should compress/encrypt, but leave it to the user to specify to each BSM.
The question we have to ask; Do we see it as the responsibility of the backup kernel to encrypt the data? The user may very well like the data to be encrypted, but they would have to choose a BSM fulfilling their requirements rather than relying on MySQL. Why would we want to spend 10ths of thousands lines of code on implementing a complete KMS?
My opinion is that the backup kernel is responsible for backup and restore operations. The BSMs are responsible for storing the data, be it raw, compressed, and/or encrypted.
Why duplicate functionality? Why add support for compression and encryption in backup kernel, as well as in the BSMs? We have to make an design decision that either we only allow the backup kernel to do it, or only allow the BSMs to do it. My opinion is clear from above, leave it to the BSMs, let the storage systems do what they are good at.
Only recently have other DBMS vendors added support for compression (2:1) and encryption but the implementations just add unnecessary administration. Also, imagine the scenario where the backup kernel does encryption as well as the underlying BSM, we now use double amount of CPU to do it, and encrypt same data twice is known to be a bad thing.
Best regards / Cordialement
Andreas Almroth
-----Original Message-----
From: Ingo.Struewing@stripped [mailto:Ingo.Struewing@stripped]
Sent: 15. oktober 2009 15:19
To: Andreas Almroth
Cc: Rafal.Somla@Sun.COM; backup@stripped; Lars Thalmann; Ingo Str HLS updated
Hi Andreas,
Andreas Almroth, 15.10.2009 12:32:
...
> This also leads me to think about earlier discussion regarding encryption. Would MySQL backup kernel want to keep a fully working Key Management System (KMS) in order to use right keys. KMS is a very complex system, managing many keys such as current, not-in-use, expired, deleted etc. I again think it would be better to leave it to the BSM to implement encryption and KMS. If we look at NetBackup it supports compression, encryption on client side, but also de-duplication when going to OST storage. NetBackup also support KMS and AES256 encryption when storing on supported tape drives (LTO4 and Sun StorageTek T10000).
If these things are provided by the back ends and we just need to turn
them on and off, then it is fine. My idea concerning this is to request
specific algorithms through the "location string".
OTOH, if compression and/or encryption is to be implemented, then it's
better to do it in the backup core so that all storage modules can
profit from them.
BTW, I'm still working on my own comments on the HLS. Please stay tuned.
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
