On 8/2/2010 11:17 AM, Stefan Sperling wrote:
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
Quote:
"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.
Are there any svnadmin commands that could quiesce/lock the repository
in a consistent state for the duration of a filesystem snapshot - or if
not, could that be added as an enhancement?
--
Les Mikesell
lesmikes...@gmail.com
