On Friday 02 March 2007 04:46, Lutz Frommberger wrote:
> Is there a need for dumping the contents of a FSFS repository prior
> to an incremental backup? In other words: Is it possible that my
> backup mechanism will bring me to an inconsistent state when just
> backing up the repository "as is"?
The way I see it with any repository, your backup mechanism will
never modify any files that it is backing up, therefore you will
never be brought "to an inconsistent state" by backing up with the
normal backup utility.
The problem is actually whether your regular backup is guaranteed to
contain a valid backup of the repos. I don't think they guarantee
that, but there is documentation on what order to copy the files to
guarantee valid backup.
The book wrote:
> In the case of Berkeley DB, Sleepycat documents describe a certain
> order in which database files can be copied that will guarantee a
> valid backup copy. And a similar ordering exists for FSFS data.
> Better still, you don't have to implement these algorithms yourself,
> because the Subversion development team has already done so. The
> hot-backup.py script is found in the tools/backup/ directory of the
> Subversion source distribution. Given a repository path and a backup
> location, hot-backup.py—which is really just a more intelligent
> wrapper around the svnadmin hotcopy command—will perform the
> necessary steps for backing up your live repository—without
> requiring that you bar public repository access at all—and then will
> clean out the dead Berkeley log files from your live repository.
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.reposadmin.maint.backup
The bottom line is that I _would_ make subversion backups using the
subversion backup methods as documented rather than rely on my
normal filesystem backup.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 2 22:36:31 2007