...
Refreshes are performed at the start of each month (following a successful month end process). The above form is an example of a recent request to refresh all of the non-prod environments.
...
Unique environment:
DR Environment
This environment is a "dual purpose" environment. It is used as an isolated test environment on an as-needed basis but additionally, DR is utilized to perform quarterly testing of the DR "fall back" process. When used for DR testing, it is maintained as a production-like environment, which includes a full copy of the production database including the document attachments. In addition, the data is maintained in it's productive state which includes production key encryption of the sensitive data. This data is also real (no falsified). Access to the DR environment (when in true DR mode) is controlled by role assignment in KFS (KIM). This provides a fully functional prod-like environment enabling full business process testing by authorized users, while protesting the sensitive data contained within.
Typical Issues and remediation
DR Environment & prod encryption key
When DR is used for true DR testing, the encryption key is the one from production. If a refresh is requested for this environment with the production key and production java object in place, the result will be a successful refresh but an unusable environment. The reason for this is that part of the cleansing process involves copying the java object from the database before the data is overwritten and then restoring the "saved" object after. This is done to ensure that the resulting object is the test object that was in place prior to the refresh as opposed to the prod object from the production export.
Remediation
Immediately following completion of a DR event:
- the java object in the DR schemas must be replaced with the test version of java object. (Dave Raines)
- the encryption key in the security file on the application servers is replaced with the test key. (Ben Daniels)