>>>>> "Samay" == Samay <getafix123@hotmail.com> writes:
>> My management is cautious about backups (having been burned by
>> database corruption in the past). So I need to be able to do at
>> least some of my backups simply by turning Subversion off (no
>> writes to the repository internals), then copy the repository
>> data, then turn it back on. ...
Samay> This is what we do for backup ... a) overnight filesystem
Samay> backup ... with FSFS type repos, however, it is error prone if
Samay> there is somehow any inconsistency with in the repos itself.
Also, if commits are taking place at this time, then this is known to
be a bad idea (with either type of repository).
Samay> b) overnight "svnadmin dump" for each repository. this also
Samay> provides us a simple check that repos is healthy if we can
Samay> dump all revisions. c) weekly restore "svnadmin load" for all
Samay> repos onto a test server for last known backup ... to confirm
Samay> that backup & restore both processes conform to our BCP
Samay> requirement.
Samay> during a & b above, SVN server (using apache & mod_dav_svn) is
Samay> still operational (albeit tad slower!). If yours are BDB
Samay> backend repos then (a) may not be a reliable option, but (b)
Samay> should work irrespective if repos are live or offline.
No, (a) is unreliable for all repository types, I believe that's
documented. That's why svnadmin hotcopy exists.
svndump is an interesting option -- thanks for the suggestion. But
it's very slow. I forgot how long it took when I tried it --
certainly a lot longer than a file system copy of the repository
filesystem.
And in any case, I'm not going to be allowed to rely exclusively on
tools that run with the repository enabled. So I still need an answer
to the original question: what do I do to V1.2.3 svnserve, with FSFS,
to ensure that nothing is writing to the repository internal file
data?
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 6 23:45:06 2006