Backup and recovery concepts

Disk space shortages, hardware failures, and system crashes might corrupt Helix Server files.

Versioned files	Checkpoints and journals	Database
Versioned files Source files stored in the Helix Server depot, including one or more revisions to each file. Also known as archive files, archives, and depot files. Versioned files typically use the naming convention 'filename,v' or '1.changelist.gz'. are stored in the depot A file repository hosted on the Helix Core Server. A depot is the top-level unit of storage for versioned files, which are also known as depot files, archive files, or source files. It contains all versions of all files ever submitted to the depot, including deleted files (but not obliterated files). There can be multiple depots on a single installation. and contain the content of file revisions submitted by users.	The checkpoint A backup copy of the underlying metadata at a particular moment in time. A checkpoint can recreate db.user, db.protect, and other db.* files. See also metadata. and journal A file containing a record of every change made to the Helix Server’s metadata since the time of the last checkpoint. This file grows as each Helix Server transaction is logged. The file should be automatically truncated and renamed into a numbered journal when a checkpoint is taken. are text files in the same format. A checkpoint is a copy of the database at a particular time. The checkpoint file is often much smaller than the database, and it can be made smaller still by compressing it. A journal is a log of updates to the database since the last checkpoint. The journal file can grow quite large. It is truncated when a checkpoint is made, and the older journal is renamed. Old journal files can be backed up offline to free space locally. Checkpoints and journals archive only the Helix Server database files, not the versioned files stored in the depot directories.	The database The database in the P4ROOT directory contains db.* files with metadata that the Helix Core Server uses to operate on versioned files, users, protections, streams, changelists, and more. in the P4ROOT directory contains db.* files. The only way to guarantee the integrity of the database if you need to reconstruct it is by using checkpoint and journal files. A checkpoint and (if available) its subsequent journals can restore the database.
On a regular schedule, make backups of the versioned files, checkpoints, and truncated (numbered) journals. Always back up the versioned files with the standard operating system backup commands after checkpointing. It is good practice to keep one month of checkpoint and journal files available.		Do NOT use your operating system backup utilities to back up the db.* files because such utilities often lock files and interfere with Helix Server operations and performance.

Anti-virus software

We understand and respect that each organization has its own requirements and policies about anti-virus software.

Consider whether your organization might prefer to use anti-virus software on client machines rather than on the server machine running Helix Core Server. Anti-virus software might:

• lock metadata files and thereby interfere with normal Helix Server operation

• degrade server performance by competing for system resources.

If your organization determines that anti-virus software must be used on the server machine running Helix Core Server, consider whether it is feasible to exclude the scanning of db.* metadata files and live scan operations.