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
dumpcommand tells SVN to copy all the revisions in the repository to a file called
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).
rmcommand recursively deletes the existing repository location. Make sure your dumps are complete before running this command.
svnadmin createcommand 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.
svnadmin loadcommand reads the dumpfile and creates a new repository from it. When it completes, the new version of
svnwill 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:
svninstalled on a Windows machine at the same time due to DLL conflicts