Philip Martin <philip.martin_at_wandisco.com> wrote on 06/30/2011 11:53:54
AM:
> > I know using traditional server backup software has never been
> > recommended on fsfs repositories. However, since the server
> > never rewrote any files after the transaction was finalized, the
> > only previous issues with using a snapshot based backup mechanism
> > would be that the current file was out of sync with reality. This
> > could be easily fixed, by manually modifying the current file
> > to reference the previous revision number if needed.
>
> There are problems simply copying a live repository:
>
> - since 1.6, if FSFS rep-sharing is not disabled there is the problem
> of copying the rep-sharing SQLite database.
rep-cache.db? I thought that could be easily regenerated. Is there
another .db file I missed?
> - since 1.2, if Subversion file locking is not disabled there is the
> problem of copying the locks directory:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3750
Locks are transient, so I can live with them not being consistent,
as long as their inconsistency doesn't make the whole repository
unusable.
> > Daniel mentioned this is no longer the case since revprop packing
> > using a sqlite database is not guaranteed to be consistent
> > while it is open.
>
> Not sure what you mean. The restriction is that it is not valid to
> simply copy an SQLite database file while it being written.
>
> > In my opinion this is a huge regression from
> > previous functionality. Using hotcopy or svnsync is not practical
> > for larger environments.
>
> I suppose incremental hotcopy might help if it were implemented:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3815
> We would have to fix 3750 first.
>
> > On a similar note, could a server or application crash now leave
> > a 1.7 repository in an inconsistent and unrecoverable state?
>
> Not sure what you are thinking of here, but it's perfectly OK to
> interrupt SQLite in the middle of a transaction.
Understood, but I want to make sure that a corrupted SQLite db
doesn't make the whole past history of the repository unusable.
For example, if the server dies a horrible death in the middle
of updating r100, I'd really hope it can't easily make r1-r99
unusable in the process. Yes, you should have redundant copies
available elsewhere, but I'm thinking worse case scenario when
your multiple levels of other protections have also failed...
Kevin R.
Received on 2011-06-30 19:20:55 CEST