0373-0376.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 433 行
HTML
433 行
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:Backup and Restore</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=18 //-->
<!-- PAGES=0373-0382 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="../ch17/0371-0372.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0377-0382.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-373"><P>Page 373</P></A>
<H3><A NAME="ch18_ 1">
CHAPTER 18
</A></H3>
<H2>
Backup and Restore
</H2>
<P>
<B>by David Pitts</B>
</P>
<H3><A NAME="ch18_ 2">
IN THIS CHAPTER
</A></H3>
<UL>
<LI> Qualities of a Good Backup
<LI> Selecting a Backup Medium
<LI> Selecting a Backup Tool
<LI> Backup Strategy
<LI> Restoring Files
<LI> What Is on the Tape?
</UL>
<A NAME="PAGENUM-374"><P>Page 374</P></A>
<P>Data is important. Both the time it took to create it and the uniqueness of the data make
it valuable. Therefore, care should be taken that data is not lost.
</P>
<P>Data can be lost several different ways. The first is through carelessness. I do not know
how many times I have restored data for people who have been in the wrong directory when
they issued an rm -r command. The second way that data can be lost is through hardware
failure. Although newer hard drives are more reliable than the older ones, they still fail, and data
is lost. A third way that data is lost is faulty software. Too many times I have programmed a
tool to perform a task, only to have the tool destroy my data instead of manipulating it. The rule
of thumb these days is that programs are released before they are ready. If there is a bug, then
the people who developed the software will put out a patch. Still the data, and time it took,
are both gone. Finally, the earth can just swallow up entire buildings; or there can be
earthquakes, or tornadoes, or volcanoes, or hurricanes, or aliens from outer space.
</P>
<P>Backups can protect that investment in time and in data, but only if they are actually
successful in backing up and keeping the information. Therefore, part of a successful backup
procedure is a test strategy to spot check backups. The easiest way to spot check your backups is
to perform a restore with them. This is something you should attempt
before you need to perform a restore with them.
</P>
<P>Backups can take on many forms. I worked for a company once that had six servers.
Their backup method was to tar servers and store a copy of that
tar on another server. In addition, they did tape backups of the servers, which included the online version of the backups.
These tape backups were used for disaster recovery purposes and kept offsite. This example
actually shows a couple different ways of performing backups: One way is to store tarred copies on
other machines, and the other is to store copies on tape backup (and to keep the copies offsite).
The combination of these two methods provides a fairly reliable way of doing backups in that
it covers everything from the simple "Oops, I accidentally deleted your database!" to
"Godzilla just stepped on our building, and we need the data back in less than two days!"
</P>
<P>This chapter covers what the qualities of a good backup are and the process of selecting a
good backup medium and a backup tool. Finally, backup strategies are considered, including
incremental and full backups and when to perform each.
</P>
<H3><A NAME="ch18_ 3">
Qualities of a Good Backup
</A></H3>
<P>Obviously, in the best of all possible worlds, backups would be perfectly reliable, always
available, easy to use, and really fast. In the real world, this is not the case. There are trade-offs to
be made. For example, backups stored offsite are good for disaster recovery, but would not
always be available.
</P>
<P>Above all, backups need to be reliable. A reliable backup medium should last for several
years. Of course, if the backups are never successfully written to the backup medium, then it
does not matter how good the medium is.
</P>
<A NAME="PAGENUM-375"><P>Page 375</P></A>
<P>Speed is more or less important, depending upon the system. If there is a time window
when the system is not being utilized, and the backup can be automated, then speed is not an
issue. On the other hand, the restoration might be an issue. The time it takes to restore the data is
as important as how critical it is to have the data available.
</P>
<P>Availability is a necessary quality. It does no good to perform regular backups if, when they
are needed, they are unavailable. Backups for disaster recovery would not be available to restore
a single file that a user accidentally deleted. A good backup and recovery scheme includes
both a local set of backups for day-to-day restores and an offsite set of backups for disaster
recovery purposes.
</P>
<P>It does no good to have fast, available, reliable backups if they are not usable. The tools
used for backup and restoration need to be easy to use. This is especially important for
restoration. In an emergency, the person who normally performs the backup and restores might be
unavailable. A nontechnical user might have to perform the restoration. Obviously,
documentation is a part of usability.
</P>
<H3><A NAME="ch18_ 4">
Selecting a Backup Medium
</A></H3>
<P>Today the three common backup options are floppies, tapes, and hard drives. Table 18.1
rates these media in terms of reliability, speed, availability, and usability.
</P>
<P>Table 18.1. Backup medium comparison.</P>
<TABLE WIDTH="360">
<TR><TD>
<B>Media</B>
</TD><TD>
<B>Reliability</B>
</TD><TD>
<B>Speed</B>
</TD><TD>
<B>Availability</B>
</TD><TD>
<B>Usability</B>
</TD></TR>
<TR><TD>
Floppies
</TD><TD>
Good
</TD><TD>
Slow
</TD><TD>
High
</TD><TD>
With small
data—good; with large data—bad
</TD></TR>
<TR><TD>
Tapes
</TD><TD>
Good
</TD><TD>
Medium to fast
</TD><TD>
High
</TD><TD>
Depending on the size
of the tape, can be highly usable
</TD></TR>
<TR><TD>
Hard drives
</TD><TD>
Excellent
</TD><TD>
Fast
</TD><TD>
High
</TD><TD>
Highly usable
</TD></TR>
</TABLE>
<P>Of course, there are other options, including CDs and floptical disks. Writable CDs are
good for archival purposes, but they cannot be overwritten; therefore, the expense tends to be
high. Flopticals, with attributes of both floppies and optical disks, tend to have the good qualities
of floppies and tapes. They are good for single file restoration, and they can hold a lot
of data.
</P>
<H3><A NAME="ch18_ 5">
Selecting a Backup Tool
</A></H3>
<P>Many tools are available for making backups. In addition to numerous third-party
applications, Red Hat Linux comes with some standard tools for performing this task. This
section examines two of them, tar and cpio.
</P>
<A NAME="PAGENUM-376"><P>Page 376</P></A>
<P>tar and cpio are very similar. Both are capable of storing and retrieving data from almost
any media. In addition, both tar and cpio are ideal for small systems, which Red Hat Linux
systems often are. For example, the following tar command saves all files under
/home to the default tape drive:
</P>
<!-- CODE SNIP //-->
<PRE>
$ tar -c /home
</PRE>
<!-- END CODE SNIP //-->
<P>The -c option tells tar which directory it is gathering files
from—/home in the preceding example.
</P>
<P>cpio, while similar, has several advantages. First it packs data more efficiently than does the
tar command. Second, it is designed to back up arbitrary sets of files
(tar is designed to back up subdirectories). Third,
cpio is designed to handle backups that span over several tapes.
Finally, cpio skips over bad sections on a tape and continues, while
tar crashes and burns.
</P>
<H3><A NAME="ch18_ 6">
Backup Strategy
</A></H3>
<P>The simplest backup strategy is to copy every file from the system to a tape. This is
called a full backup. Full backups by themselves are good for small systems, such as those typically used
by Red Hat Linux users.
</P>
<P>The downside of a full backup is that it is time-consuming. Restoring a single file is almost
too cumbersome to be of value. There are times when a full backup is the way to go, and
times when it is not. A good backup and recovery scheme will identify when a full backup is
necessary and when incremental backups are preferred.
</P>
<P>Incremental backups tend to be done more frequently. With an incremental backup, only
those files that have changed since the last backup are backed up. Therefore, each incremental
builds upon previous incremental backups.
</P>
<P>UNIX uses the concept of a backup level to distinguish different kinds of backups. A full
backup is designated as a level 0 backup. The other levels indicate the files that have changed since
the preceding level. For example, on Sunday evening you might perform a level 0 backup
(full backup). On Monday night, you would perform a level 1 backup, which backs up all
files changed since the level 0 backup. Tuesday night would be a level 2 backup, which backs up
all files changed since the level 1 backup, and so on. This gives way to two basic backup and
recovery strategies. Here is the first:
</P>
<TABLE WIDTH="360">
<TR><TD>
Sunday
</TD><TD>
Level 0 backup
</TD></TR>
<TR><TD>
Monday
</TD><TD>
Level 1 backup
</TD></TR>
<TR><TD>
Tuesday
</TD><TD>
Level 1 backup
</TD></TR>
<TR><TD>
Wednesday
</TD><TD>
Level 1 backup
</TD></TR>
<TR><TD>
Thursday
</TD><TD>
Level 1 backup
</TD></TR>
<TR><TD>
Friday
</TD><TD>
Level 1 backup
</TD></TR>
<TR><TD>
Saturday
</TD><TD>
Level 1 backup
</TD></TR>
</TABLE>
<P><CENTER>
<a href="../ch17/0371-0372.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0377-0382.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?