⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 unx32.htm

📁 Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.
💻 HTM
📖 第 1 页 / 共 2 页
字号:
<HTML>

<HEAD>

<TITLE>UNIX Unleashed unx32.htm</TITLE>

<LINK REL="ToC" HREF="index.htm">

<LINK REL="Next" HREF="unxpt7au.htm">

<LINK REL="Previous" HREF="unx31.htm"></HEAD>

<BODY TEXT="#000000" LINK="#0000FF" VLINK="#800080" bgcolor=white>

<P><A HREF="unx31.htm"><IMG SRC="bluprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>

<A HREF="index.htm"><IMG SRC="blutoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>

<A HREF="unxpt7au.htm"><IMG SRC="blunext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>

<A HREF="index.htm"><IMG SRC="bluprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Home"></A>

</P><UL>

<LI>

<A HREF="#I1">32 &#151; Backups</A></LI>

<UL>

<UL>

<UL>

<UL>

<LI>

<A HREF="#I3">By S. Lee Henry</A></LI></UL></UL>

<LI>

<A HREF="#I4">Backups and Archives</A></LI>

<LI>

<A HREF="#I5">The dump Command</A></LI>

<LI>

<A HREF="#I6">The restore Command</A></LI>

<LI>

<A HREF="#I7">Dump Schedules</A></LI>

<LI>

<A HREF="#I8">The tar Command</A></LI>

<LI>

<A HREF="#I9">Commercial Software</A></LI>

<LI>

<A HREF="#I10">High-Reliability Technology</A></LI>

<LI>

<A HREF="#I11">Summary</A></LI></UL></UL></UL>



<H1 ALIGN="CENTER">

<CENTER><A ID="I1" NAME="I1">

<BR>

<FONT SIZE=5><A ID="I2" NAME="I2"></A><B>32 &#151; Backups</B>

<BR></FONT></A></CENTER></H1>

<H5 ALIGN="CENTER">

<CENTER><A ID="I3" NAME="I3">

<FONT SIZE=3><B>By S. Lee Henry</B>

<BR></FONT></A></CENTER></H5>

<P>The only thing wrong with backups is that you have to do them, and that is often a big problem. Necessary safeguards against disaster, backups take time and are generally not used. As a result, the motivation for doing them is often lacking, except 
immediately following a disaster, and the recognition you get for all the time and effort that backups require is almost always nonexistent. At the same time, no responsible system administrator or user would fail to see that backups are done on a regular 

basis.

<BR></P>

<P>Routinely storing entire file systems or individual directories and files to protect the integrity of your system and your work can be very time-consuming or it can be fairly well automated.

<BR></P>

<P>Whether caused by human error (most likely), by media failure, or by acts of God, loss of important files warrants the time and attention that goes into planning and executing a good backup scheme.

<BR></P>

<P>After reading this chapter, you will be able to back up and restore file systems or individual files, design a backup schedule that is right for your site, and evaluate the advantages of commercial backup software.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I4" NAME="I4">

<FONT SIZE=4><B>Backups and Archives</B>

<BR></FONT></A></CENTER></H3>

<P>The last chapter discussed archiving. Very similarly to backups, archives are usually created by individual users interested in storing &quot;snapshots&quot; of their work when they reach important milestones. Archives are usually the result of an 
individual's interest in making a safe copy of his own work.

<BR></P>

<P>Backups, on the other hand, are most often the responsibility of system administrators and represent the state of entire file systems rather than the work of specific individuals. Usually periodic in nature, backups are an attempt to preserve the state 

of a system so that any type of loss, whether through human error or catastrophe, can be averted.

<BR></P>

<P>Another important distinction between archives and backups is the issue of completeness. Archives will include files that may subsequently be deleted from the system. These archives may be kept indefinitely, or at least as long as the project or effort 

being archived has some relevance. Backups, on the other hand, are generally cycled. Files that are removed from file systems will eventually disappear from the backups as well. There is usually a fixed window of a couple weeks or a couple months within 
which a file that is removed can be recovered.

<BR></P>

