Backup and recovery concepts

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

Versioned files	Checkpoints and journals	Database
Versioned files Source files stored in the 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. Except for obliterated files, any version of any file can be restored, including deleted files, but not obliterated files. An installation can have multiple depots, and they might be of different types, such as a local depot and a stream depot. and contain the content of file revisions submitted by users. The P4ROOT environment variable represents the root directory of Helix Core Server installation. Each depot is a subdirectory under the P4ROOT directory. By default, the versioned files for a given depot are located in a tree of directories beneath this subdirectory. For an alternative location, see The server.depot.root configurable section of Set a depot location.	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 metadata since the time of the last checkpoint. This file grows as each transaction is logged. 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 Core 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 Core 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 Core 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.