Skip to content

Svn backup and restore process

SVN Backup and Restore

The main reason to backup and restore is to upgrade from one release of SVN to another. The commands go like this (with lots of elapsed time in between):

svnadmin dump /path/to/my/repository/root > /my/backup/filename.svn
[upgrade to the new version of SVN here]
[make backups of repository here]
rm -rf /path/to/my/repository/root
svnadmin create -fs-type fsfs /path/to/my/repository/root
/* --- upgrade your SVN binaries here --- */
svnadmin load /path/to/my/repository/root < /my/backup/filename.svn

Explanation:

  1. The dump command tells SVN to copy all the revisions in the repository to a file called filename.svn (called a dumpfile). Note: Running this command can take considerable time and disk space. SVN creates a directory for every revision in the repository and outputs the entire directory structure of the project(s) within that directory. One alternative is to create single-project backups (more files, smaller each).
  2. The rm command recursively deletes the existing repository location. Make sure your dumps are complete before running this command.
  3. The svnadmin create command creates a new repository in place of the old one. This example shows the repository being created where the old one used to be. It doesn't have to be this way. There can be multiple repositories on disk at any one time. But for large repositories, there might not be enough space to have multiple repositories at the same time.
  4. The statement "upgrade your SVN binaries here" will be performed differently, depending on the OS involved. My assumption is that the installer will remove the existing version of SVN before or during the install.
  5. The svnadmin load command reads the dumpfile and creates a new repository from it. When it completes, the new version of svn will be available just like the previous version, with the repository in the same location. End users who are accessing the repository (locally or via mod_dav_svn) will not see any difference.

There are other ways to perform the upgrade, including one that uses the old and new versions of SVN at the same time. I've found those other methods to be unreliable because:

  • they assume you will remain connected during the upgrade, which might not be true
  • its difficult or impossible to have 2 versions of svn installed on a Windows machine at the same time due to DLL conflicts