subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hett <ste...@egosoft.com>
Subject Re: Creating and Verifying a Reliable backup
Date Wed, 01 Jun 2016 16:20:50 GMT
On 6/1/2016 4:58 PM, Michael Schwager wrote:
> Hello,
> We are very paranoid about our Subversion repo, notwithstanding the 
> fact that the previous sysadmin didn't back it up. But that's another 
> story. Now I'm here at my job, I've inherited the repo admin duties, 
> and I want to back it up reliably. If we lose it, we're all out of work.
>
> My question is: How do I back it up reliably, and verify it so that I 
> can deliver a 100% recovery guarantee to my boss? I have Subversion 
> 1.8.4 on a CentOS 6.3 server, and Tortoise SVN 1.8.11 on Windows 7 
> clients.
>
> I am thinking to do both an svn hotcopy to one directory, and an rsync 
> to another. The svn hotcopy will give me a backup that I'm pretty sure 
> is reliable (see Notes below). Assuming httpd is down and I can 
> guarantee that I am the only person who will be logged into the SVN 
> server, can I expect with 99.9% surety that the svn repos are quiescent?
>
> Thanks.
> -- 
> -Mike Schwager
>
> Notes:
>
> We're a little worried about svn hotcopy; we ran into a bug that came 
> about under 1.8 when working with older repos; the hotcopy exits with 
> the following error:
>
> svnadmin: E200002: Serialized hash missing terminator
As far as I can tell this indicates a problem in the repository you are 
trying to hotcopy from. Run svnadmin verify on that to get details where 
the corruption might be located and resolve that (if possible).
>
> I have compiled subversion-1.9.4 on the server under 
> /opt/subversion-1.9.4. If I run that version of svn hotcopy, it 
> appears to work and svnverify exits successfully. But if I look at all 
> the files under both the original and the hotcopy on one of our repos, 
> I find that a file is missing: repos2/db/rev-prop-atomics.shm . That's 
> probably ok, but still- how do we know the latest hotcopy, and 
> hotcopies of the future, are and will remain 100% bug-free?
To ensure the integrity of a backup close to 100% I go the fail safe way:
1. svnadmin verify to ensure the current repository is in a good state 
(if there are errors/issues resolve them)
2. svnadmin dump to dump the current repository
3. svnadmin load the dump into a fresh repository
4. svnadmin dump the newly loaded repository
5. compare the first and the last dump
6. run svnadmin verify on the loaded dump to en
If both dumps are equal, I'm certain enough the integrity is given. 
(Note: this implies the same fsfs-format as well as the same server 
version for the svnadmin calls).

This process however only works when you can take down access to a 
repository completely. Otherwise svnadmin hotcopy would be my choice 
too. In addition setting up a mirror which is kept in sync using svnsync 
is also a reasonable measurement to further increase the reliability of 
an SVN repository IMO.

However, it's also utterly vital to keep the server up to date with 
patch releases, so you are not suffering flaws/bugs which could impact 
the server side. Some examples for issues which have been fixed a long 
time ago and are not fixed in 1.8.4 (but might be relevant for your case 
of ensuring data correctness/integrity and a reliable backup system):
1.8.5: hotcopy: fix hotcopy losing revprop files in packed repos (issue 
#4448)
1.8.9: svnadmin dump: don't let invalid mergeinfo stop dump
1.8.9: svnrdump load: fix crash when svn:* normalization (issue #4490)
1.8.9: mod_dav_svn: detect out of dateness correctly during commit 
(issue #4480)
1.8.11: disable revprop caching feature due to cache invalidation problems
1.8.13: svnadmin load: tolerate invalid mergeinfo at r0 (issue #4476)
1.8.13: svnadmin load: strip references to r1 from mergeinfo (issue #4538)
1.8.13: svnsync: strip any r0 references from mergeinfo (issue #4476)
1.8.14: prevent possible repository corruption on power/disk failures
1.8.16: dump: don't write broken dump files in some ambiguously encoded 
fsfs repositories (issue #4554)

If you feel very conservative you might also wanna consider staying at 
the old stable version for the server (sidenote: even with the server 
running at 1.8, clients could use svn 1.9), if you don't need 
bugfixes/improvements of the current stable svn version. While the 
current stable build (1.9.4) contains fixes for issues still present in 
1.8.16 and also delivers new features, it also contains 
features/improvements which by the nature of software lifecycles have 
not been tested as long in the wild as the features present in 1.8.16. 
So one might argue that from the code integrity point of view, 1.8.16 
would be the safer choice to go.

If you are compiling your own server, be sure to keep the dependencies 
used also up to date.

-- 
Regards,
Stefan Hett


Mime
View raw message