Virtual TapeServer 8.2 Configuration Guide
Table Of Contents
- Virtual TapeServer for NonStop Servers Configuration Guide
- Preface
- Introduction
- Overview of Tasks
- Reconfiguring Vaults
- Enabling Licensed Features
- Configuring Ports
- Creating and Managing VTLs and VTDs
- Enabling and Performing Tape-to-tape Exports
- Enabling and Performing Stacked Exports
- Enabling and Configuring Data Replication
- Enabling and Configuring Role Swapping
- Configuring EMS Communication
- Enabling and Configuring Data Encryption
- Creating and Managing Virtual Media
- Enabling and Configuring Scan/Cleanup
- Configuring User Accounts
- Configuring Web Interface Preferences
- Managing the VTS Server
- Troubleshooting
- Maintaining GFS for VTS
- Reinstalling and Restoring VTS
- Attaching External Devices after Initial Deployment
- TCP/IP Ports and Protocols
- Index
58 | Enabling and Configuring Data Encryption
key in the database ensures that the key will not be compromised and that it resides in a
central, secure location with all other keys.
The key database is backed up on the key server and on at least one other remote server to
ensure that a backup of the keys is always available in case the key server is damaged or
destroyed. The backup must complete successfully on the localhost and backup host before the
keys are available for use by VTS. This ensures that keys are backed up before data is
encrypted.
Encryption and decryption during virtual tape operations
A virtual tape can be encrypted in several ways:
• It can be encrypted when it is created.
• It can be manually encrypted after it is created.
• It can be automatically encrypted when it is added to a pool that is designated as
encrypted.
• It can be encrypted if the pool in which it resides is designated as encrypted.
Similarly, a virtual tape can be decrypted manually or when its pool is decrypted.
Data Encryption affects other tape operations as well:
• Mounting, reading, and writing to an encrypted virtual tape
When an encrypted tape is mounted, VTS retrieves the key ID from the tape and uses the
ID to request the key from the key server that generated it. The key is then used to
decrypt the data as it is read from the tape. (The data remains encrypted on the tape.)
Also, VTS cannot read or write to the tape without the key.
• Exporting a virtual tape (tape-to-tape export)
An encrypted virtual tape is exported as-is if SPHiNX is configured for encryption and the
tape is exported in virtual tape format. If you export a pool, the virtual tapes remain
intact and encrypted. If the physical drive supports encryption, an unencrypted virtual
tape can be encrypted by the drive.
• Migrating a virtual tape (stacked export)
An encrypted virtual tape is migrated as-is; that is, the data remains encrypted when it is
migrated to physical tape.
• Compressing data
If enabled, data compression occurs before encryption.
• Updating metadata, timestamps, and file sizes
Every virtual tape stores header information called metadata, which is used by VTS to
retain an audit trail of information about the tape. When a tape is encrypted, the
metadata is not encrypted. The following timestamps are associated with virtual tapes:
modify, access, and change. The modify timestamp is not updated when a tape is
encrypted or decrypted. However, the access and change timestamps are updated when a
tape is encrypted or decrypted.
Finally, when a virtual tape is encrypted, its file size changes because the key ID and
other encryption metadata is added to the virtual tape.
The SecureVTS.log file, which resides in /usr/local/tape/log/, stores an audit trail of all
encryption operations.