os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

First half of edits to Backup sections.

Browse source 
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
This commit is contained in:
Dru Lavigne 2014-01-30 18:17:31 +00:00
parent b6950141a7
commit a2f0cd2ed9
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43696
1 changed files with 35 additions and 134 deletions
Download patch file Download diff file Expand all files Collapse all files

169
en_US.ISO8859-1/books/handbook/disks/chapter.xml
View file

@ -1576,11 +1576,11 @@ cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c
</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: NOT READY, Medium not present - tray c
<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>
<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>
<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>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>
restore from, 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>
<para>Filesystem snapshots, which are useful for restoring
deleted files or previous versions of files.</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>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><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>
</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: NOT READY, Medium not present - tray c
</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&amp;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: NOT READY, Medium not present - tray c
<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: NOT READY, Medium not present - tray c
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>
@ -1904,56 +1855,6 @@ cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c
but is available as either a port or package.</para>
</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>