[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Recover after HD crash (SVN with FSFS backend)

From: Blair Zajac <blair_at_orcaware.com>
Date: 2006-05-24 20:19:48 CEST

Giovanni Bajo wrote:
> Dirk Schenkewitz wrote:
>>>Say you restored up to r100 from the backups. All the working copies
>>>after r100 are doomed. If you have three working copies pointing at
>>>r120, r140 and r160, you should first collect them from the users,
>>>then restore them with the trick you suggested (checkout, copy all
>>>the files over, commit) *and* adding padding (blank) commits into
>>>the repository so that r120 in the server actually matches the
>>>text-base version of the r120 repository, and so on for all three of
>>>them. Now think if you 500 working copies around.
>>Right - without padding/"empty" versions, r120 becomes r101, r140
>>becomes r102 and so on. But since the intermediate versions are lost
>>anyway, why not live with the new revision numbers?
> Because the working copies contains the original version number! The working
> copy that points at r120 expects that r120 on the server reflects *its*
> text-base version. If I commit what-used-to-be r140 as r101 and so on, the
> new r120 will be totally different from what the old working copy was
> expecting. When the user runs update, the client will tell the server "hey
> I'm revision r120, send me deltas", and the server will send deltas between
> the *new* r120 and HEAD! The client will then try to apply those deltas to
> *its* r120, and that won't simply work out. And what's worse, as I said
> below, is that this will probably result in some weird error client-side,
> which the user won't understand.
>>>The net result is that now I have a post-commit hook which dumps and
>>>backups a revision as soon as it is committed. I believe that any
>>>other backup strategy for a SVN server (say, hotcopy once a day)
>>>is basically useless.
>>I have something similar, a script that runs as cron-job every 10
>>minutes and checks if something changed, if yes, it makes a hotcopy.
> I believe that there *ought* be a way to hot-rsync a Subversion server. I
> didn't investigate what hotcopy exactly does, but maybe it can be repdoced
> with a simple script which runs rsync instead of copy. That would save some
> performance and allow it to be done after each commit even on very busy
> servers.

Take a look at


It's my favorite hot backup system, assuming you have a Unix OS and an FSFS
repository. It does the fastest backups, faster than svnadmin hotcopy, since it
uses rsync's --link-dest option to hard link your latest backup to the previous
revisions backup, 99% of the files are unchanged.

It does require subprocess, which only comes with Python 2.4.

After doing the hot backup to a local filesystem using svn-fast-backup, I would
recommend doing an rsync of the directory containing the hot backups to another
box so you have the repository on more than one disk, making sure to use -H so
that rsync preserves hardlinks. Do not just rsync the new hotbackup to a new
box, as then you'll loose the hardlinks between hot backups at different revisions.


Blair Zajac, Ph.D.
Subversion training, consulting and support
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 24 20:21:29 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.