docs/89900: [PATCH] new text on backup strategies for Handbook

[Lowell Gilbert]

>Number:         89900
>Category:       docs
>Synopsis:       [PATCH] new text on backup strategies for Handbook
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec 03 22:20:02 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Lowell Gilbert
>Release:        FreeBSD 6.0-STABLE i386
>Organization:
n/a
>Environment:
System: FreeBSD be-well.ilk.org 6.0-STABLE FreeBSD 6.0-STABLE #5: Tue Nov 29 19:56:53 EST 2005 root at be-well.ilk.org:/usr/src/sys/i386/compile/BE-WELL6 i386


	
>Description:

This is new text discussing how to choose backup strategies.

>How-To-Repeat:
n/a

>Fix:

--- en_US.ISO8859-1/books/handbook/disks/chapter.sgml.ORIG	Fri Aug  5 15:06:20 2005
+++ en_US.ISO8859-1/books/handbook/disks/chapter.sgml	Sat Dec  3 16:03:31 2005
@@ -2269,8 +2269,103 @@
 	restore it, even if you have not asked it to!</para>
     </sect2>
   </sect1>
 
+  <sect1 id="backup-strategies">
+    <title>Backup Strategies</title>
+
+        <para>  
+	The first requirement in devising a backup plan is to make sure that all of the
+	following problems are covered:
+	<itemizedlist>
+	  <listitem>
+	    <para>
+	      disk failure
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      accidental file deletion
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <para>
+	      random file corruption
+	    </para>
+	  </listitem>
+	  <listitem>
+	    <para>
+  	      complete machine destruction (e.g., fire) including destruction of any on-site backups
+	    </para>
+	  </listitem>
+	</itemizedlist></para>
+
+	<para>It is perfectly possible that some systems will be best served by
+	having each of these problems covered by a completely different
+	technique.  Except for strictly personal systems with very low-value
+	data, it is unlikely that one technique would cover all of them.</para>
+
+	<para>Some of the techniques in the toolbox are:</para>
+	  <itemizedlist>
+	    <listitem>
+	      <para>archives of the whole system, backed up onto permanent media
+		offsite.  This actually provides protection against all of the
+		possible problems listed above, but is slow and inconvenient to
+		restore from.  You can keep copies of the backups onsite and/or
+		online, but there will still be inconveniences in restoring files,
+		especially for non-privileged users.</para>
+	    </listitem>
+
+	    <listitem>
+	      <para>filesystem snapshots.  This is really only helpful in the
+	        accidental file deletion scenario, but it can be
+		<emphasis>very</emphasis> helpful
+	        in that case, and is quick and easy to deal with.</para>
+	    </listitem>
+
+	    <listitem>
+
+	      <para> copies of whole filesystems and/or disks.  [for example,
+	      	periodic rsync of the whole machine] This is generally most
+	      	useful in networks with unique requirements.  For general
+	      	protection against disk failure, it is usually inferior to
+	      	<acronym>RAID</acronym>.  For restoring accidentally deleted
+	      	files, it can be comparable to <acronym>UFS</acronym>
+	      	snapshots, but that depends on your preferences.</para>
+
+	    </listitem>
+
+	    <listitem>
+
+	      <para><acronym>RAID</acronym>.  Minimizes or avoids downtime
+	        when a disk fails.  At the expense of having to deal with disk
+	        failures more often (because you have more disks), albeit at a
+	        much lower urgency.</para>
+
+	    </listitem>
+
+	    <listitem>
+
+	      <para>checking fingerprints of files.  The
+	        &man.mtree.8;
+		program is very useful for this.  Although it is not a backup
+		technique, it helps guarantee that you will notice when you need
+		to resort to your backups.  This is particularly important for
+		offline backups, and should be checked periodically.
+
+	    </listitem>
+    	  </itemizedlist>
+
+	<para>It is quite easy to come up with even more techniques, many of them
+	  variations on the ones listed above.  Specialized requirements will
+	  usually lead to specialized techniques (for example, backing up a live
+	  database usually requires a method particular to the database
+	  software as an intermediate step).  The important thing is to know
+	  what dangers you want to protect against, and how you will handle
+	  each.</para>
+
+  </sect1>
+
   <sect1 id="backup-basics">
     <title>Backup Basics</title>
 
     <para>The three major backup programs are
>Release-Note:
>Audit-Trail:
>Unformatted: