http://snarfed.org Ryan Barrett's blog Wed, 08 Feb 2012 22:20:02 +0000 hourly 1 http://snarfed.org/backup_subversion_fsfs_with_rsync#comment-291 mike Wed, 30 Nov -0001 00:00:00 +0000 http://snarfed.org/wordpress/backup_subversion_fsfs_with_rsync#comment-291 <p>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</p> 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

]]> http://snarfed.org/backup_subversion_fsfs_with_rsync#comment-292 joe Wed, 30 Nov -0001 00:00:00 +0000 http://snarfed.org/wordpress/backup_subversion_fsfs_with_rsync#comment-292 <p>Agreed about the corruption.  I would instead recommend first making a hotcopy of the working repository and then doing an rsync on that.</p> Agreed about the corruption.  I would instead recommend first making a hotcopy of the working repository and then doing an rsync on that.

]]> http://snarfed.org/backup_subversion_fsfs_with_rsync#comment-293 AlberT Wed, 30 Nov -0001 00:00:00 +0000 http://snarfed.org/wordpress/backup_subversion_fsfs_with_rsync#comment-293 <p>The svn "Note: Backup" section seems to agree with this article ...<br /> <br /> the repository will not be corrupted as you don't copty transictions and copy current before the rest ...<br /> <br /> "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."</p> 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.”

]]> http://snarfed.org/backup_subversion_fsfs_with_rsync#comment-294 jonvel Wed, 30 Nov -0001 00:00:00 +0000 http://snarfed.org/wordpress/backup_subversion_fsfs_with_rsync#comment-294 <p>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.<br /> <br /> 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:<br /> <br /> === begin winscp scriptfile ===<br /> option batch on<br /> option confirm off<br /> option transfer binary<br /> option include current<br /> synchronize remote c:\mytemprepo /backup/location<br /> option include clear<br /> option exclude transactions<br /> option exclude current<br /> synchronize remote c:\mytemprepo /backup/location<br /> exit<br /> === end winscp script ===<br /> called with:<br /> winscp.com <session_id> /script=winscpscript > logfile<br /> <br /> Now a backup takes a whopping < 5 minutes to run (well, the first one was very long).</p> 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).

]]> http://snarfed.org/backup_subversion_fsfs_with_rsync#comment-295 jonvel Wed, 30 Nov -0001 00:00:00 +0000 http://snarfed.org/wordpress/backup_subversion_fsfs_with_rsync#comment-295 <p>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.<br /> <br /> 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:<br /> <br /> === begin winscp scriptfile ===<br /> option batch on<br /> option confirm off<br /> option transfer binary<br /> option include current<br /> synchronize remote c:\mytemprepo /backup/location<br /> option include clear<br /> option exclude transactions<br /> option exclude current<br /> synchronize remote c:\mytemprepo /backup/location<br /> exit<br /> === end winscp script ===<br /> called with:<br /> winscp.com <session_id> /script=winscpscript > logfile<br /> <br /> Now a backup takes a whopping < 5 minutes to run (well, the first one was very long).</p> 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).

]]>