[svnbook commit] r2717 - trunk/src/en/book

cmpilato noreply at red-bean.com
Tue Feb 27 00:59:35 CST 2007


Author: cmpilato
Date: Tue Feb 27 00:59:34 2007
New Revision: 2717

Modified:
   trunk/src/en/book/ch05-repository-admin.xml

Log:
* src/en/book/ch05-repository-admin.xml
  Finish the last review item from Ben's feedback on chapter 5.


Modified: trunk/src/en/book/ch05-repository-admin.xml
==============================================================================
--- trunk/src/en/book/ch05-repository-admin.xml	(original)
+++ trunk/src/en/book/ch05-repository-admin.xml	Tue Feb 27 00:59:34 2007
@@ -1983,11 +1983,9 @@
         that triggered the hook.  Or you might have a script that runs
         nightly to append dump file data for all the revisions that
         were added to the repository since the last time the script
-        ran.  Used like this, <command>svnadmin</command>'s
-        <literal>dump</literal> and <literal>load</literal> commands
-        can be a valuable means by which to backup changes to your
-        repository over time in case of a system crash or some other
-        catastrophic event.</para>
+        ran.  Used like this, <command>svnadmin dump</command> can be
+        one way to backup changes to your repository over time in case
+        of a system crash or some other catastrophic event.</para>
 
       <para>The dump format can also be used to merge the contents of
         several different repositories into a single repository.  By
@@ -2719,13 +2717,6 @@
         repository data that has changed since the previous
         backup.</para>
 
-      <para>We discussed in <xref
-        linkend="svn.reposadmin.maint.migrate" /> how to use
-        <command>svnadmin dump --incremental</command> to perform an
-        incremental backup based on the repository dump format.  We'll
-        not spend much time discussing that method any further
-        here.</para>
-
       <para>As far as full backups go, the naive approach might seem
         like a sane one, but unless you temporarily disable all other
         access to your repository, simply doing a recursive directory
@@ -2779,17 +2770,41 @@
         cause it to run nightly (or at whatever granularity of Time
         you deem safe enough for you).</para>
 
-      <para>There are advantages and disadvantages to both backup
-        types.  The easiest is by far the full backup, which will
-        always result in a perfect working replica of your repository.
-        Should something bad happen to your live repository, you can
-        restore from the backup with a simple recursive directory
-        copy.  Unfortunately, if you are maintaining multiple backups
-        of your repository, these full copies will each eat up just as
-        much disk space as your live repository.  Incremental backups,
-        by contrast, tend to be quicker to generate and smaller to
-        store.  But the restoration process can be a pain, often
-        involving applying multiple incremental backups.</para>
+      <para>Some administrators use a different backup mechanism built
+        around generating and storing repository dump data.  We
+        described in <xref linkend="svn.reposadmin.maint.migrate" />
+        how to use <command>svnadmin dump --incremental</command> to
+        perform an incremental backup of a given revision or range of
+        revisions.  And of course, there is a full backup variation of
+        this achieved by omitting the <option>--incremental</option>
+        option to that command.  There is some value in these methods
+        in that the format of your backed-up information is
+        flexible—it's not tied to a particular platform,
+        versioned filesystem type, or release of Subversion or
+        Berkeley DB.  But that flexibility comes at a cost, namely
+        that restoring that data can take a long time—longer
+        with each new revision committed to your repository.  Also, as
+        is the case with so many of the various backup methods,
+        revision property changes made to already-backed-up revisions
+        won't get picked up by a non-overlapping, incremental dump
+        generation.  For these reasons, we recommend against relying
+        solely on dump-based backup approaches.</para>
+
+      <para>As you can see, each of the various backup types and
+        methods has its advantages and disadvantages.  The easiest is
+        by far the full hot backup, which will always result in a
+        perfect working replica of your repository.  Should something
+        bad happen to your live repository, you can restore from the
+        backup with a simple recursive directory copy.  Unfortunately,
+        if you are maintaining multiple backups of your repository,
+        these full copies will each eat up just as much disk space as
+        your live repository.  Incremental backups, by contrast, tend
+        to be quicker to generate and smaller to store.  But the
+        restoration process can be a pain, often involving applying
+        multiple incremental backups.  And other methods have their
+        own peculiarities.  Administators need to find the balance
+        between the cost of making the backup and the cost of
+        restoring it.</para>
 
       <para>The <command>svnsync</command> program (see <xref
         linkend="svn.reposadmin.maint.replication" />) actually
@@ -2826,26 +2841,26 @@
         backup their entire repository, say, every time a commit
         occurred.  However, assuming that a given repository has some
         other redundancy mechanism in place with relatively fine
-        granularity (like per-commit emails), a hot backup of the
-        database might be something that a repository administrator
-        would want to include as part of a system-wide nightly backup.
-        For many repositories, archived commit emails provide
-        sufficient redundancy as restoration sources, at least for the
-        most recent few commits (and where the files being modified
-        are human-readable).  But it's your data—protect it as
-        much as you'd like.</para>
+        granularity (like per-commit emails or incremental dumps), a
+        hot backup of the database might be something that a
+        repository administrator would want to include as part of a
+        system-wide nightly backup.  It's your data—protect it
+        as much as you'd like.</para>
             
       <para>Often, the best approach to repository backups is a
-        diversified one.  You can leverage combinations of full and
-        incremental backups, plus archives of commit emails.  The
-        Subversion developers, for example, back up the Subversion
-        source code repository nightly, keep multiple archives of all
-        the commit and property change notification emails, and almost
-        certainly have the repository mirrored by various folks using
-        <command>svnsync</command>.  Your solution might be similar,
-        but should be catered to your needs and that delicate balance
-        of convenience with paranoia.  And while all of this might not
-        save your hardware from the iron fist of Fate,
+        diversified one which leverages combinations of the methods
+        described here.  The Subversion developers, for example, back
+        up the Subversion source code repository nightly using
+        <command>hot-backup.py</command> and an offsite
+        <command>rsync</command> of those full backups; keep multiple
+        archives of all the commit and property change notification
+        emails; and have repository mirrors maintained by various
+        volunteers using <command>svnsync</command>.  Your solution
+        might be similar, but should be catered to your needs and that
+        delicate balance of convenience with paranoia.  And whatever
+        you do, validate your backups from time to time—what
+        good is a spare tire that has a hole in it?  While all of this
+        might not save your hardware from the iron fist of Fate,
         <footnote>
           <para>You know—the collective term for all of her
             <quote>fickle fingers</quote>.</para>




More information about the svnbook-dev mailing list