Backup and Restore of SVN Server

[Felix Natter <fe...@sidact.com>]

Dear SVN community,

I have a few questions regarding backup and restore of a SVN Server:

1. I would like to create daily backups to a cloud service using duplicity
  (basically full/incremental tars). Now I can do this (a) with a simple 
filesystem
  backup or (b) create dumps using svnadmin dump and backup them using
  duplicity.

   -> (a) is not safe in case someone does a commit during the backup?

   -> (b) would take much more time (we have many, sometimes big, repos),
       so it might not finish over night?

   -> which one is better? Or is there a (c)?

2. I think I shall use --force-uuid when replaying the dumps (in case of 
(b))
     so that colleagues can just "svn relocate" and continue working?

3. Are there limitations on what "svn relocate" can handle? Do I need to 
test
     some corner cases? (Both servers are using svn+ssh:// but with totally
    different paths and different auth)

4. Are there best practices / blogs for migrating svn repos to another 
server?

Many Thanks in Advance and Best Regards!

Felix

-- 

*SIDACT GmbH
Simulation Data Analysis and
Compression Technologies
*
*Felix Natter*
/Software Developer /

Auguststraße 29
53229 Bonn
Germany

Phone 	 :   +49 228 5348 0430
Direct 	 :   +49 228 4097 7118
Email 	 : felix.natter@sidact.com
Web 	 : http://www.sidact.com/

Re: Backup and Restore of SVN Server

[Daniel Sahlberg <da...@gmail.com>]

Den ons 7 dec. 2022 kl 12:06 skrev Felix Natter <fe...@sidact.com>:

> Dear SVN community,
>
> I have a few questions regarding backup and restore of a SVN Server:
>
> 1. I would like to create daily backups to a cloud service using duplicity
>  (basically full/incremental tars). Now I can do this (a) with a simple
> filesystem
>  backup or (b) create dumps using svnadmin dump and backup them using
>  duplicity.
>
This is discussed in the SVN Book, see [1].

>   -> (a) is not safe in case someone does a commit during the backup?
>
I think it was mentioned somewhere on the list that you *could* do this if
you are very careful with the order you copy the files, basically coping
metadata first then actual contents. But it seems risky and prone to errors
in case future Subversion versions changes things in the repository layout.

Look at svnadmin freeze which was added in Subversion 1.8.0, see the SVN
book[2]. This is explicitly intended to "[A]llow[s] safe use of third-party
backup tools on a live repository." (copied from the output of svnadmin
help freeze).

>   -> (b) would take much more time (we have many, sometimes big, repos),
>       so it might not finish over night?
>
>   -> which one is better? Or is there a (c)?
>
If you are not able to lock the repository (as in (a)) for the time the
backups take), you could use svnsync to copy the repository to a remote
server and take the backups from there. See the SVN book[3] and pay
attention to the copy-revprops command and to backup any hook scripts
manually.

Or you can use svnadmin hotcopy (with --incremental?) if you have space to
spare at the Subversion server, see [4].

> 2. I think I shall use --force-uuid when replaying the dumps (in case of
> (b))
>     so that colleagues can just "svn relocate" and continue working?
>
> 3. Are there limitations on what "svn relocate" can handle? Do I need to
> test
>     some corner cases? (Both servers are using svn+ssh:// but with totally
>    different paths and different auth)
>
> 4. Are there best practices / blogs for migrating svn repos to another
> server?
>
Kind regards,
Daniel


[1]
https://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.backup

[2] https://svnbook.red-bean.com/nightly/en/svn.ref.svnadmin.c.freeze.html
(I have to look to the svn book nightly, since the last published book only
covers 1.7.)
[3]
https://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
[4] https://svnbook.red-bean.com/nightly/en/svn.ref.svnadmin.c.hotcopy.html