Backup and recovery concepts

Disk space shortages, hardware failures, and system crashes can corrupt any Helix Server files. That’s why the entire Helix Server root directory structure (your versioned files and your database) must be backed up regularly.

The versioned files are stored in subdirectories beneath your Helix Server root and can be restored directly from backups without any loss of integrity.

The files that constitute the Helix Server database, on the other hand, are not guaranteed to be in a state of transactional integrity if archived by a conventional backup program. Restoring the db.* files from regular system backups can result in an inconsistent database. The only way to guarantee the integrity of the database after it’s been damaged is to reconstruct the db.* files from Helix Server checkpoint and journal files:

• A checkpoint is a snapshot or copy of the database at a particular moment in time.
• A journal is a log of updates to the database since the last snapshot was taken.

The checkpoint file is often much smaller than the original database, and it can be made smaller still by compressing it. The journal file, on the other hand, can grow quite large. It is truncated whenever a checkpoint is made, and the older journal is renamed. The older journal files can then be backed up offline, freeing up more space locally.

Both the checkpoint and journal are text files, and have the same format. A checkpoint and (if available) its subsequent journal can restore the Helix Server database.

Because the information stored in the Helix Server database is as irreplaceable as your versioned files, checkpointing and journaling are an integral part of administering Helix Server, and must be part of your regular backup cycle.