<P>Backups should be automated. Most people will not reliably back up their systems if it is a boring and painful task. The best backups happen &quot;by themselves.&quot; This doesn't mean that a good deal of insight isn't required to configure the 
process. 

<BR></P>

<P>One of the most important distinctions to be made regarding backups is whether you back up an entire file system or only those files that have been created or modified since some earlier time. A combination of full and incremental backups is usually the 

best strategy for getting the greatest reliability while minimizing the work of retrieving files and the number of backup tapes (or other media) that must be maintained.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I5" NAME="I5">

<FONT SIZE=4><B>The </B><B><I>dump</I></B><B> Command</B>

<BR></FONT></A></CENTER></H3>

<P>The dump command is the command most commonly used for backups. Typically used to dump entire file systems to tape, whether fully or incrementally, the dump command can also be used to dump specified files and directories. The dump command creates 
backups in a format that includes directory information as well as a notation of where the file system was last mounted. The directory index precedes the actual files.

<BR></P>

<P>The dump command can access remote or local drives. To use the remote dump command, all you need to do is precede the name of the tape device with the name of the remote host (for example, boson:/dev/rst0). On some UNIX systems, there is a second dump 
command, rdump, which specifies a remote dump. When rdump is used, the system will look for a host named dumphost in your host file and attempt to dump to dumphost:/dev/rmt0. To perform a remote dump (that is, dump to another host's tape drive or hard 
disk), the other host needs to trust the one you are dumping from. Including the local host in the remote host's /.rhosts file is the simplest way to do this, but this gives the local host considerable access to the remote one and may not be a good 
strategy for security reasons. It is often possible to dump to the remote host as a specific user rather than as root. In this case, the syntax user@remotehost:device is used instead of remotehost:device, and the user must have an .rhosts file in his home 

directory.

<BR></P>

<P>The following is some typical dump command output. It provides a lot of information about the file system being dumped, including the dates of the last dumps at this level and the lower level, the partition name and the mount point, the passes dump 
makes as it dumps the directory information and the contents of the files themselves, and an estimate of how much tape will be used in the process.

<BR></P>

<P>The command

<BR></P>

<PRE>boson% /usr/etc/dump 7cusdtf 590 1200 18 /dev/nrst0 /dev/sd0h</PRE>

<P>produces the following output:

<BR></P>

<PRE>  DUMP: Date of this level 7 dump: Tue Mar  8 00:20:01 1994

  DUMP: Date of last level 5 dump: Sat Mar  5 02:22:11 1994

  DUMP: Dumping /dev/rsd0h (/export/data1) to /dev/nrst0

  DUMP: mapping (Pass I) [regular files]

  DUMP: mapping (Pass II) [directories]

  DUMP: mapping (Pass II) [directories]

  DUMP: estimated 520 blocks (260KB) on 0.00 tape(s).

  DUMP: dumping (Pass III) [directories]

  DUMP: dumping (Pass IV) [regular files]

  DUMP: level 7 dump on Tue Mar  8 00:20:01 1994

  DUMP: Tape rewinding

  DUMP: 546 blocks (273KB) on 1 volume

  DUMP: DUMP IS DONE</PRE>

<P>In SVR4 systems, the dump command is called ufsdump. The format of the dump files, however, is the same so that you can almost always read dumps from one UNIX system on another.

<BR></P>

<P>The dump command uses dump levels to indicate whether full or incremental dumps should be made. A level 0 dump is a full dump. Levels 1&#151;9 create incremental dumps. The level of an incremental dump has significance only in relationship to other 
dumps. If John Doe made a level 0 dump once a month and a level 9 once a week, while Jane Doe ran a level 0 dump once a month and a level 5 once a week, they would both have the same dump result (we are assuming that they are dumping different systems). 
Both the level 9 and the level 5 dumps will include all files that have been modified since the earlier dump, at a lower level (that is, the level 0 dump). If John dumped at levels 0, 5, and 8, on the other hand, his level 8 dumps would include files 
modified only since the most recent level, 0 or 5 (whichever most closely preceded it).

<BR></P>

<P>The dump command keeps track of the date and level of the prior dumps through use of a file called /etc/dumpdates. Unsuccessful backups will not update this file, which includes a record for each file system and dump level used, along with the date and 

