You really dont want to do this. You can corrupt your svn database if rsync only gets part of a tranction. A better way is to script backing up the svn repository manually

Agreed about the corruption.  I would instead recommend first making a hotcopy of the working repository and then doing an rsync on that.

The svn "Note: Backup" section seems to agree with this article ...

the repository will not be corrupted as you don't copty transictions and copy current before the rest ...

"So, if you are using standard backup tools to make backups of a FSFS repository, configure the software to copy the "current" file before the numbered revision files, if possible, and configure it not to copy the "transactions" directory.  If you can't do those things, use "svnadmin hotcopy", or be prepared to cope with the very occasional need for repair of the repository upon restoring it from backup."

I'd like to say that I've been using a very similar strategy for backing up my FSFS Svn Repository (going on about 2 GB total data, 4800+ revisions).  I've restored this from backup, and it works fine.  No corruption issues that anyone is complaining about, even with a "live" system that I've TRIED to corrupt - ie making a large (~1500 files) checkin while the backup was in process.  Yes, when I restored the backup (to a third server), the latest update (the ~1.5k files) wasn't there, but I expected that to happen.  re-synching after the update, however, did give me the files I was expecting, and the update I expected.

Since my SVN repo is running on a windows machine, I can't use rsync.  But I CAN use winscp's scripting capability.  The commands are essentially the same:

=== begin winscp scriptfile ===
option batch on
option confirm off
option transfer binary
option include current
synchronize remote c:\mytemprepo /backup/location
option include clear
option exclude transactions
option exclude current
synchronize remote c:\mytemprepo /backup/location
exit
=== end winscp script ===
called with:
winscp.com <session_id> /script=winscpscript > logfile

Now a backup takes a whopping < 5 minutes to run (well, the first one was very long).

I'd like to say that I've been using a very similar strategy for backing up my FSFS Svn Repository (going on about 2 GB total data, 4800+ revisions).  I've restored this from backup, and it works fine.  No corruption issues that anyone is complaining about, even with a "live" system that I've TRIED to corrupt - ie making a large (~1500 files) checkin while the backup was in process.  Yes, when I restored the backup (to a third server), the latest update (the ~1.5k files) wasn't there, but I expected that to happen.  re-synching after the update, however, did give me the files I was expecting, and the update I expected.

Since my SVN repo is running on a windows machine, I can't use rsync.  But I CAN use winscp's scripting capability.  The commands are essentially the same:

=== begin winscp scriptfile ===
option batch on
option confirm off
option transfer binary
option include current
synchronize remote c:\mytemprepo /backup/location
option include clear
option exclude transactions
option exclude current
synchronize remote c:\mytemprepo /backup/location
exit
=== end winscp script ===
called with:
winscp.com <session_id> /script=winscpscript > logfile

Now a backup takes a whopping < 5 minutes to run (well, the first one was very long).