On Wed, Jun 1, 2016 at 11:55 AM, Michael Schwager <mschwage_at_gmail.com>
wrote:
> Thanks Matt. To your point,
>
> > my collection of backups probably does have some corrupt repo trees...
>
> that is really what I'm driving at. The RAID, offsite, number of backups
> (nightly in our case), and testing is all covered. In other words, I can
> mitigate the effects of failure with all those tried-and-true sysadmin
> techniques.
>
> The essence of my question drives to Subversion specifically. I don't want
> *any* unknown corrupt Subversion repo backups lying around. Meaning I don't
> trust a shotgun approach, where I do enough of them so one is bound to be
> good. I'm looking for a precision approach, where I can be reasonably
> assured that the techniques I'm doing will provide me with a recoverable
> repo at any chosen backup point. ("reasonably" defined as "as close to 100%
> as I can get)
>
> Because if it's Thursday, and Wednesday night's repo backup is the one I
> need, I don't want to have to report back that it's corrupt and the best I
> can do is Tuesday.
>
Personally, I think it is overkill to keep a bunch of backups. With the
exception of revision properties, history is immutable so it is not like
someone can delete something where you would need an older backup to find
it.
The best backup option is svnadmin hotcopy. That is the only backup option
that gets all of the data in the repository. dump and svnsync both do not
backup locks or hook scripts.
As of 1.8 I believe, svnadmin hotcopy supports an --incremental option so
that you can also do these backups very fast. I would recommend doing an
--incremental hotcopy from a post-commit hook script so that you always
have a proper backup. You can then periodically take dumps or perform
verify on your hotcopy or do an rsync to maintain some offsite backup etc.
So do an incremental hotcopy via post-commit hook and do a nightly verify
of the hotcopy if you are paranoid. SVN repositories do not suddenly
become corrupt though. The data is only written once, so unless the disk
drive starts losing bits once it is good it stays good. Only a newer
commit can come in that is somehow "corrupt". That said, corrupt
repositories are really rare.
Mark
Received on 2016-06-01 18:22:47 CEST