Custom key storage relies on 3d-party enterprise software for how the encrypted, external key "blobs" (binary objects) are stored, and how their life-cycle is managed. How a custom key storage methodology should be backed up/restored depends on the media or methods provided by the enterprise software, or by a 3d party.
For example, an enterprise application with millions of keys and certificates may decide to store them as B*OBs ("binary <size> objects") in an RDBMS table row. In this case, the RDBMS management methods should provide the ability to replicate, backup and restore the database, even in real-time.
If using custom keystores, the keys must be created as "external" (CXI_KEY_FLAG_EXTERNAL) keys.
The scripts below are broken down into multiple lines in order to improve readability. Where a command is meant to be typed as a single line, a trailing \ character is used to indicate that the line following is meant to be typed on the current line. Not all shells understand the \[newline] syntax to indicate 'next line continues here'.
csadm \
Dev=288@10.19.29.200 \
LogonSign=bobo,:cs2:cjo:USB0 \
GetState
is equivalent to, and should be typed as:
csadm Dev=288@10.19.29.200 LogonSign=bobo,:cs2:cjo:USB0 GetState
where 'next line continues here' is not supported.