Daniel Berlin wrote:
> When I started looking at Subversion for our company, the mandatory
> requirements were reliability and availability. We have development
> offices in several countries and require 24-hour access. I waited until
> FSFS was available and stable and have since begun pilot testing.
>
> FSFS with rsync is indeed the way to go. We use rsync to backup our
> repositories being careful to backup db/current first. The backup cron
> job is amazingly fast - maybe a few seconds every hour, so we get highly
> reliable backups with essentially no impact on the server. We copy to a
> standby server (to be located in a disaster recovery center), so should
> the main server fail, or we lose network connectivity, we can be up and
> running again in under an hour.
Smart, and done with only packages, Subversion and rsync only.
One thing that struck me is that backing up the db/current first is no
guarantee?
A commit initiated just before backup-time must result in a corrupted backup,
virtually every time:
db/current is written (by svn doing "commit zero")
The backup start and backs up db/current first. The same backup procedure then
proceed (e.g. by running rsync) for the rest of the files.
But when rsync started commit zero is still running and writes to other files
which should correspond to db/current. We can have no control over which
files are being read by rsync earlier than commit zero updated them, and
which later.
So it is hard to imagine how commit zero could be correctly backed up.
To me it seems a better procedure would be to back up db/current first, then
_wait_ until commit zero surely is completed (with plenty of margin added)
and then run rsync. This way we can be sure that the update of all files
corresponding to commit zero is completed.
It does not matter if another commit has started while we wait as the files
written by commit zero will not be changed and so we would have a backup with
integrity (and possibly 'unreferred' files belonging to commits done before
our backup were completed).
Have I understood this correctly?
- - -
Another matter is - which is a OS-thing - what happens if a write-request is
being done to a file while another process reads from it. Does e.g. UNIX
automatically take care of some locking? If so it must mean that it is
"wrong" to write to any part of a file while it is being read?
Or can we risk that db/current is being read by the backup procedure - and
then changed by svn while we read it it, resulting in corruption?
- - -
Once "The server is down for maintenance, please come back soon..." was good
enough... :-)
Soren 'Frank'
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 2 21:20:02 2005