Product Documentation

Knowledgebase

Previous Topic

Next Topic

FairCom DB Files to Include for a Successful Backup Strategy

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:

  • FAIRCOM.FCS
  • ctdbdict.fsd
  • *.dat in the ctreeSQL.dbs folder
  • *.idx in the ctreeSQL.dbs folder
  • ctreeSQL.fdd in ctreeSQL.dbs\SQL_SYS

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):

  • FAIRCOM.FCS
  • SYSLOG*.FCS
  • SEQUENCE*.FCS
  • DFRKSTATE*.FCS
  • ctdbdict.fsd
  • *.dbs\SQL_SYS\*.fdd
  • RSTPNT*.FCS
  • REPLSTATE*.FCS (created on the target server by the Replication Agent)

Testing the Backup

The following test should demonstrate that you have backed up everything you need:

  1. Use the dynamic dump utility, ctdump, to back up your files into SYSTEM.BAK.

    The !FILES section of your dynamic dump script should include the entries shown earlier.

  2. Shut down your FairCom Server and rename your C:\<faircom>\server\data folder to a new (unused) folder name, such as data.old:

    C:\<faircom>\server\data.old

  3. Create a new data folder and copy the following files to this location:

    ctrdmp.exe

    SYSTEM.BAK

    Your backup script (the text file that contains the !FILES section shown above)

  4. Run ctrdmp to restore your files in place.
  5. Now start your FairCom Server and connect using FairCom DB Explorer. You should be able to see your restored SQL tables.

Previous Topic

Next Topic

Automatic Recovery

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.

Previous Topic

Next Topic

Restrict Access to FairCom DB Server Files

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.

Previous Topic

Next Topic

External Third-Party Utilities

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.

TOCIndex