What is a safe way of backing up a shared bzr repository

Hans Fangohr h.fangohr at soton.ac.uk
Mon Nov 19 11:04:42 GMT 2007


Dear all,

many thanks to all that have responded to my question.

I try to summarise the replies (but be aware that I have just started
learning about bzr; so this may be inaccurate)

- if I just copy the file structure (i.e. the .bzr directories), I
   could get an inconsistent copy if somebody is commiting while I copy.
   (Not an option for me).

- I could 'lock' the repository with the script provided by John
   (thanks!), then make the copy. This is a 'clean' solution in that it
   always works (in the sense of creating a consistent copy) but if I
   ever have to use the backup, I need to unlock it first.

- I could create a clone and create a copy of this. (No idea what a
   clone is but that can probably be learned from the bzr documentation).

- I could copy the files in the right order (not really something I
   would like to do unless the bzr team provides the script for this).

So it seems there are options to create a safe backup. However, I
agree with Vincent: bzr should really provide a simple script (and a
short section in the manual) that provides exactly this
functionality. Ideally, this would create a (consistent) copy of the
repository in a different place. Which of the methods listed above
would be used is mostly irrelevant to users like myself. As a former
svn user, I would look for a script called hot-backup.py -- but that
is of course a matter of taste and history.

What is the recommended way to suggest this feature?

Many thanks,

Hans

>>>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:
>
> <snip/>
>
>    john> The only downside to this is that you've backed up a
>    john> locked repository, so the first thing you need to do is
>    john> "bzr break-lock" on it when restoring. But it is a
>    john> decent way to do it. And break-lock is a rather small
>    john> thing. (it is similar to making the backup readonly,
>    john> which is a good thing.
>
>    john> Another way is to keep an alternate repository and
>    john> clone all branches into it, and then back that
>    john> up. Since that one is guaranteed to be offline. And we
>    john> guarantee consistency (even if push/pull is interrupted
>    john> the data stays consistent on disk). There would also be
>    john> an order that you could copy the data and get
>    john> consistent results (copy all the branches, and then the
>    john> repository, starting with revisions, then inventory,
>    john> then knits/*, and copying .kndx before .knit).
>
>    john> It wouldn't be hard to write a script that built up the
>    john> filenames in the right order. If you go in that order,
>    john> you will always have consistent data, even in the
>    john> middle of a push or pull. At worst, you just end up
>    john> with some unreferenced data sitting around.
>
> That screams "supported in core" to my ears.
>
> So that both points above can be addressed:
>
> - creating a read-only backup (or not)
>
> - saving files in order to allow concurrent updates while
>  providing a usable backup
>
> bzr branch already provide a way to backup a branch and a working
> tree can be backed up like any tree, so providing a way to backup
> a shared repository seems to be the only missing bit.
>
>     Vincent
>
>
>
>

--
Hans Fangohr

School of Engineering Sciences 
University of Southampton 
Phone: +44 (0) 238059 8345

Email: fangohr at soton.ac.uk
http://www.soton.ac.uk/~fangohr







More information about the bazaar mailing list