<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>