Re: Backing up - is db/current written last?

[Soren 'Frank' Munch <sm...@u5.com>]

Daniel wrote:
> db/current is written last by svn.
>
> Also, fsfs is still transactional, so the commits are stored in the
> transaction directory until they are moved into place, and *then*
> db/current is updated.

Great! In that case db/current _must_ point to a set of valid file and there's 
no reason to delay rsync.

> Thus, at worst, you will end up with a backup that does not include the
> last revision, *not* a corrupt repository.

I figured out this would be the worst case if db/current was not written last.

- - -

Well, the bottom line must be that grabbing the db/current first leads to 
correct backups of the commit that wrote it. I assume is what hot-backup.py 
is doing but I am one of those who would like to keep up an illusion that I 
know what goes on and the raw "(s)cp db/current ..." and subsequent rsync is 
very appealing.

Thanks for the information from the front-line!

Soren 'Frank'

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Backing up - is db/current written last?

[Daniel Berlin <db...@dberlin.org>]

On Mon, 2005-07-04 at 14:02 +0200, Jacob Atzen wrote:
> On Sat, Jul 02, 2005 at 10:32:37PM -0400, Daniel Berlin wrote:
> > Rsync builds the list of files first, *then* transfers them.
> > 
> > Thus, the case to worry about is if it transfers db/current *after*
> > another commit has occurred during the rsync (and the newly created
> > revision file is thus not in rsync's list of files), and then you have a
> > db/current that refers to something that wasn't transferred.
> > 
> > Hence the reason to transfer it first.
> 
> Why not use svnadmin hotcopy[1] and stop worrying instead?

Because it takes time to copy 6.9 gig around to a temporary directory :)



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Backing up - is db/current written last?

[Jacob Atzen <ja...@aub.dk>]

On Sat, Jul 02, 2005 at 10:32:37PM -0400, Daniel Berlin wrote:
> Rsync builds the list of files first, *then* transfers them.
> 
> Thus, the case to worry about is if it transfers db/current *after*
> another commit has occurred during the rsync (and the newly created
> revision file is thus not in rsync's list of files), and then you have a
> db/current that refers to something that wasn't transferred.
> 
> Hence the reason to transfer it first.

Why not use svnadmin hotcopy[1] and stop worrying instead? That is, do a
hotcopy on the repository server and then rsync the copy to the backup
server. I also like to keep a dump of every single revision that goes
into the repository, just in case. I do this by having a post-commit
hook that simply dumps the latest delta into a file on each commit like
this:

$SVNADMIN dump "$REPOS" --incremental --revision "$REV" | bzip2 >
"$BACKUPDIR/$REPOSNAME/incremental/$REPOSNAME.$REV.dump.bz2"

[1]: <http://svnbook.red-bean.com/en/1.1/re33.html>

-- 
Cheers,
- Jacob Atzen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Backing up - is db/current written last?

[Daniel Berlin <db...@dberlin.org>]

On Sun, 2005-07-03 at 05:01 +0700, Soren 'Frank' Munch wrote:
> Daniel wrote:
> > db/current is written last by svn.
> >
> > Also, fsfs is still transactional, so the commits are stored in the
> > transaction directory until they are moved into place, and *then*
> > db/current is updated.
> 
> Great! In that case db/current _must_ point to a set of valid file and there's 
> no reason to delay rsync.
Rsync builds the list of files first, *then* transfers them.

Thus, the case to worry about is if it transfers db/current *after*
another commit has occurred during the rsync (and the newly created
revision file is thus not in rsync's list of files), and then you have a
db/current that refers to something that wasn't transferred.

Hence the reason to transfer it first.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org