subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nico Kadel-Garcia <nka...@gmail.com>
Subject Re: UNS: Re: Taking mirror Backup of SVN Repos through 3rd Party Software
Date Fri, 01 Jul 2011 01:46:19 GMT
On Thu, Jun 30, 2011 at 12:35 PM, Les Mikesell <lesmikesell@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.)

Mime
View raw message