|
|
|
A FairCom DB SQL dictionary is composed of several files. You will need to back up all of these files if you want to be able to restore the entire SQL dictionary from your backup. By backing up the correct set of files, you will be able to do a full restore and have your SQL dictionary ready-to-go.
The following files need to be backed up if you want to be able to restore the entire SQL dictionary:
The !FILES section of your dynamic dump script will look like this:
!FILES
FAIRCOM.FCS
ctdbdict.fsd
ctreeSQL.dbs\*.dat
ctreeSQL.dbs\*.idx
ctreeSQL.dbs\SQL_SYS\ctreeSQL.fdd
!END
More generally, the following files are FairCom internal files that need to be included in backups to allow recovery to function without SKIP_MISSING_FILES YES (in the event these files are changed during the backup interval):
Testing the Backup
The following test should demonstrate that you have backed up everything you need:
The !FILES section of your dynamic dump script should include the entries shown earlier.
C:\<faircom>\server\data.old
ctrdmp.exe
SYSTEM.BAK
Your backup script (the text file that contains the !FILES section shown above)
|
|
|
Never interrupt the FairCom DB process during automatic recovery. Data and indexes will be left in an unknown state, resulting in probable data loss. This situation may require restoring data from a clean backup to ensure absolute data integrity.
File ID Overflow during Recovery
When a transaction controlled file is opened by the server, it is assigned a unique fileid which is used to reference it in the transaction logs. This number is stored as a 4-byte integer. If large numbers of files are opened and closed repeatedly, available file numbers can be rapidly consumed, causing a "Pending File ID overflow" message to be logged. This message is logged once every 10,000 file opens. The fileid can be reset by shutting down the server cleanly (so no recovery is needed), and removing existing transaction logs (L*.FCS and S000*.FCS).
An FUSE_ERR error (22) during recovery indicates that the FILES setting should be increased to complete recovery. A RECOVER_FILES keyword (NO by default) is also available that controls this specifically.
RECOVER_FILES <number of files | NO>
Note: Recent improvements to only assign the fileid when a file is actually updated, and not just opened and read from, can substantially reduce the file numbers consumed.
|
|
|
The FairCom DB Server engine requires exclusive access to the files under its control. Therefore do not attempt to copy, delete or in any way replace a file being controlled by the FairCom DB Server engine while the Server is running. This can lead to data corruption and Server instability.
|
|
|
FairCom DB server technology requires that it is the only process operating over any data and index files under its control. Third-party backup (and some virus scan) utilities should never touch any files while FairCom DB has the files open. Doing so on the transaction logs or on a transaction controlled file may terminate the server process. When FairCom DB encounters a write error on these types of files it can no longer guarantee integrity or recovery and must terminate to protect the state of the current system.
If a third-party backup is desired, either use the FairCom DB Dynamic Dump backup facility to create a copy of the files and point the third-party backup to the resulting backup file, or shut down FairCom DB. and then perform the backup.
It is also possible to use a disk-level copy as an acceptable backup strategy, provided FairCom DB is put into a quiet state (using either “Quiesce” or File Block) before the hardware-level copy.
FairCom DB V9.2 and later for Windows also includes Windows VSS support (Volume Shadow Service) for enhanced integration with third-party backup tools.
