SVN migration and Backup methods "Go"

Turn from: http://spiritfrog.iteye.com/blog/448578 + http://magnet2008.iteye.com/blog/586578

Backup policy ==============svn backups are typically made in three different ways:
1) Svnadmin Dump
2) Svnadmin Hotcopy
3) Svnsync.

Note that SVN backup is not recommended for normal file copy (unless you pause the library when you back up), such as the Copy command, the rsync command.
I used the rsync command to do incremental and full backup, in the quarterly backup check audit, found that the majority of the backup library is not available, so it is best to use the functionality provided by SVN itself for backup.

Pros and Cons analysis
==============
The first type of Svnadmin dump is the official recommended backup method, with the advantage of being flexible enough to have a full backup or incremental backup, and to provide a version recovery mechanism.
The disadvantage is that if the version is larger, such as the number of versions increases to tens of thousands of, hundreds of thousands of, then the process of dump will be very slow, backup time, recovery more time-consuming, not conducive to rapid disaster recovery.
It is recommended that you use this backup method when the number of versions is smaller.
The second Svnadmin hotcopy original design objective is not to be used for backup, only a full-volume copy can not be incremental backup;
The advantage is that the backup process is fast and disaster recovery is fast, and if the SVN service is already set up on the backup machine and does not even need to be restored, simply configure it to switch to the backup repository.
The disadvantage is: more expensive hard disk, need to have a large hard disk support (my backup machine has 1TB space, hehe).
The third kind of svnsync is actually making 2 mirror libraries, and when one is broken, you can quickly switch to another. However, this feature must be supported on svn1.4 versions.
The advantages are as follows: when making 2 mirror libraries, we play the role of two-machine real-time backup;
The downside is that when used as 2 mirror libraries, there is no way to "completely abandon today's changes and revert to what they were like last night"; while daily backup as a normal backup mechanism, the operation is more troublesome than the first 2 methods.

Backup command ============== Full backup: Use Svnadmin dump or svnadmin hotcopy or svnsync to do it,
Hotcopy:
Svnadmin hotcopy path/to/repository Path/to/backup–clean-logs
Dump
Svnadmin dump repository path and name –revision Export version number > export naming

Incremental backup: Use Svnadmin Dump's –incremental option to implement
Svnadmin dump repository path and name –revision last exported version number: to this minor export to the version number –incremental > exported naming

A tip: If you have a larger subsersion repository and you want to back it up with the least amount of space, use this command (please replace/repo with your repository path):
Svnadmin dump–deltas/repo |bzip2 |tee dump.bz2 | Md5sum >DUMP.MD5
The most important step is-deltas, which consumes more CPU resources, but has a more efficient and differentiated storage approach.
The BZIP2 compression scheme is slower than gzip, but in exchange for better compression ratios.
More interestingly, the tee method moves the compressed data flow to the file dump.bz2, while outputting it to the standard output, which has turned to the MD5 Summary calculation tool.

Restore command ============== Restore version: Svnadmin load to restore the repository path and name < export naming
Svnadmin hotcopy path/to/repository Path/to/backup–clean-logs

Svnadmin Dump
==============

This is a backup method that is officially recommended by subversion.

1) Define the backup policy:
Backup frequency: Full backup every Saturday, incremental backup every Sunday to Friday
Backup location: Backup storage path to/home/backup/svn/
Backup name: Full backup file name: WEEKLY_FULLY_BACKUP.YYMMDD, incremental backup file named: DAILY-INCREMENTAL-BACKUP.YYMMDD
Backup time: Starting every 21 o'clock in the evening
Backup check: Svnadmin load recovery test at the end of each month.
2) Create a full-scale backup script:
Under ~/, create a Perl script file named weekly_backup.pl, perform a full backup, and compress the backup file, the code is as follows (this code only for one library backup, if it is more than one library to make the corresponding changes):

#!/usr/bin/perl-w
My $svn _repos= "/home/svn/repos/project1";
My $backup _dir= "/home/backup/svn/";
My $next _backup_file = "Weekly_fully_backup." ' Date +%y%m%d ';

$youngest = ' Svnlook youngest $svn _repos ';
Chomp $youngest;

Print "Backing up to revision $youngest \ n";
My $svnadmin _cmd= "Svnadmin dump--revision 0: $youngest $svn _repos > $backup _dir/$next _backup_file";
' $svnadmin _cmd ';
Open (LOG, "> $backup _dir/last_backed_up"); #记录备份的版本号
Print LOG $youngest;
Close LOG;
#如果想节约空间, then execute the following compression script
Print "compressing dump file...\n";
print ' gzip-g $backup _dir/$next _backup_file ';

3) Create an incremental backup script:
On a full-scale backup basis, make incremental backups: Create a Perl script file under ~/, named: daily_backup.pl, with the following code:

#!/usr/bin/perl-w
My $svn _repos= "/home/svn/repos/project1";
My $backup _dir= "/home/backup/svn/";
My $next _backup_file = "Daily_incremental_backup." ' Date +%y%m%d ';

Open (In, "$backup _dir/last_backed_up");
$previous _youngest = <IN>;
Chomp $previous _youngest;
Close in;

$youngest = ' Svnlook youngest $svn _repos ';
Chomp $youngest;
if ($youngest eq $previous _youngest)
{
Print "No new revisions to backup.\n";
Exit 0;
}
My $first _rev = $previous _youngest + 1;
Print "Backing up revisions $youngest ... \ n";
My $svnadmin _cmd = "Svnadmin dump--incremental--revision $first _rev: $youngest $svn _repos > $backup _dir/$next _backup _file ";
' $svnadmin _cmd ';
Open (LOG, "> $backup _dir/last_backed_up"); #记录备份的版本号
Print LOG $youngest;
Close LOG;
#如果想节约空间, then execute the following compression script
Print "compressing dump file...\n";
print ' gzip-g $backup _dir/$next _backup_file ';

4) Configure the/etc/crontab file
Configure the/etc/crontab file, specify the execution weekly_backup.pl every Saturday, specify Monday to Friday to execute daily_backup.pl;
The concrete steps I will not wordy.

5) Backup Recovery check
At the end of the month recovery check or in the case of a disaster, follow these steps to recover: restore order from the lower version to a higher version, i.e., restore the most recent full backup weekly_full_backup.071201 (example), and then restore the incremental backup next to this file daily_incremental_backup.071202, then restore the day after the backup 071203, and so on. As follows:
User1>mkdir Newrepos
User1>svnadmin Create Newrepos
User1>svnadmin Load Newrepos < weekly_full_backup.071201
User1>svnadmin Load Newrepos < daily_incremental_backup.071202
User1>svnadmin Load Newrepos < daily_incremental_backup.071203
....

If the backup is compressed with gzip, the decompression and recovery commands can be merged and simply written as:
User1>zcat weekly_full_backup.071201 | Svnadmin Load Newrepos
User1>zcat daily_incremental_backup.071202 | Svnadmin Load Newrepos
Svnadmin Hotcopy Copy method of the whole library
==============svnadmin Hotcopy is a copy of the entire library "hot", including the library's hook scripts, configuration files, etc.; run this script at any time to get a secure copy of the repository, regardless of whether other processes are using the repository.
So this is my favorite way to backup.

1) Define a backup strategy
Backup frequency: Make a full backup every day,
Backup location: Backup directory named by date, backup path to/HOME/BACKUP/SVN/${MMDD}
Backup retention period: 10 days to 15 days, more than 15 days to delete.
Backup time: Starting every 21 o'clock in the evening
Backup check: Automatically run the check script and send the report automatically after the backup is finished.
2) Create a backup script
Create a file under your home directory ~/, backup.sh:

#!/bin/bash
srcpath=/home/svn/repos/; #定义仓库parent路径
distpath=/home/backup/svn/' Date +\%m%d '/; #定义存放路径;
If [-D "$DISTPATH"]
Then
Else
mkdir $DISTPATH
chmod g+s $DISTPATH
Fi
Echo $DISTPATH
Svnadmin hotcopy $SRCPATH/project1 $DISTPATH/project1 >/home/backup/svn/cpreport.log 2>&1;
Svnadmin hotcopy $SRCPATH/project2 $DISTPATH/project2
CP $SRCPATH/access $DISTPATH; #备份access文件
CP $SRCPATH/PASSWD $DISTPATH; #备份passwd文件
perl/home/backup/svn/backup_check.pl #运行检查脚本
perl/home/backup/svn/deletdir.pl #运行删除脚本 to delete an expired backup.

3) Create a check script
Create a Perl script under/home/backup/svn/, where specified above: backup_check.pl
The idea of a backup integrity check is to run Svnlook youngest on the backed-up library, and if the latest version number is printed correctly, the backup file is not missing, and if an error is run, the backup is incomplete. I tried. If the backup is interrupted, running Svnlook youngest will cause an error.

4) Define the delete script
Because it is a full-scale backup, the backup should not be kept too much, only need to retain the last 10 days, for more than 15 days of history of the backup can basically be deleted.
Create a Perl script under/home/backup/svn/: deletdir.pl

5) Modify the/etc/crontab file

Specify the "backup.sh" script to execute every 21 o'clock in the evening in the file.

Svnsync Backup
============== using Svnsync Backup is simple and the steps are as follows:
1) Create an empty library on the backup machine: svnadmin Create Project1
2) Change the library's hook script pre-revprop-change (because svnsync to change the properties of the library, that is, to back up the properties of the source library to this library, so to enable this script):
CD smp/hooks;
CP Pre-revprop-change.tmpl Pre-revprop-change;
chmod 755 Pre-revprop-change;
VI Pre-revprop-change;
Comment out the three sentences that follow the script, or simply make it an empty file.
3) initialization, no data has been backed up at this time:
Svnsync Init File:///home/backup/svn/svnsync/Project1/http://svntest.subversion.com/repos/Project1
The syntax is: Svnsync init {The library URL you just created} {Source Library URL}
Note The local URL is a three slash:///
4) Start Backup (sync):
Svnsync Sync File:///home/backup/svn/svnsync/Project1
5) Create a synchronization script
After the backup is complete, create a hook script to synchronize. Create/Modify the Post-commit script under Source Library/hooks/, and add one line to the following:
/usr/bin/svnsync Sync--non-interactive File:///home/backup/svn/svnsync/Project1
You may have noticed that the backup above appears to be a local backup, not an offsite backup.  In fact, I did this by using the remote backup mount (see Mount command) to the SVN server, which logically appears to be a local backup, physically an offsite backup. Finish!

Here's what subversion officially recommends for backup.
Close all running processes and verify that no programs are accessing the repository (such as httpd, Svnserve, or local users in direct access).
Backing up the SVN repository
#压缩备份
Svnadmin Dump/home/workhome/svn/repository | gzip > ~/repository-backup.gz
#不压缩备份
Svnadmin dump/home/workhome/svn/repository > ~/REPOSITORY-BACKUP.SVN

Recovering the SVN repository
#建立新的svn存储库
Svnadmin create/home/workhome/svn/newrepository
#确认成功与否
Ls-l/home/workhome/svn/newrepository
#导入存储库数据
Svnadmin Load/home/workhome/svn/newrepository < ~/REPOSITORY-BACKUP.SVN

SVN database Migration Method One

Known as SVN full-Library operation, or SVN global backup and recovery, repository data porting: Svnadmin dump, svnadmin load
Export:
$svnadmin dump repos > DumpFile//Export the specified repository to a file dumpfile
New:
$svnadmin Create Newrepos
Import:
$svnadmin Load Newrepos < DumpFile

SVN Database Migration method two
Incremental or batch backup, batch recovery, specific reversion export:
$svnadmin dump Repos–r >rev-23.dumpfile//Export version23
$svnadmin dump Repos–r 100:200 >rev-100-200.dumpfile//Export version100~200
Batch export: Larger libraries can be batch-exported for easy backup
$svnadmin Dump Repos–r 0:1000 >0-1000.dumpfile
$svnadmin dump Repos–r 1001:2000--incremental >1001-2000.dumpfile
$svnadmin dump Repos–r 2001:3000--incremental >2001:3000.dumpfile
Batch import to load these backup files into a new repository
$svnadmin Load Newrepos < 0-1000.dumpfile
$svnadmin Load Newrepos < 1001-2000.dumpfile
$svnadmin Load Newrepos < 2001:3000.dumpfile
SVN Database Migration method Three
After exporting, do the library sorting or other sorting operations on the import to filter the Repository history:
Suppose you have a repository with three items: Calc,calendar, and spreadsheet. They are laid out in the repository as follows:
/
calc/
trunk/
branches/
tags/
calendar/
trunk/
branches/
tags/
spreadsheet/
trunk/
branches/
tags/
Now it's time to move these three projects to three separate repositories. First, dump the entire repository:
$ svnadmin dump/path/to/repos > Repos-dumpfile
* Dumped Revision 0.
* Dumped Revision 1.
* Dumped Revision 2.
* Dumped Revision 3.
Then, three times the dump file is fed into the filter, and each time you keep only one top-level directory, you can get three dump files:
$ Cat Repos-dumpfile | Svndumpfilter include calc > calc-dumpfile
$ Cat Repos-dumpfile | Svndumpfilter include calendar > Cal-dumpfile
$ Cat Repos-dumpfile | Svndumpfilter include spreadsheet > Ss-dumpfile
Now you have to make a decision. Each of these three dump files can be used to create an available repository, but they retain the exact path structure of the original repository. That is, although Project Calc now has an exclusive repository, the repository also retains a top-level directory called Calc. If you want trunk, tags, and branches to be located directly under the root path of the repository, you may need to edit the dump file, adjust the Node-path and Copyfrom-path header parameters, and delete the path calc/. Also, you want to delete the part of the dump data that created the Calc catalog. In general, here are some of the following:
Node-path:calc
Node-action:add
Node-kind:dir
content-length:0
Warning:
If you plan to remove a top-level directory by manually editing the dump file, be careful not to have your editor convert the newline character to a local format (such as \ r \ n). Otherwise the contents of the file do not match the desired format, and the dump file is invalidated.
The rest of the work is to create three new repositories, and then import the three dump files separately:
$ svnadmin Create calc; Svnadmin Load Calc < calc-dumpfile
$ svnadmin Create calendar; Svnadmin Load Calendar < Cal-dumpfile
$ svnadmin Create spreadsheet; Svnadmin Load Spreadsheet < Ss-dumpfile
The two subcommands of Svndumpfilter can be set by the option to handle "empty" revisions. If a specified revision contains only changes to the path, the filter removes it because the currently empty revision is often useless or even annoying. To give users the option to process these revisions, Svndumpfilter provides the following command-line options:
--drop-empty-revs
Do not generate any empty revisions, ignoring them.
--renumber-revs
If an empty revision is excluded (by using the--drop-empty-revs option), modify the numbering of the other revisions to make sure that the numbering sequence is sequential.
--preserve-revprops
If an empty revision is retained, keep these empty revisions of the properties (log information, author, date, custom attributes, and so on). If this option is not set, an empty revision retains only the initial timestamp and an automatically generated log message indicating that the revision was processed by Svndumpfilter.
Although Svndumpfilter is very useful and can save a lot of time, it is a double-edged sword. First, this tool is extremely sensitive to path semantics. Double-check that the path in the dump file is preceded by a slash. Perhaps Node-path and Copyfrom-path these two head parameters to help you a little.
Node-path:spreadsheet/makefile
If these paths start with a slash, then the paths you pass to Svndumpfilter include and Svndumpfilter exclude must also start with a slash (and vice versa). If, for some reason, the paths in the dump file are not uniformly used or do not start with a slash, you may need to fix these paths, using either a diagonal line or a slash start.
In addition, the path generated by the copy operation can cause trouble. Subversion supports copy operations in the repository, that is, copying an existing path and generating a new one. The problem is that a file or directory that svndumpfilter retains may be copied from a file or directory that is excluded by a svndumpfilter. That is, in order to ensure the integrity of the dump data, Svndumpfilter needs to sever the relationship between the files that are copied from the excluded path and the source files, and add the contents of those files to the dump data in a new way. However, because the Subversion repository dump file format contains only the revision information, the contents of the source file are largely inaccessible. If you are unsure whether a similar situation exists in the repository, it is a good idea to reconsider which paths to keep/exclude.
Backup Environment Note points:
1. Make sure no other processes access the repository, close Apache, Svnserve services
2. Become an administrator of the repository, if you restore the repository as a different identity, you may change the access rights of the repository file, resulting in the inability to access after recovery
3, Svnadmin Recover/path/to/repos
4. Restart the service process
SVN Database Collation method
Do not go through the dump,load operation, the implementation of the SVN database, first design the adjusted directory, and then open the repository, select the file (folder) to adjust or transfer, and right-drag, do not let go and then the file (folder) will be transferred to the destination folder-- >--select Move items to here--> complete

