Backup and restore of visual svn [transfer]

Visual SVN backup and restore
Except for the most commonly used operations such as update, checkout, commit, etc., the most common one is the backup and restore of the svn repository.
Backup strategy
svn backup generally adopts three methods:
1) svnadmin dump
2) svnadmin hotcopy
3) svnsync.

Note that svn backup should not use ordinary file copying methods (unless you suspend the library during backup), such as copy command, rsync command .
The author once used the rsync command to do incremental and full backups. During the quarterly backup inspection and audit, it was found that most of the backed up libraries were unavailable. Therefore, it is best to use the functions provided by svn itself for backup.

Analysis of advantages and disadvantages:
=============
The first svnadmin dump is the officially recommended backup method. .
The disadvantage is: if the version is relatively large, such as the number of versions increases to tens of thousands or hundreds of thousands, the dump process will be very slow; backup is time-consuming, and recovery is more time-consuming; it is not conducive to rapid disaster recovery.
Personally, it is recommended to use this backup method when the number of versions is relatively small.
The original design purpose of the second type of svnadmin hotcopy is estimated not to be used for backup. It can only perform full copy, but cannot perform incremental backup. The
advantages are: the backup process is faster, and the disaster recovery is also fast; if the svn service has been built on the backup machine, You don't even need to restore, you just need to do simple configuration to switch to the backup repository to work.
Disadvantage is: it consumes more hard disk and needs larger hard disk support (my backup machine has 1TB space, huh, huh).
The third type of svnsync is actually to make 2 mirror libraries, when one is broken, you can quickly switch to the other. However, this function must be supported by svn1.4 or above.
The advantage is: when it is made into two mirror libraries, it can play the role of real-time backup of two machines; the
disadvantage is: when it is used as two mirror libraries, there is no way to "want to completely abandon today's changes and restore to last night's appearance. ”; and when it is used as a common backup mechanism for daily backup, the operation is more troublesome than the first two methods.

The backup command says

full backup: use svnadmin dump or svnadmin hotcopy or svnsync to do,
hotcopy:
svnadmin hotcopy path/to/repository path/to/backup –clean-logs
dump:
svnadmin dump repository path and name –revision exported Version number > Exported name

Incremental backup: use the --incremental option of svnadmin dump to implement
svnadmin dump repository path and name --revision Last exported version number: to the version number to be exported to this time --incremental > Exported name

One tip: if you have a large Subsersion repository and you want to back it up with the least amount of space, use this command (replace /repo with your repository path):
svnadmin dump --deltas / repo |bzip2 |tee dump.bz2 | md5sum >dump.md5
Step-by-step explanation: The most important step is -deltas, which will consume more CPU resources but have a more efficient way to store differences.
The bzip2 compression scheme is slower than gzip, but in exchange for better compression ratios.
More interestingly, the tee method diverts the compressed data stream to the file dump.bz2, while outputting it to standard output, which is diverted to the MD5 digest calculation tool.

Restore command:
restore version: svnadmin load path and name of the repository to be restored < export name
svnadmin hotcopy path/to/repository path/to/backup –clean-logs