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

Re: Support for filesystem snapshots (?)

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 2 Aug 2010 18:17:39 +0200

On Mon, Aug 02, 2010 at 11:38:30AM -0400, Vallon, Justin wrote:
> In the svn book, http://svnbook.red-bean.com/en/1.1/ch05s03.html#svn-ch-5-sect-3.6 on "Repository Backup" describes some backup methods - hot copy, etc. Given that enterprise-level filesystems generally support filesystem snapshots, what is SVN's position on whether such snapshots are sufficient for backups?
> Suppose our criteria is that we unplug the network cable between the writer (svn commit) and the filesystem. If unplugging the network cable could yield a repository that is corrupt, then doesn't that mean that there are failure modes where the repository is corrupted? If a filesystem insures that the snapshots behave in this way (as if you disconnect the network cable, make an instant copy, then reconnect), it would seem to imply that these volume-level snapshots would result in a consistent view. If the snapshots are not consistent, then atomicity is not being insured (somewhere between application, client o/s, server o/s, disk controller, media).
> My follow up is whether the svn book could include a word about whether it blesses (or not) this form of backup?

By chance, this very topic was discussed earlier today.
See http://svn.haxx.se/users/archive-2010-08/0019.shtml

"Use 'svnadmin hotcopy' to create a copy of a repository that is consistent
from Subversion's point of view. There is no other repository copying
tool that can guarantee a consistent repository snapshot."

This holds true for filesystem-level snapshots.
The atomicity of Subversion's commits only exists from the application's
point of view.

Received on 2010-08-02 18:18:22 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.