Section 10.3. Unwedging Your Repository

10.3. Unwedging Your Repository

If you are using the Berkeley DB backend, you may occasionally find that the repository gets "wedged" after a system crash, failed transaction, or other nasty event. This can happen when the database (for one reason or another) fails to remove an internal lock, which causes every subsequent request to hang indefinitely. Fortunately, fixing the problem is usually easy. In most cases, if you run the svnadmin recover command, you'll be back up and running (although with a large repository, the command might take a while to run). Because this command may modify files in the repository, make sure you run it as the user who owns the repository. You should also make sure that nothing else is accessing the repository while you perform the recovery (i.e., shut down Apache or svnserve). Although the recover command obtains a lock on the database, you can still have problems if another process was already accessing the repository when you started the recovery. If possible, it's also a good idea to make a copy of your repository before you run a recovery, just in case.

 $ svnadmin recover /srv/svnrepos Please wait; recovering the repository may take some time... Recovery completed. The latest repos revision is 13729. 

The svnadmin recover command is a wrapper for the most common use case of the Berkeley DB recovery command, db_recover. Unfortunately, the most common use case is sometimes not enough to recover a broken repository. So, if svnadmin recover fails, you may need to try a catastrophic recovery with db_recover itself. To perform a catastrophic recovery, you need to have an intact backup of your repository, plus all of the log files that have been generated since that backup was made (or just all of the log files that have ever been generated for your repository). Then, you need to follow these steps.

1.	Shut down any Subversion servers to ensure that no one is accessing your repository.
2.	Move the corrupted repository out of the way. $ mv /srv/svnrepos /srv/svnrepos.wedged
3.	Restore a backup of the repository to the original repository location (for instance, /srv/svnrepos).
4.	Copy any log files from your corrupted repository into the recovered backup version. $ cp /srv/svnrepos.wedged/db/log* /srv/svnrepos/db/ If you have backups of log files that are stored elsewhere, you can copy them in, too. If you do copy log files from multiple places, make sure you copy from oldest backup to newest backup. Multiple backups may have different versions of the same log file, so copying from oldest to newest will ensure that you have the newest version of each log file.
5.	Run db_recover with the -c option. $ db_recover -cv -h /srv/svnrepos/db
6.	If the recovery was successful, you can safely remove the corrupted repository. $ rm -rf /srv/svnrepos.wedged

If you are recovering from a complete set of log files instead of a backup repository, you can skip steps 2 and 3. Instead, copy any necessary log file backups into the corrupted repository directory and run the recovery directly on it. You may need to remove the corrupted repository table files: nodes, revisions, representations, changes, strings, TRansactions, and uuids. Of course, you should still make a backup of the corrupted repository before you attempt the recovery.