A unique feature of the Commvault® software is the ability to encrypt deduplicated data. The software accomplishes this by encrypting the data after the hash signature has been generated. The full process, including compression is:
- Object level backups – Compress, Hash, Encrypt
- Database backups – Hash, Compress, Encrypt
Traditional methods of deduplicating encrypted data is to hash the encrypted data. Every time the block is encrypted a different hash is generated. As a result, it is not possible to achieve efficient deduplication ratios using this method. Since Commvault software hashes the block prior to encryption, the hash is always consistent even if the encryption key changes resulting in efficient deduplication ratios.
Deduplicated data encryption
Mixing Encrypted and non-Encrypted Data
It is possible, when writing deduplicated data to storage, that one client can have encryption enabled where on another client it is disabled. If both clients are writing data to the same deduplication store, it would result in a mix of encrypted and unencrypted blocks within the store. If some clients require encryption whereas others do not, separate the clients into separate deduplication policies for best security.
Encryption Key Management and Destruction using Deduplication
Commvault® software writes deduplicated jobs to disk by splitting the job into data chunks and metadata chunks. Both chunk types are encrypted. Data chunks can be associated with multiple jobs if other jobs are referencing blocks within the chunk. Metadata chunks are only associated with a specific job.
When a data aging job runs, metadata chunks for jobs exceeding retention are deleted from the CommServe® database. Although the data chunk can still exist in the disk library, without the metadata chunks, no data for the aged job can be recovered. Any blocks within the data chunk that are not being referenced by any other jobs are deleted from the library using a process called 'drill holes.' If no jobs are referencing blocks from the data chunk, the chunk is deleted from the disk and relevant encryption key are deleted from the CommServe database. Splitting deduplicated data into data and metadata chunks prevents the recovery of aged job jobs while allowing encrypted data in the data chunk to be recovered when other jobs are referencing blocks within the chunk.
Encrypting SILO data to tape
Since the SILO exists as a backup set and subclient, 'inline encryption' options are configured to perform encryption as the SILO job runs. The encryption settings are configured in the same way an ordinary subclient encryption is configured.
Hardware encryption is also used for LTO4, 5, 6, and 7 drives that support encryption. Enabling hardware encryption is configured in the SILO data path properties in the storage policy Copy.