2. The AccuRev Repository : Backing Up the Repository

Backing Up the Repository
You can use the procedures described in this section to back up both master and replica servers. Indeed, AccuRev recommends that you back up the replica servers in your environment on the same schedule you use for backing up your master. If you are backing up a replica server, be sure to also read Backing up a Replica Server.
Backing up the repository is a two-step process:
First, you use the accurev backup command to make a copy of the AccuRev metadata.
During backup command execution, clients can continue to work. Only transactions that are complete at the time the backup command is invoked are included in the metadata backup. The backup may take a few seconds or a few minutes, depending on the amount of metadata on your system.
Next, you use a backup/restore tool to make a complete copy of the file storage area (the storage directory tree), without worrying about synchronization or time-skew. When you back up file storage, you can either stop the AccuRev Server or use a backup/restore tool that supports a live-backup scheme. See Before You Begin for more information.
CAUTION: Do not execute the backup command while you are copying the file storage area. This can place incorrect data into the backup copy of the repository.
With the metadata backup and the copy of the file storage area, you can restore the repository to its state at the time you executed the backup command.
Before You Begin
Unless you plan to stop the AccuRev Server prior to backing up your file storage area, your backup/restore tool must be able to copy files that are currently “open” at the operating system level (that is, files that are in use by the AccuRev Server process). Your backup/restore tool should also have the ability to:
If you have any questions, contact Micro Focus technical support.
Backup Procedure
accurev backup <backup-file-name>
By default, the backup is stored in the storage\site_slice\backup directory.
For more information on the backup command, refer to the CLI documentation.
Use your backup/restore tool to create a backup copy of the entire directory tree below the storage directory, except for the db directory. This backup can be all-at-once or piecemeal; for example, you can back up the site_slice directory and the subdirectories within the depots directory separately.
Note: If your site slice is in a non-standard location (as specified by the SITE_SLICE_LOC setting — see Server Configuration File), or if some depots are in non-standard locations (perhaps moved with the chslice command), then your job in backing up the entire repository is more complicated than simply to copy the storage directory.
Backing up a Replica Server
As mentioned previously, you can use the procedure described in Backing Up the Repository to back up both master and replica servers. If you are backing up a replica server, note the following additional considerations:
On each replica server, make a copy of the acserver.cnf from the bin directory and save it with the backed-up data.
Out of Shared Memory Error
If you have a large number of depots, you may encounter error messages similar to the following:
pg_dump: WARNING: out of shared memory
pg_dump: attempt to lock table <table name> failed: ERROR: out of
shared memory
HINT: You may need to increase max_locks_per_transaction.
You can address this issue in the following ways:
To increase "max_shared_locks_per_transaction", edit the value of this variable in postgresql.conf using the following formula:
20 x (number_of_depots + 1) / max_connections
NOTE: Supporting the backup of more than 1,000 depots may also require that you increase the value of SHMMAX to more than 32MB.

Micro Focus