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
database, on the other hand, are not guaranteed to be in a state of
transactional integrity if archived by a conventional backup program.
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
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.
Checkpoints and journals archive only the Helix server database files, not the versioned files stored in the depot directories!
You must always back up the depot files (your versioned file tree) with the standard OS backup commands after checkpointing.
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.