time of the backup. Here is an example:

<BR></P>

<PRE>/dev/rsd0g       0 Sat Jul 12 03:45:00 1994

/dev/rsd0g       5 Fri Jul  4 03:45:01 1994

/dev/rsd2a       0 Tue Jul  1 03:52:49 1994

/dev/rsd2a       5 Fri Jul  4 03:55:49 1994</PRE>

<P>Each of these records will be updated the next time a backup is done of the same file system at the same level.

<BR></P>

<P>One useful way to employ this information is to extract the dates of the latest backups and include them in your /etc/motd file. This will reassure users that their files are being backed up routinely and give them an idea of how current the latest 
backups are.

<BR></P>

<P>Here's a script that will do this:

<BR></P>

<PRE>#!/bin/csh

#

# remove old dump dates (if there)

/bin/cat /etc/motd | /usr/local/bin/grep -v &quot;^Last&quot; &gt; /tmp/motd.$$

# determine home partition

#set PART='grep /export/home /etc/fstab | awk -F/ '{print $3}''

# get dates for last level 0 and 5 backups

set FULL='grep &quot;/dev/rusr        0&quot; /etc/dumpdates | awk '{print $3,$4,$5,$6}''

set INCR='grep &quot;/dev/rusr        5&quot; /etc/dumpdates | awk '{print $3,$4,$5,$6}''

# create new motd file w this info

echo &quot;Last full backup:          &quot; $FULL &gt;&gt; /tmp/motd.$$

echo &quot;Last incremental backup:     &quot; $INCR &gt;&gt; /tmp/motd.$$

# put new motd file in place

mv /tmp/motd.$$ /etc/motd</PRE>

<P>Here's a typical /etc/motd updated by such a script:

<BR></P>

<PRE>SunOS Release 4.1.3 (boson) #2: Wed Aug 11 13:54:26 EDT 1994

     Dial-in.......123-4567

     ExaByte......./dev/rst0

     9-Track......./dev/rmt0

     9-Track......./dev/rmt8 (1600/6250)

****************************************************************************

*                                                                          *

*          Don't forget tea and cookies at 3 PM this afternoon             *

*                                                                          *

**************************************************************************** 

Last full backup:           Sat Mar 12 03:45:00

Last incremental backup:      Fri Mar 4 03:45:01</PRE>

<P>Similar to the tar command described in the previous chapter, the dump command is usually used to back up file systems to tape. Given the nature of UNIX, however, dump files can also be created on hard disk or on less expensive media, such as read-write 

optical disks. Like the tar command, the dump command can create a file in a specific format that can be used later to extract files. The benefit of disk-based dumps is that they are always available, and the process can be automated so that there is 
practically no human intervention needed. With tape-based backups, it is often the manual procedures of inserting, removing, and labelling the tapes that cause the most problems. With disk-based dump, you can rely on file naming conventions to 
&quot;cycle&quot; your backups. It is also possible to get a similar effect using a multitape backup device. In any case, the more you can automate your backups, the more likely it is that you will be able to recover when the need arises.

<BR></P>

<P>You should be familiar with the optional parameters of the dump command. These can very significantly affect how efficiently your backups are, in terms of both space and speed. Density and length parameters that are proper for a 1/2-inch tape are not at 

all correct for an 8 mm Exabyte drive. Even if you are backing up to hard disk, the parameters you provide will determine whether the dump is successful or not because dump will use these parameters to calculate the space available for the disk-based dump. 

Most UNIX systems will include suggestions about dump parameters in the man page for the dump command. Here are some suggestions:

<BR></P>

<TABLE BORDER>

<TR>

<TD>

<P>60 MB cartridge:</P>

<TD>

<P>cdst 1000 425 9</P>

<TR>

<TD>

<P>150 MB cartridge:</P>

<TD>

<P>cdst 1000 700 18</P>

<TR>

<TD>

<P>1/2-inch tape:</P>

<TD>

<P>dsb 1600 2300 126</P>

<TR>

<TD>

<P>2.3-GByte 8mm tape:</P>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -