On Oct 24, 2006, at 18:59, Tim Liu wrote:
> I have read svn book and mailing list about this topic. I'd like to  
> summarize them and make sure what I understand meets my  
> requirements. thank you for your opinios first.
>
> Requirement
> ==========
> Backup repository perodically and in case of failure,  restore  
> backup repository as first repository.
> We are using FSFS
>
> A few choices:
>
> 1. svnadmin hotcopy
>
> 2. shut down public access to copy directory manually
>
> 3. incremental backup
>
> 4. hot-backup.py
>
> 5. svnsync
>
> 6. write a new backup script
>
> Look like choice #1 is simple. I just need to write a con job to  
> run it periodically. The drawback is if backup happens in the  
> middle of commit, backup has obsolete information.
Sure, the backup has obsolete information if a commit happens later.  
But it does not have inconsistent or incorrect information in it,  
which is the main thing: It is designed to be used on a live  
repository (hence "hot" in the name). From the book:
http://svnbook.red-bean.com/en/1.2/svn.ref.svnadmin.c.hotcopy.html
"You can run this command at any time and make a safe copy of the  
repository, regardless of whether other processes are using the  
repository."
If you want to be absolutely safe, and I recommend this, then you  
could do both of the following:
- "svnadmin hotcopy $REPOS new.repos" periodically via cron.
- "svnadmin dump $REPOS --incremental > complete.dump" periodically  
via cron.
This way you have backups in two different formats -- one (a hot  
backup) which can replace the primary repository on a moment's  
notice, and the other (the dump file) which can be loaded into a new  
repository, which takes longer, but is useful when upgrading to a new  
version of Subversion if that new version offers improvements in  
repository storage, like 1.4.0 does. Also, do this:
- "svnadmin dump $REPOS -r $REV --incremental > rev_$REV.dump" in  
your post-commit hook so that you have a backup created immediately  
after each revision is committed, so that if your repository blows  
up, you'll be able to get back each and every revision up to the very  
latest one. This is very important because if you do not do this and  
you lose the last few revisions because your backup is old, then  
everybody will have to throw out their working copies and get new  
ones because their old working copies may point to revisions the  
server no longer knows anything about, which will cause problems.  
This is inconvenient and wastes time, so it's best to implement a  
complete backup strategy.
Another good thing you can do in your cron task is "svnadmin verify"  
to make sure the repository stays healthy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 25 03:23:36 2006