kmradke_at_rockwellcollins.com wrote on Thu, Jun 30, 2011 at 09:06:28 -0500:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote on 06/30/2011 07:35:36 AM:
> > I'm going to say this even more clearly:
> >
> > If you backup a repository by copying its files while a server is
> > running, the backup may be created corrupted.
> >
> > http://subversion.apache.org/docs/release-notes/1.7#single-db (sic)
>
> This does not seem point to any additional warnings about the server
> side yet (only the client)...
>
Read the attached issue. FSFS on 1.7 is affected --- specifically,
revprops.db, which contains the only copy of revprops of packed
revisions.
> I realize regular backup software was never truly endorsed, but in
> the past, the "corruption" could always be rolled back to the last
> valid commit, since the server never modified files once they were
> created. You could lose the last commit and need to manually
> perform surgery on the "current" file, but the repo would still be
> functional. Since backups are considered a snapshot in time this
> isn't a big problem since it just moves the timeframe of the
> backup to the previous commit.
>
> To be honest, both hotcopy and svnsync are way too slow for
> any server of appreciable size. If 1.7 is designed to modify
> existing files in place on the server, potentially rendering
> snapshot backups non repairable, it would be a huge regression.
>
Per above, it is designed this way. Could you raise this issue on dev@ please?
Would adding an 'svnadmin create'-time knob that says "Pack only
revision shards but not revision property shards" solve your issue?
> Kevin R.
Received on 2011-06-30 16:22:50 CEST