208 Implementing IBM Tape in i5/OS
7.2.3 Disaster recovery considerations
The main reason to have more than one EKM server is that, if this single EKM server fails,
there is no possibility to read from or write to encrypted tapes before having recovered the
failed EKM server.
Another reason for setting up a secondary EKM server is that an EKM server, which was
started in a batch job currently, cannot be dynamically reconfigured using the EKM admin
console. Figure 7-5 shows a redundant setup with two EKM servers. If one EKM server fails,
the IBM tape library that has been configured with two redundant EKM paths (EKM server
TCP/IP addresses) automatically attempts to failover to the second EKM server for retrieving
the data keys required for encryption and decryption of the tape cartridges. With two
redundant EKM servers, it is required that their keystore, configuration file, and drive table are
synchronized. You can define parameters in the EKM configuration to have this done
automatically at regular intervals.
Figure 7-5 Redundant EKM server configuration using two different systems
For further details on setting up a secondary EKM server and synchronizing EKM servers,
refer to “New installation of a secondary EKM server” on page 215.
Note: For availability reasons, we recommend that you set up two redundant EKM servers
on different host systems, ideally at different locations.
Important: Taking regular unencrypted backups of the EKM keystore *.KDB file,
drivetable, and configuration file KeyManagerConfig.properties, for example, via prior FTP
transfer to another system, is crucial for restoring a working EKM server configuration after
a disaster before being able to regain access to the encrypted tape data.
EKM Path 2
EKM Path 1
running EKM Server 1
running EKM Server 2
IBM Tape Library
with encryption-enabled tape
System i5 Server 2System i5 Server 1