Automated (scheduled) backups can not reliably backup files stored in encrypted volumes created and managed by the CyberAngel/TrueCrypt encryption products. Such files must be backed up and restored manually in order to ensure consistent data upon restore. To do so:

• the CyberAngel/TrueCrypt application must be running
• the encrypted volume(s) must be mounted
• the TSM client must be accessible to the end user
• the user must know how to initiate a backup (this can be down via a script presented to the user as an icon)

This special handling is the result of the methodology of these products. The encrypted volume presented to the user by these products is not a separate disk, or disk partition, but rather a large file (a canister in CyberAngel documentation, a container in TrueCrypt documentation) within a Windows filesystem. The contents of this large file are managed by the products; as such, files in the encrypted volume are not directly visible to the TSM client unless the encrypted volume is mounted when the TSM client is running. This generally requires the user’s presence, for at a minimum, a password must be entered when the encrypted volume is mounted. (We have investigated, in conjunction with the university ITSO, whether such a mount can be done via script, and thus be mounted by the TSM client during a backup, but neither product supports such an action at this time). Hence, the requirement of a manual backup. One positive consequence of this: files on encrypted volumes are managed (i.e., have the same retention policies) by the TSM client and server in the same manner as files on unencrypted volumes.

In addition to the manual backup, the following are recommended:

• The file(s) stored in an encrypted volume should be encrypted by the TSM client.
• The file that constitutes the encrypted volume should be excluded from the nightly backup.

The first recommendation is relatively straightforward: if a file needs to be stored in an encrypted volume, then that file should be encrypted for transmission to the TSM server. While there are several means of achieving this, using the TSM client encryption feature ensures that the file is also encrypted within the TSM Server storage as well.

The reasons for the second recommendation are more complex, in part because the two products do differ slightly in the way they manage the large file behind the encrypted volume when its contents are updated (for example, when a file is created/modified/deleted on the encrypted volume). Regardless of product, backing up the large file will consume a considerable amount TSM storage space (undoubtedly more than the sum of the files therein), inflating EZ-Backup storage charges. Beyond that, there are retention considerations, which differ by product:

• TrueCrypt container: As the file metadata of the large file doesn’t change when the contents change, the TSM client cannot detect when the contents of the file changes. Thus, the large file would be backed up once, the first night the TSM client detected its presence. Any subsequent restore attempt would return the container file, and hence its contents, to that of the first night, losing all subsequent changes (file creation/modification/deletion within the encrypted volume) made by the user after that first backup;
• CyberAngel canister: As the file metadata of the large file does change when the contents change, the TSM client could detect that the contents of the file had changed, and back it up when it did so—if the canister is not mounted by the user when the backup occurs (the CyberAngel product puts an exclusive lock on the large file/canister when it is mounted, so the TSM client wouldn’t be able to read the large file). Even if the large file could be backed up consistently, though, doing so results in retention policy being applied to the container, and not to the files within the associated encrypted volume. As such, users would not have the same experience with file versions for files on the encrypted volume. And restoring the large file results in ALL of the files in the associated encrypted volume being restored - potentially resulting in the loss of user work.