With each such adjustment, everyone will worry about whether the history will still exist, TORTOISESVN will not be displayed by default, and an option needs to be removed.

This allows for library-based tuning operations, but everything is not as good as it should be, and revision will grow a lot when this happens.
My idea is:
Stop the current SVN service, the current SVN library directly to organize, just like the folder stored in the computer, and then open the SVN service, instantly display the adjusted effect, haha. is not a bit whimsical, in fact, I also think this is not possible, unless the use of tools to access, otherwise the SVN library is not visible, I hope that later what configuration management tool can let administrators have such permissions.

Experiment:
one, in the move out server execution:
[email protected]:~/csvn/bin> CSVN Stop
Stopping Csvn Console ...
Waiting for CSVN Console to exit ...
Waiting for CSVN Console to exit ...
Stopped csvn Console.
[email protected]:~/csvn/bin> csvn-httpd Stop
Stopping Subversion Edge Apache Server: Done
[email protected]:~/csvn/data/repositories> Svnadmin Dump/home/svn/csvn/data/repositories/camp | Gzip >camp_dumpfile_20130610.gz
......
* Dumped revision 4495.
* Dumped revision 4496.
[email protected]:~/csvn/data/repositories> ls
Camp camp_dumpfile_20130610.gz cpst CSVN csvn-httpd docm

second, in the migration server execution:
Take out the exported files on the server camp_dumpfile_20130610.gz;
[email protected]:~/data/repositories> Svnadmin Create/home/csvn/data/repositories/newcamp
[email protected]:~/data/repositories> gzip-d camp_dumpfile_20130610.gz
[email protected]:~/data/repositories> Svnadmin Load/home/csvn/data/repositories/newcamp < camp_dumpfile_20130610
......
<<< Started new transaction, based on original revision 4495
* Editing path:trunk/site/campost/src/dsp/frmdomitemmod.mcpp ... done.
* Editing path:trunk/site/campost/src/dsp/frmintitemmod.mcpp ... done.
-------Committed Revision 4495 >>>
<<< Started new transaction, based on original revision 4496
* Editing path:trunk/site/campost/src/dsp/frmdspinterclosedisp.mcpp ... done.
-------Committed Revision 4496 >>>
[email protected]:~/bin> CSVN Start
Starting CSVN Console ...
CSVN Console started
Waiting for application to initialize (this could take a minute) ..... ..... ..... ..... ......... ...............
CSVN Console is ready at HTTP://LOCALHOST:3343/CSVN
[email protected]:~/bin> csvn-httpd Start
Starting Subversion Edge Apache Server:

Reference:

Http://developer.51cto.com/art/201005/202261.htm

Http://www.cnblogs.com/itech/archive/2011/10/11/2206988.html

Http://www.cnblogs.com/jifeng/p/4196238.html

SVN migration and Backup methods "Go"