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

Re: UNS: Re: Taking mirror Backup of SVN Repos through 3rd Party Software

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Thu, 30 Jun 2011 21:46:19 -0400

On Thu, Jun 30, 2011 at 12:35 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On 6/30/2011 10:46 AM, Andreas Krey wrote:
>> On Thu, 30 Jun 2011 10:09:43 +0000, Les Mikesell wrote:
>> ...
>>> A backup made in an inconsistent state should exactly resemble the disk
>>> files if the system lost power or crashed for another reason at that
>>> point.
>> No, backups can contain inconsistencies that are impossible to
>> create with a server crash. When, say, the svn server writes
>> file A and B with a synchonization point in between, it is
>> still possible for a backup to contain the old A and the new B.
>> This can't happen in a crashed filesystem.
> I think you are being way too optimistic about real-world filesystems and
> disk and controller caches.  It is possible to make a system that behaves
> with the ideal behavior you describe - and maybe many do in terms of the
> filenames and directory entries.  But I'd guess that the majority don't
> really get this right with the data contents of those files.

Not without work. I've recently had an unfortunately short discussion
about the risks of using the Linux "dump" program as a backup
technology for systems including databases, such as the FSFS in
Subversion. This is prey to exactly the sort of "In cache but not yet
written to disk" problems that have been discussed elsewhere. And it's
apparently even riskier with ext4 (wich is a very useful filesystem
for large Subversion repositories with millions of auto-commits.)
Received on 2011-07-01 17:13:33 CEST

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.