← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/admin-guide/backup.txt

  • Committer: Neil Martinsen-Burrell
  • Date: 2009-12-16 02:03:31 UTC
  • mto: This revision was merged to the branch mainline in revision 4908.
  • Revision ID: nmb@wartburg.edu-20091216020331-0rbid4b635r82z4d
completely rework the part about filesystem backups in light of JAMs comments about concurrent access

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/admin-guide/backup.txt
10
10
------------------
11
11
 
12
12
Bazaar transactions are atomic in the sense that the disk format is such that
13
 
it is in a valid state at all times.  If a Bazaar file is copied while some
14
 
process is in the midst of writing to that file, then that content is not
15
 
referred to by the other on-disk structures until the data is completely
16
 
written.  As such, it should be safe to copy Bazaar branches using filesystem
17
 
tools at any time.  The only possible drawback to doing this is that the
18
 
copied files may contain a small amount of additional content that isn't used
19
 
elsewhere in the branch.  A later copy made after that change has fully
20
 
completed would contain that whole change.  Bazaar's disk formats are not
21
 
specifically tuned to be kind to tape backup methods that prefer to append to
22
 
existing files, but they should be reasonably friendly in that regard.  (In
23
 
many cases, they do only append to files that already exist.)
24
 
 
25
 
Although Bazaar has a valid on-disk state at all times, backing up a live
26
 
branch can have unintended human interactions.  In particular, a commit that
27
 
happens during the course of a backup may not be present in the backup that
28
 
was running when the commit was made.  This can be a problem if developers
29
 
delete their local branches on the assumption that the branch located on the
30
 
server is backed up.  In the event of a failure on the server before the next
31
 
backup that starts strictly *after* the commit finishes, then that commit may
32
 
be lost when restoring from the backup.  To avoid this possibility entirely,
33
 
it is necessary to take the branch offline while doing the backup or to use
34
 
a backup scheme based on Bazaar's branches: `Bound Branch Backups`_
 
13
it is in a valid state at any instant in time.  However, for a backup process
 
14
that takes a finite amount of time to complete, it is possible to have
 
15
inconsistencies between different on-disk structures when backing up a live
 
16
branch or repository.  (Bazaar itself manages this concurrency issue by only
 
17
*reading* those structures in a well-defined order.)  Tools such as LVM that
 
18
allow instantaneous snapshots of the contents of a disk can be used to take
 
19
filesystem backups of live Bazaar branches and repositories.
 
20
 
 
21
For other backup methods, it is necessary to take the branch or repository
 
22
offline while the backup is being done in order to guarantee consistency
 
23
between the various files that comprise a Bazaar branch's history.  This
 
24
requirement can be alleviated by using Bazaar as its own backup client,
 
25
since it follows an order for reading that is designed to manage concurrent
 
26
access (see the next section for details).  Depending on the different
 
27
access methods that are being used for a branch, there are different ways to
 
28
take the branch "offline".  For ``bzr+ssh://`` access, it is possible to
 
29
temporarily change the filesystem permissions to prevent write access from
 
30
any users.  For ``http://`` access, changing permissions, shutting down
 
31
the HTTP server or switching the server to a separate configuration that
 
32
disallows access are all possible ways to take a branch offline for backup.  
 
33
Finally, for direct filesystem access, it is necessary to make the branch
 
34
directories un-writable.
 
35
 
 
36
Because this sort of downtime can be very disruptive, we strongly encourage
 
37
using Bazaar itself as a backup client, where branches are copied and
 
38
updated using Bazaar directly.
35
39
 
36
40
 
37
41
Bazaar as its own backup
172
176
backup data, so we can't cover them all here.  What we will say is that
173
177
restoring the contents of the ``/srv/bzr`` directory completely will restore
174
178
all branches stored there to their state at the time of the backup (see
175
 
`Filesystem Backups`_ for possible human-level concerns on backing up live branches.)  For
 
179
`Filesystem Backups`_ for concerns on backing up live branches.)  For
176
180
example, if the backups were mounted at ``/mnt/backup/bzr`` then we could
177
181
restore using simply::
178
182