svn commit: r43696 - head/en_US.ISO8859-1/books/handbook/disks
Dru Lavigne
dru at FreeBSD.org
Thu Jan 30 18:17:32 UTC 2014
Author: dru
Date: Thu Jan 30 18:17:31 2014
New Revision: 43696
URL: http://svnweb.freebsd.org/changeset/doc/43696
Log:
First half of edits to Backup sections.
Merge 18.9 Backup Strategies and 18.10 Backup Basics.
Clean up summary.
Divide utilities into File System Backups and Directory Backups sections (not quite complete yet).
Remove Do Nothing section (we don't want to encourage this).
Remove Which Program is Best section as it is personal opinion and based on 23 year old findings.
Next commit will finish the edits to this section.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/disks/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/disks/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/disks/chapter.xml Thu Jan 30 15:28:21 2014 (r43695)
+++ head/en_US.ISO8859-1/books/handbook/disks/chapter.xml Thu Jan 30 18:17:31 2014 (r43696)
@@ -1576,11 +1576,11 @@ cd0: Attempt to query device size failed
</sect2>
</sect1>
- <sect1 xml:id="backup-strategies">
- <info>
- <title>Backup Strategies</title>
+ <sect1 xml:id="backup-basics">
+ <title>Backup Basics</title>
- <authorgroup>
+<!--
+ <authorgroup>
<author>
<personname>
<firstname>Lowell</firstname>
@@ -1589,99 +1589,55 @@ cd0: Attempt to query device size failed
<contrib>Original work by </contrib>
</author>
</authorgroup>
- </info>
+ -->
- <para>The first requirement in devising a backup plan is to make
- sure that all of the following problems are covered:</para>
-
- <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, say by fire, including
- destruction of any on-site backups.</para>
- </listitem>
- </itemizedlist>
-
- <para>Some systems will be best served by having each of these
- problems covered by a completely different technique. Except
- for strictly personal systems with low-value data, it is
- unlikely that one technique will cover all of them.</para>
-
- <para>Some possible techniques include:</para>
+ <para>Implementing a backup plan is essential in order to have the
+ ability to recover from disk failure, accidental file deletion,
+ random file corruption, or complete machine destruction,
+ including destruction of on-site backups.</para>
+
+ <para>The backup type and schedule will vary, depending upon the
+ importance of the data, the granularity needed for file
+ restores, and the amount of acceptable downtime. Some possible
+ backup techniques include:</para>
<itemizedlist>
<listitem>
<para>Archives of the whole system, backed up onto permanent,
off-site media. This provides protection against all of the
problems listed above, but is slow and inconvenient to
- restore from. Copies of the backups can be stored on site
- or online, but there will still be inconveniences in
- restoring files, especially for non-privileged users.</para>
- </listitem>
-
- <listitem>
- <para>Filesystem snapshots, which are really only helpful in
- the accidental file deletion scenario, but can be
- <emphasis>very</emphasis> helpful in that case, as well as
- quick and easy to deal with.</para>
+ restore from, especially for non-privileged users.</para>
</listitem>
<listitem>
- <para>Copies of whole file systems or disks which can be
- created with a periodic <package>net/rsync</package> of the
- whole machine. This is generally most useful in networks
- with unique requirements. For general protection against
- disk failure, this is usually inferior to
- <acronym>RAID</acronym>. For restoring accidentally deleted
- files, it can be comparable to <acronym>UFS</acronym>
- snapshots.</para>
+ <para>Filesystem snapshots, which are useful for restoring
+ deleted files or previous versions of files.</para>
</listitem>
<listitem>
- <para><acronym>RAID</acronym>, which minimizes or avoids
- downtime when a disk fails at the expense of having to deal
- with disk failures more often, because there are more disks,
- albeit at a much lower urgency.</para>
+ <para>Copies of whole file systems or disks which are
+ sychronized with another system on the network using a
+ scheduled <package>net/rsync</package>.</para>
</listitem>
<listitem>
- <para>Checking fingerprints of files using &man.mtree.8;.
- Although this is not a backup, this technique indicates
- when one needs to resort to backups. This is particularly
- important for offline backups, and should be checked
- periodically.</para>
+ <para>Hardware or software <acronym>RAID</acronym>, which minimizes or avoids
+ downtime when a disk fails.</para>
</listitem>
</itemizedlist>
- <para>It is quite easy to come up with more techniques, many
- of them variations on the ones listed above. Specialized
- requirements 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 which dangers should be protected
- against, and how each will be handled.</para>
- </sect1>
-
- <sect1 xml:id="backup-basics">
- <title>Backup Basics</title>
-
- <para>The major backup programs built into &os; are
- &man.dump.8;, &man.tar.1;, &man.cpio.1;, and
- &man.pax.1;.</para>
+ <para>Typically, a mix of backup techniques is used. For
+ example, one could create a schedule to automate a weekly, full
+ system backup that is stored off-site and to supplement this
+ backup with hourly ZFS snapshots. In addition, one could make a
+ manual backup of individual directories or files before making
+ file edits or deletions.</para>
+
+ <para>This section describes some of the utilities which can be
+ used to create and manage backups on a &os; system.</para>
<sect2>
- <title>Dump and Restore</title>
+ <title>File System Backups</title>
<indexterm>
<primary>backup software</primary>
@@ -1773,13 +1729,16 @@ cd0: Attempt to query device size failed
</sect2>
<sect2>
- <title><command>tar</command></title>
+ <title>Directory Backups</title>
<indexterm>
<primary>backup software</primary>
<secondary><command>tar</command></secondary>
</indexterm>
+ <para>Several built-in utilities are available for backing up
+ and restoring specified files and directories as needed.</para>
+
<para>&man.tar.1; also dates back to Version 6 of AT&T
&unix;, circa 1975. <command>tar</command> operates in
cooperation with the file system and writes files and
@@ -1798,10 +1757,6 @@ cd0: Attempt to query device size failed
<para>When backing up over an insecure network, instead use
<command>ssh</command>.</para>
- </sect2>
-
- <sect2>
- <title><command>cpio</command></title>
<indexterm>
<primary>backup software</primary>
@@ -1837,10 +1792,6 @@ cd0: Attempt to query device size failed
backups, and <replaceable>backup_device</replaceable> is where
the backups should be written to, such as
<filename>/dev/nsa0</filename>).</para>
- </sect2>
-
- <sect2>
- <title><command>pax</command></title>
<indexterm>
<primary>backup software</primary>
@@ -1905,56 +1856,6 @@ cd0: Attempt to query device size failed
</sect2>
<sect2>
- <title>Do Nothing</title>
-
- <para><quote>Do nothing</quote> is not a computer program, but
- it is the most widely used backup strategy. There are no
- initial costs. There is no backup schedule to follow. Just
- say no. If something happens to your data, grin and bear
- it!</para>
-
- <para>If your time and data is worth little to nothing, then
- <quote>Do nothing</quote> is the most suitable backup program
- for the computer. But beware, &os; is a useful tool and
- over time it can be used to create a valuable collection of
- files.</para>
-
- <para><quote>Do nothing</quote> is the correct backup method for
- <filename>/usr/obj</filename> and other
- directory trees that can be exactly recreated by the computer.
- An example is the files that comprise the HTML or &postscript;
- version of this Handbook. These document formats have been
- created from XML input files. Creating backups of the HTML or
- &postscript; files is not necessary if the XML files are
- backed up regularly.</para>
- </sect2>
-
- <sect2>
- <title>Which Backup Program Is Best?</title>
-
- <indexterm>
- <primary>LISA</primary>
- </indexterm>
-
- <para>&man.dump.8; <emphasis>Period.</emphasis> Elizabeth D.
- Zwicky torture tested all the backup programs discussed here.
- The clear choice for preserving all your data and all the
- peculiarities of &unix; file systems is
- <command>dump</command>. Elizabeth created file systems
- containing a large variety of unusual conditions (and some not
- so unusual ones) and tested each program by doing a backup and
- restore of those file systems. The peculiarities included:
- files with holes, files with holes and a block of nulls, files
- with funny characters in their names, unreadable and
- unwritable files, devices, files that change size during the
- backup, files that are created/deleted during the backup and
- more. She presented the results at LISA V in Oct. 1991. See
- <link
- xlink:href="http://www.coredumps.de/doc/dump/zwicky/testdump.doc.html">torture-testing
- Backup and Archive Programs</link>.</para>
- </sect2>
-
- <sect2>
<title>Emergency Restore Procedure</title>
<sect3>
More information about the svn-doc-all
mailing list