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

Add a section that describes briefly various backup strategies available

Browse source 
with FreeBSD, their relative merits and what the final choise of a
backup strategy has to cover/support.

PR:		docs/89900
Submitted by:	Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
This commit is contained in:
Giorgos Keramidas 2005-12-12 15:16:03 +00:00
parent 116bdafd9b
commit 0c5fbe5924
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=26573
1 changed files with 91 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

91
en_US.ISO8859-1/books/handbook/disks/chapter.sgml
View file

@ -2270,6 +2270,97 @@ sa0(ncr1:4:0): Logical unit is in process of becoming ready</screen>
</sect2>
</sect1>
<sect1 id="backup-strategies">
<sect1info>
<authorgroup>
<author>
<firstname>Lowell</firstname>
<surname>Gilbert</surname>
<contrib>Original work by </contrib>
</author>
</authorgroup>
<!-- 3 Dec 2005 -->
</sect1info>
<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:</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 (e.g. fire), including destruction
of any on-site backups.</para>
</listitem>
</itemizedlist>
<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 (e.g. 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; utility 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.</para>
</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>