|
|
|
Used to restore backups created with ctdump.
Operational Model:
Standalone
Usage:
ctrdmp [ dumpscript ] [ -x ]
A successful ctrdmp completion always writes the following message to CTSTATUS.FCS:
DR: Successful Dump Restore Termination
A failed ctrdmp writes the following message to CTSTATUS.FCS when ctrdmp terminates normally:
DR: Dump Restore Error Termination...: <cterr>
where <cterr> is the error code.
When the -x option is specified, the !DUMP keyword in the dump script is ignored and the dump stream is read from standard input.
This might be combined with the ctdump output redirection to pipeline a backup and restore operation:
ctdump -s FAIRCOMS -u admin -p ADMIN -t test6.dmp -c -x| ctrdmp test6.dmp -x
Note: If an error occurs during the restore phase, no backup exists on disk.
If encrypted files are being restored and input redirection is used, ctrdmp is not able to prompt for the master password during the recovery phase of the restore. In this case, an alternate means of providing the master password is required, such as using the CTREE_MASTER_KEY_FILE environment variable.
If for some reason ctrdmp terminates prematurely (for example, a fatal error causes ctrdmp to terminate abnormally), the “Dump Restore Error Termination...” message might not be written to CTSTATUS.FCS. In that case, ctrdmp might have written error messages to standard output or to CTSTATUS.FCS before terminating that helps explain the reason for ctrdmp terminating prematurely.
Note: A 32-bit ctrdmp could fail with error 75 if run on transaction logs created by a 64-bit FairCom Server, which might support more than 2048 connections.
The ctfdmp, ctldmp, and ctrdmp utilities display the FairCom DB version used to compile them when they are run.
Dump and Restore Version Compatibility
The ctrdmp (ctrdmp - Backup Restore or System Rollback, Backup Restore Utility) utility is used to restore a Dynamic Dump and the ctfdmp utility can be used to roll forward. Occasionally an update to the FairCom Database Engine may cause an incompatibility between versions. For this reason you must use the ctrdmp from the same release from which the dump was created. It is important to save a copy of the ctrdmp utility that is compatible with each dump file.
Restore Recovery Options
The ctrdmp utility now supports the RECOVER_DETAILS and RECOVER_MEMLOG transaction recovery options (the same options that FairCom Server supports).
If you specify !RECOVER_DETAILS YES in your dump restore script, ctrdmp will log progress messages to the file CTSTATUS.FCS as it performs its automatic recovery.
Environment Variable for Advanced Encryption Password
If this utility has advanced encryption enabled, it can read an encrypted password file instead of being prompted to enter the master password. To enable this, set the environment variable CTREE_MASTER_KEY_FILE to the name of the encrypted master password file.
ctrdmp supports options to help analyze recovery behavior. The following options behave like their corresponding server configuration options:
See also
|
|
|
In V11 and later, ctrdmp is able to rollback to a Restore Point. Restore Points permit server clients to establish quiet spots in the transaction log where there are no active transactions.
Prior to the V11 modifications, ctrdmp could either perform a dynamic dump recovery or rollback to a specified date and time. ctrdmp has been extended such that, as an alternative to specifying a date and time, the rollback script can provide the name of a Restore Point file.
A typical ctrdmp script file used for a rollback looks like:
!ROLLBACK
!DATE MM/DD/YYYY
!TIME HH:MM:SS
....
Now the script can be composed as follows:
!RP <Restore Point File Name>
....
The Restore Point File Name generated by the server is either of the following:
Note that, as with the !ROLLBACK script keyword, the !RP keyword must be the first entry in the script file.
See also
|
|
|
The dynamic dump restore utility, ctrdmp, supports options for converting path separators to the operating system's native path separator. These options are useful when restoring a dynamic dump that was created on an operating system that uses a different path separator. For example, using ctrdmp on a Linux system to restore a dynamic dump that was created on a Windows system.
!CONVERT_PATHSEP
The dynamic dump restore script option !CONVERT_PATHSEP instructs ctrdmp to convert path separators to the native path separator. ctrdmp applies this conversion to:
Note: If the file name begins with a drive letter (for example, C:) or a UNC reference (for example, \\machinename\sharename), it is not changed. In these cases, we recommend using the !REDIRECT option in the dynamic dump restore script to replace these references with the desired target directory names.
The dynamic dump restore script option !REDIRECT_IFIL instructs ctrdmp to apply the !REDIRECT rules that are specified in the dump restore script to the data and index filenames in the IFIL resources of the data files restored by ctrdmp.
An alternative to the !REDIRECT_IFIL option is to run the ctredirect utility after ctrdmp completes.
Example
As an example, consider a backup made on a Windows system of the c-tree data and index files accounts.dat and accounts.idx that are stored in the directory E:\mydata. In this example, the data file name in the IFIL resource is E:\mydata\accounts.
Here is an example dynamic dump backup script:
!DUMP backup.fcd
!FILES
E:\mydata\accounts.*
!END
Below is an example dynamic dump restore script to run on a Unix system that uses a !REDIRECT option to redirect E:\mydata to myrestoredir, which is a subdirectory in the directory where ctrdmp is being run. it uses the !REDIRECT_IFIL option to update the IFIL resource in accounts.dat based on the redirect rule:
!DUMP backup.fcd
!REDIRECT E:\mydata myrestoredir
!REDIRECT_IFIL
!CONVERT_PATHSEP
!FILES
E:\mydata\accounts.*
!END
In this example, accounts.dat and accounts.idx are restored to the myrestoredir directory, and then the data file name E:\mydata\accounts in accounts.dat is changed to myrestoredir/accounts. If the !REDIRECT_IFIL option had not been used, only the path separators would have been changed, so the data file name in the IFIL resource would have been changed to E:/mydata/accounts.
Limitations: The byte ordering of the two systems must be the same so that ctrdmp can restore the dump.
