Backup and Restore

This appendix describes the commands and processes you can use to back up and restore GitCentric.

GitCentric provides two sets of commands for backing up and restoring GitCentric, summarized in the following table:

Table 1. Summary of Backup and Restore Commands
Command	Description	When to Use
full_backup.sh full_restore.sh	The full_backup.sh command backs up the GitCentric databases, your Git repositories, and your configuration files. Likewise, full_restore.sh copies all required files to the new location.	Use full_backup.sh and full_restore.sh any time you wish to completely back up GitCentric. You should also use these commands when migrating GitCentric from one server to another.
backupdbs restoredbs	The low-level backupdbs and restoredbs commands, as the names imply, back up and restore only the GitCentric databases. Other important data, like your Git repositories and configuration files are not backed up by the backupdbs command. backupdbs and restoredbs are kandoMaintain commands. See Appendix A: The kandoMaintain Utility for more information.	You might wish to use these commands if your current backup strategy includes a third-party tool for backing up your repositories. Note: If you are currently using backupdbs and restoredbs to back up GitCentric, you can continue to do so.

Micro Focus recommends that you use the full_backup.sh and full_restore.sh commands to back up and restore GitCentric as described in the remainder of this appendix.

Micro Focus recommends that you back up GitCentric on a daily basis -- every night, for example. You can back up GitCentric at any time, but Micro Focus recommends that you choose a time of light system usage.

Tip: Consider creating a cron job for GitCentric backups. For examples of cron jobs, see Set Up Gerrit Garbage Collection on page 55.

This section describes the background information and procedures you use to back up GitCentric.

The full_backup.sh command backs up:

All files are backed up to a .tar file that is created at the location from which you run the full_backup.sh command. The file is named kando_backup_site_etc_<yyyymmdd>.tar, where <yyyymmdd> is the year, month, and day.

You can move the backup file to -- and restore it from -- a different location if you choose.

The GitCentric databases, "kando" and "gcreviewdb", are PostgreSQL databases installed on the GitCentric server. These databases contain all AccuRev stream-Git branch mappings, as well as a history of all import and export activity. Stream-branch mappings are recorded using AccuRev transaction-Git commit pairs. For more information on the GitCentric databases, see Basic Architecture on page 3.

This section describes the background information and procedure you use to restore GitCentric.

The full_restore.sh command completely overwrites an existing GitCentric installation. If you are restoring to an existing GitCentric installation, make sure there is no data under the GitCentric home directory that needs to be saved.

In order to successfully run the full_restore.sh command:

The full_restore.sh command restores all the files and databases in the kando_backup_site_etc_<yyyymmdd>.tar created by the full_backup.sh command. See What Gets Backed Up? on page 84 for more information.

To restore GitCentric:

If your GitCentric restore was successful, you might need to perform one or more of the following tasks depending on whether or not you restored GitCentric to a new location or to a new machine. In addition, you might need to merge Gerrit configuration files.

If you restored GitCentric to a new location on the existing machine, you need to:

If you restored GitCentric to a new machine, as you might in a migration scenario, for example, you need to:

If you restored to the same location, simply unpack the kando_backup_site_etc_<yyyymmdd>.tar file by running:

In typical usage, GitCentric displays a message like the following for each Git branch that is successfully restored:

When the restore is successful, no action is required on the part of the GitCentric administrator. The remainder of this section describes other scenarios that require the attention of the GitCentric administrator.

An overflow condition occurs when the GitCentric database is backed up before the Git repositories are copied. In this event, it is possible that the GitCentric database and the Git repository copies are out of synch -- specifically, the GitCentric database probably does not have a complete set of AccuRev transaction-Git commit pairs reflecting the latest commits in the Git repositories.

When this happens, the GitCentric restore:

In the case of an overflow condition, it is up to the GitCentric administrator to determine whether or not these changes need to be merged into the original branch and pushed to the Git repository. If the changes represented by the unrecorded commits are already in AccuRev, GitCentric will automatically export them to the restored repository after you start the GitCentric server. If the missing changes are not in AccuRev, the user can clone, then fast forward-only merge from the overflow branch to the named branch, and push.

A rollback condition can occur when there is a large interval of time between when the copy of the Git repositories was created and the GitCentric database backup was performed. In this event, the GitCentric database will have recorded Git commits which are not in the restored repositories.

When the GitCentric restore encounters a rollback condition, it writes a message to output like the following:

In this example, the GitCentric administrator needs to be aware that any AccuRev transaction-Git commit pair greater than transaction number 61 is not known to the Git repositories; GitCentric has rolled back database transactions to 61 -- the last value known to the Git repositories. Users that have any missing changes in their clone should push them again.

If GitCentric restore cannot locate a branch, it writes a message to output like the following:

In this case, the GitCentric administrator needs to ensure that the copies of all Git repositories have been copied to their original location (that is, the location at the time the GitCentric database backup was created) and that all expected branches are present in those repositories. You may need to delete and recreate the branch mapping in GitCentric.