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.

Overview

Backing up the repository is a two-step process:

1.	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.

2.

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

•	Read the section titled A Word of Caution on Windows Zip Utilities.

•	Obtain a backup/restore tool if you don’t already have one.

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:

•	Preserve file timestamps.

•	Preserve file ownership and execute permissions.

•	Back up zero-length files. See Server-Control Files for more information.

•	Order matters. If you are using AccuRev’s repository replication feature, AccuRev recommends that you back up the replica server first. See Backing up a Replica Server for more information.

If you have any questions, contact Micro Focus technical support.

Backup Procedure

1.	Back up the AccuRev metadata:

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.

2.	If your backup/restore tool cannot copy files that are currently open at the operating system level, stop the AccuRev Server. (See Controlling Server Operation.)

3.

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.

4.	If you have scripts or triggers that are crucial to your usage of AccuRev, back up those as well.

5.	If you stopped the AccuRev Server in Step 2, start it again. (See Controlling Server Operation.)

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:

•	Back up all replica servers; order is not important.

•	Replica servers can be backed up before or after the master server is backed up. (When each replica server is restored later via the accurev replica sync command, it will be brought back in sync with the master server.)

•

Try to minimize the amount of time between backing up the master server and backing up the replica server. A one-hour difference is a good interval, though you might want to adjust that over time. Keeping the time interval as small as possible reduces the amount of content that will be required to update the replica servers after you restore the master server.

•	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:

•	perform a more selective backup using "-p" to back up only some depots

•	increase "max_shared_locks_per_transaction" as suggested by the error message

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.