Comparison and Analysis of svn backup methods
Generally, three methods are used:
1. svnadmin dump
2. svnadmin hotcopy
3) svnsync
Note: svn backup should not adopt the normal file copy method (unless you pause the database during Backup), such as the copy and rsync commands.
I used the rsync command for incremental and full backup. During the quarterly backup check and audit, I found that most of the databases backed up are unavailable. Therefore, it is best to use the functions provided by svn for backup.
Advantages and disadvantages:
The first svnadmin dump is an officially recommended backup method. It has the advantage of being flexible, supports full backup or Incremental backup, and provides a version recovery mechanism.
Disadvantages: if the version is relatively large, for example, if the number of versions increases to tens of thousands or hundreds of thousands, the dump process will be very slow; backup time consumption and recovery time consumption will be more time consuming; it is not conducive to rapid disaster recovery.
We recommend that you use this backup mode when the number of versions is small.
The original design purpose of svnadmin hotcopy is not estimated to be used for backup. It can only be used for full copy, but not Incremental backup;
The advantage is that the backup process is fast and disaster recovery is fast. If the svn service has been set up on the backup machine and you do not need to recover it, you only need to perform simple configuration to switch to the backup database.
Disadvantage: it is relatively hard disk-consuming and requires large hard disk support (the backup machine has 1 TB space ).
The third type of svnsync is actually to create two image libraries. When one fails, it can be quickly switched to another. However, this function must be supported only in svn1.4 or later versions.
Advantage: When two image libraries are created, the dual-host real-time backup function is enabled;
The disadvantage is that, when used as two image libraries, we cannot "completely discard the changes we made today and restore them to the last night". When we backup them daily as a normal backup mechanism, the operation is more difficult than the first two methods.
Svnadmin dump ModeSVN migration requires the following operations:
1. Export the original Repository as a file dumpfile.
# Svnadmin dump the original repos directory path (/repository/directory)> dumpfile
# Svnadmin dump/opt/svn/iitshare/>/var/tmp/iit1__20130626
2. Configure the same SVN server on another machine.
Reference: linux SVN installation and configuration graphic tutorial
3. Import dumpfile to the new repository directory.
# Svnadmin load the directory path of the newly created repos (/repository/directory) <dumpfile
# Svnadmin load/opt/svn/iitshare/</var/tmp/iit1__20130626
4. Back up the configuration file of the original server and copy it to the new server.
#/Opt/svn/iitshare/conf directory
Authz, passwd, and svnserve. conf files
Svnadmin hotcopy Method1. Backup
# Svnadmin hotcopy/opt/svn/iitshare // var/tmp/iit1__20130626-clean-logs
If you pass the-clean-logs option, svnadmin performs the hot copy operation and then deletes unused Berkeley DB log files.
You can run this command at any time to obtain a secure copy of the version library, regardless of whether other processes use this version library.
2. Restore
# Svnadmin hotcopy/var/tmp/iitshare_20130626/opt/svn/iitshare/