Recovering a Failed or Incomplete dataxform Session
A dataxform session can fail for different reasons: dataxform can be canceled, the process is killed, the system crashes, and so on. The recovery process is similar for manual and automatic dataxform.
For more information, see:
Restarting an Incomplete Automatic dataxform Session
Although unlikely, if an automatic dataxform session fails to complete, your intervention may be required to allow it to resume.
In the case of a system restart--for example after a power failure--the automatic session will be resumed when the GuardPoint is mounted during the boot sequence. However, if the dataxform session terminated unexpectedly (for example, if the session had been killed), then the system will not restart it automatically, and the GuardPoint status needs to be reset so that another automatic session will be initiated.
The following steps reset the GuardPoint status:
-
Verify that the session really has terminated unexpectedly by verifying that no existing dataxform process is running. Use the standard system tools (
psor task manager). -
From your key manager, disable the GuardPoint, then wait until the GuardPoint status on the CTE Agent no longer lists the GuardPoint.
-
From your key manager enable the GuardPoint.
An automatic dataxform session will start soon after this, and the session will continue from where it previously stopped.
Recovering from a Failed dataxform Session
The following is an example of how to recover from a failed dataxform session. The GuardPoint in this example is /opt/apps/dx9.
-
A manual dataxform session is run, then canceled using Ctrl-c:
Response
The
dataxform_status-_opt_apps_dx9,dataxform_status_error-_opt_apps_dx9, anddataxform_dir_list-_opt_apps_dx9files are created in the log directory, or the GuardPoint, depending on the command line options. By default, all status and log files go to/var/log/vormetric. If--status_gpwas included on the command line, the status files go in the GuardPoint.The dataxform session log file,
/var/log/vormetric/vordxf-_opt_apps_dx9_root.log, is updated. It displays the same basic information as displayed on the terminal screen. -
The dataxform messages indicate that the session had been interrupted and that a number of files (6) are in an unknown state due to the interruption.
-
You may optionally use the
--recoveryoption to generate a set of files that track the progress dataxform made in the GuardPoint (see later). However this step is not required and can be deferred until after a new dataxform session has been run to transform the remaining files. -
Resume the data transformation run, using the same command as you used to start it before.
Response
-
If for some reason this session also did not complete, performing the same operation again should continue from where the previous session ended. The status records are accumulated across each session.
Warning
Do not run the
--recoveryoption more than once, as a second run may overwrite vital information required to recover any files that did not transform correctly. -
Use the
--recoveryoption to generate a set of files that track the progress dataxform made in the GuardPoint.Response
-
Use those files later to determine which files in the GuardPoint have not been transformed.
Response
-
The
/var/log/vormetric/vordxf-_opt_apps_dx9_root.logfile is updated. It displays the same basic information displayed on the terminal screen. -
The primary files of interest are
dataxform_files_todo-_opt_apps_dx9,dataxform_files_done-_opt_apps_dx9, anddataxform_status_error-_opt_apps_dx9.dataxform_files_done-_opt_apps_dx9lists the files that dataxform rekeyed successfully. Leave these files alone.
Note
If more than one session restart was required to complete the dataxform run, there may be repeated entries in the above list.
dataxform_status_error-_opt_apps_dx9lists the files that were being processed at the time an error occurred—for example, when dataxform was interrupted in the above example. These are the files that have to be checked individually to determine if they had been processed. They may or may not have been completely processed.
Response
dataxform_files_todo-_opt_apps_dx9lists the files that dataxform had not touched and are yet to be transformed, and any files for which a transform was attempted but for some reason failed.
Response
Response
-
Unguard the GuardPoint with the rekey policy through your key manager. Do not re-apply the regular policy because you are not able to use the in the GuardPoint. A proper rekey policy restricts access to all the files in the GuardPoint. You have to disable the rekey policy so you can access all the files in the GuardPoint and determine their transformation status.
-
At this point, you should restore the files that were named in the error listing above from a backup, and run a transformation session for just these files, using the "todo" list (
dataxform_files_todo-_opt_apps_dx9) to select which files are to be transformed. However, depending on the exact nature of the error reported, some entries may need to be removed from the "todo" list, for example, if somehow a file no longer exists, then attempting to transform it again will obviously not work. -
If you are running automatic dataxform, remove the
dataxform_auto_conffile from the GuardPoint. -
Re-apply the rekey policy to the GuardPoint, but first be sure that your current directory is not the GuardPoint.
-
Verify that the policy has been successfully re-applied.
Response
-
Run dataxform on just the files in the todo list. For example:
Response
In this case the dataxform completes successfully. The error file was removed because no errors were encountered in the rekey process.
-
Unguard the rekey policy.
-
If you are satisfied with the successful completion, clean up the files left by the rekey process.
-
Apply a regular policy that uses the applied key.
-
Check that the access controls and encryption keys configured in the policy are working as expected.
Avoiding Double Encryption
Scenarios can occasionally occur that can lead to double-encryption. This can be caused by various different issues such as:
-
Attempts to run Data Transformation twice on the same content, using the same policy, so on the second transformation it attempted to encrypt the file with the target key, not the source key
-
Bad restore attempt
-
Files incorrectly copied into a GuardPoint
-
Procedural problem with encrypting the GuardPoint
-
The file is unencrypted, or encrypted without a header, and the policy assumes that the file must be encrypted with a header
-
The file is corrupted, in which case you need to recover the file from a backup method
-
The wrong transform policy was used, so you need to change the policy
CipherTrust Transparent Encryption UserSpace has added two error messages to help avoid the double-encryption scenario. They are:
-
Invalid header
-
Wrong key
Invalid Header
If Data Transformation is converting from an encrypted state and its header has been corrupted, the following message displays as the file is being processed:
At the end of the dataxform run, it will display another message for each file skipped, and a count of the number of files skipped:
Encrypted with Incorrect Key
If converting from an encrypted state and the encryption key of a file does not match the initial key in the transform rule, the following message displays as the file is being processed:
At the end of the dataxform run, it displays another message for each file skipped, and a count of the number of files skipped:
