SVN full backup, Incremental backup, and Database Synchronization

Full backup
The most common and simple backup is to directly use the copy command to copy the version library directory to the backup directory. However, this is not a safe method, because if the version library changes during the copy process, the backup results will be inaccurate and the backup function will be lost, therefore, subversion provides the "svnadmin hotcopy" command to prevent this problem.

Do you still remember our version library directory?

D:/svnroot
├ ── Project1
│ ─ ── Conf
│ ├ ── Dav
│ ─ ── DB
│ ─-Revprops
│ ── Revs
│ Transactions
│ ─ ── Hooks
│ ─ ── Locks
└ ── Project2
├ ── Conf
├ ── Dav
Analytic DB
│ Bai── revprops
│ ─ ── Revs
│ Transactions
├ ── Hooks
─ ── Locks

To back up project1 to the d:/svnrootbak directory, run:

Svnadmin hotcopy D:/svnroot/project1 D:/svnrootbak/project1

2. Incremental Backup
Full backup is simple but costly. When the version library is very large, it is unrealistic and unnecessary to perform full backup, but what should I do if there is a problem between the backup of the version library? Here we use Incremental backup.

Incremental backup is usually used in combination with full backup, just like the archive log of the Oracle database, which records the changes submitted every time the Subversion is changed, and then returns to the latest available status when recovery is required. In this example, we use the svnadmin dump command to perform Incremental backup by using the following methods:

Svnadmin dump project1 -- Revision 15 -- incremental> dumpfile2

The preceding command implements Incremental backup of revision 15. The output file dumpfile2 only saves the modified content of revision 15.

To record the results submitted each time, we need to use a subversion feature-hook to see our project1 directory:

├ ── Project1
│ ─ ── Conf
│ ├ ── Dav
│ ─ ── DB
│ ─-Revprops
│ ── Revs
│ Transactions
│ ─ ── Hooks
│ ─ ── Locks

The hooks directory contains the hook script. Here we only use the post-commit hook. This hook will be executed after each submission. In order to implement our backup function, we create a file post-commit.bat Under hooks with the following content:

Echo off
Set svn_home = "C:/program files/subversion"
Set svn_root = D:/svnroot
Set unix_svn_root = D:/svnroot
Set delta_backup_svn_root = D:/svnrootbak/Delta
SET LOG_FILE = % 1/backup. Log
Echo backup revision % 2> % LOG_FILE %
For/R % svn_root % I in (.) do if D:/svnroot/% ~ Ni = % 1% svn_root %/% ~ Ni/hooks/deltabackup. Bat % ~ Ni % 2
Goto end
: End
This script can be used to implement automatic Incremental backup to D:/svnrootbak/Delta when the version library under D:/svnroot is submitted (to confirm that this directory exists), where the deltabackup is used. BAT can be stored anywhere, but it is packaged with the svnadmin dump of the script. The content is as follows:

@ ECHO is backing up version library % 2 ......
% Svn_home %/bin/svnadmin dump % svn_root %/% 1 -- incremental -- Revision % 2> % delta_backup_svn_root %/% 1. Dump
@ Echo version library % 2 successfully backed up to % 3!

The above two scripts can be directly copied to the hooks directory of project2, and automatic backup of project2 can be achieved without modification.

The above operations are OK. Now we need to combine full backup and Incremental backup, that is, to clear the Incremental backup after full backup, to save only the results after full backup.

If a version database fault occurs, we need to restore the version database. This is to use the svnadmin load command, at the same time, you also need the last full backup, for example, to make the last full backup backuprepo, and the subsequent Incremental Backup dumpfile:

Svnadmin load backuprepo <dumpfile

Finally, you can download svnroot.rar, decompress it to D:/, and modify the svn_home of several BAT files.

3. Version library Synchronization
Subversion 1.4 adds a synchronization mechanism to synchronize a version library with another version Library (but it seems to be only one-way). We can implement backup or image of the version library.

3.1. initialize the target database
Svnsync init SVN: // localhost/project2 SVN: // localhost/project1
Project2 is the target version library, while project1 is the source version library. The target version library must be empty and must allow modifications to the Revision property, that is, adding a file pre-revprop-change.bat to the hooks directory of the target version library with a blank content.

3.2. Synchronize project2 to project1
Svnsync sync SVN: // localhost/project2
At this time, you can update a copy of project2 to find all the content of project1. If project1 is submitted again, the latest changes cannot be seen in the version library of project2. You need to run the sync operation again to synchronize the latest changes. Note that the target version library can only be read-only. If the target version library is changed, the synchronization will not continue.

3.3. Modify synchronization history attributes
Because synchronization does not update changes to historical attributes, svnsync also has a sub-command copy-revprops to synchronize attributes of a specific version.

3.4. Automatic hook Synchronization
To synchronize data at each commit, you need to add the post-commit script to the source database. The content is as follows:

Echo offset svn_home = "D:/subversion" % svn_home %/bin/svnsync sync -- non-interactive SVN: // localhost/project2
Store the above content as a post-commit.bat, and then put it under the hooks directory under the version library project1, so that each submission of project1 will cause synchronization of project2.