asg11.htm

apache技术手册

<FONT SIZE=4 COLOR="#FF0000"><B>restore</B></FONT></CENTER></H5>

<BR>

<P>To extract files backed up with dump, use restore. restore copies files stored in a dump tape or file to the current directory. Note that using restore can and will clobber exiting files with matching names. restore will also create any directories or directory trees that it needs before extracting a file. This feature is powerful if you know what you are doing. If in doubt, restore to an empty directory and move the files by hand. restore has the following syntax:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">/usr/etc/restore [options [argument  ]]</FONT></PRE>

<P>By default, restore will use the tape drive at /dev/rxt0 (check your man page). If you want to override this device, use the f option.

<BR>

<P>restore has an easy-to-use interactive shell-like interface that allows you to navigate through the dump tape as if your were in a filesystem. The interactive session is started by using the i option.

<BR>

<BR>

<H6 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><A NAME="I11"></A><A NAME="I12"></A><A NAME="I13"></A><A NAME="I14"></A><A NAME="I15"></A><A NAME="I16"></A><A NAME="I17"></A><A NAME="I18"></A><B>restore</B><B> Examples</B></FONT></CENTER></H6>

<BR>

<P>To restore all files from a tape, use this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">restore r</FONT></PRE>

<P>To restore a particular file, use this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">restore x /Users/demo/file.rtf</FONT></PRE>

<P>The preceding command will extract (x) the file specified (/Users/demo/file.rtf) from the tape. If the directories don't exist, it will create them. It's a good idea to direct restore to put recovered files on an empty directory, and then move the files to their final destination.

<BR>

<P>To restore from a compressed gzip archive, use this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">gzcat /tmp/backup.gz | restore f -</FONT></PRE>

<P>To create a catalog from files on a dump tape, use the t option. It is always a good idea to create a catalog from your tape. This will ensure that the backup tape you made contains the correct information and that the tape is readable.

<BR>

<P>Listing 4.1 is a script I use to automate backups. It is called from cron (see your UNIX documentation) with the level for the backup. Customizing it to fit your needs should not be very hard. Just read over all the options and make sure that the commands in your system are located in the same place. Also verify that the /dev files I reference match your configuration and change accordingly. This script automatically creates a catalog of the backups; it will also send a message notifying you if the backup was successful.

<BR>

<P>

<FONT COLOR="#000080"><B>Listing 4.1. An automated backup script.</B></FONT>

<BR>

<PRE>

<FONT COLOR="#000080">#!/bin/csh -f

# Simple backup csh program. Takes one argument, the dump level.

# The goal of a backup is not only to save the data in case of disaster,

# but to minimize the time and grief required to get the system 

# running again...

# cAlberto Ricart, 7/1/1996

#

# This example backups 2 disks /dev/rsd1a and /dev/rsd0a, in order of preference.

# /dev/rsd1a contains a lot of user data, if the tape were to fill up in the

# middle of

# the second backup, we are assured that the important data copied OK.

# as a peace of mind, this script generates a listing of all the files. This is

# just

# a test to verify that the tape can be read. Also helpful for locating files.

# Please verify that these commands have the same significance as yours.

# Also, more than likely you'll have to change the /dev/rsd1a and /dev/rsd0a to

# point to

# your raw disk device, as well as your tape device /dev/nrxt0 on our case.

set LOGGER = '/usr/ucb/Mail '

set DUMP_LOG = '/usr/local/adm/dump.log'

set DUMP = '/usr/etc/dump'

set DUMP_ARGS = ''$1'ufs /dev/nrxt0 1200000'

set GZIP = '/usr/bin/gzip -9'

set RM = '/bin/rm'

set TAPE = '/bin/mt -f /dev/nrxt0'

set PRINTCAT = '/usr/etc/restore t'

set CATDIR = '/usr/local/amd/Tape_Catalogs'

set DATE = `/bin/date | /bin/awk '{print $1&quot;:&quot;$2&quot;:&quot;$3&quot;:&quot;$6 }'`

set OPERATOR = 'webmaster'

if ($#argv == 1) then

 $DUMP $DUMP_ARGS /dev/rsd1a |&amp; $LOGGER $DUMP_LOG || mail -s DISK1_ BACKUP_FAILED $OPERATOR

 $DUMP $DUMP_ARGS /dev/rsd0a |&amp; $LOGGER $DUMP_LOG || mail -s DISK0_ BACKUP_FAILED $OPERATOR

 $TAPE rewind

 $PRINTCAT &gt; $CATDIR/$DATE.rsd1a.dump.$1

 $TAPE fsf 1

 $PRINTCAT &gt; $CATDIR/$DATE.rsd0a.dump.$1

 $TAPE rewind

 mail -s BACKUP_OK $OPERATOR

 exit (0)

else

 echo &quot;Backup script had no dump level, aborting&quot; | mail -s BACKUP_ ABORTED $OPERATOR

 exit (1)

endif

exit (1)</FONT></PRE>

<BR>

<A NAME="E68E139"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Monitoring Disk Space</B></FONT></CENTER></H3>

<BR>

<P>UNIX provides tools for monitoring your disk space as well as for monitoring the load incurred by your disk: df and iostat, respectively.

<BR>

<P>df (disk free) displays various statistics regarding all currently mounted disks on your system. It reports on capacity, used amount, and free amount, in kilobytes and percentage formats:

<BR>

<PRE>

<FONT COLOR="#000080">% df

Filesytem kbytes used avail capacity Mounted on

/dev/sd0a 1014845 397882 515478 44% /

/dev/sd0b 1014845 329337 584023 36% /usr/local</FONT></PRE>

<P>iostat displays information about disk performance, including the number of characters read and written to terminals for each disk, the number of transfers per second, and other information.

<BR>

<P>From this information you can glean the load affecting your disks:

<BR>

<PRE>

<FONT COLOR="#000080">% iostat

tty sd0 cpu

tin tout bps tps msps us ni sy id

0 6 80 14 0.5 2 0 5 93</FONT></PRE>

<P>One of the main reasons to monitor disk space is because if the logs are not checked periodically, they will fill up your filesystem. You should monitor what's in logs as well as the size of the logs.

<BR>

<BR>

<A NAME="E69E129"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Rotating the Logs</B></FONT></CENTER></H4>

<BR>

<P>If there's one thing that logs do, it's grow. The bigger they are, the longer it takes to process them. Organizing and managing your logs is a good thing to do because it provides you with a systematic way of naming and storing the logs. Once the logs are properly named, you can dump them to tape and forget about them. Should you ever need them, you can quickly retrieve them.

<BR>

<P>Small sites may not need their logs rotated more often than once a month. Heavy-traffic systems should really consider not logging at all. However, if logging is absolutely necessary, resetting the logs on a daily basis can produce a more manageable logfile.

<BR>

<P>To give you an idea of how quickly logs grow, the typical access log entry contains 85 bytes per request. Not much. However, on a site that handles 5 million requests a day at 85 bytes per request, this translates into 405MB of log data per day! You should rotate logs at an interval that gives you a manageable file size.

<BR>

<BR>

<A NAME="E69E130"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Resetting the Logs</B></FONT></CENTER></H4>

<BR>

<P>Resetting logs is a bit tricky. Apache won't start logging on to a new file until it restarts. The easiest way to accomplish the rotation is through a script that renames the logfile and then sends the server a HUP (hangup) signal. However, the problem with this approach is that all the current connections to the server will be terminated.

<BR>

<P>A simple script is shown in Listing 4.2.

<BR>

<P>

<FONT COLOR="#000080"><B>Listing 4.2. Resetting the logfile.</B></FONT>

<BR>

<PRE>

<FONT COLOR="#000080"># This scrip resets the log file, the log is renamed with todays date

# c1996 Alberto Ricart

# This script asumes that the PID file exists in its default location

# Bugs: Should handle a list of filenames, instead of just one.

#

set OPERATOR = 'webmaster'

set DATE = `/bin/date | /bin/awk '{print $1&quot;:&quot;$2&quot;:&quot;$3&quot;:&quot;$6 }'`

if ($#argv == 1) then

 if (-e $1) then

 mv $1 $1$DATE.weblog

 kill -HUP 'cat /usr/local/etc/httpd/logs/apache.pid'

 exit (0)

 else

 echo &quot;Logfile $1 doesn't exist.&quot; | mail -s LOG_ROTATION_ABORTED $OPERATOR

 exit 1

 endif

else

 echo &quot;You didn't provide a path to a log file.&quot; | mail -s LOG_ROTATION_ ABORTED $OPERATOR

 exit 1

endif

exit 0</FONT></PRE>

<P>Apache 1.1 ships with a utility program called rotatelogs that can be used to automatically reset the log without having to stop the server. As a side benefit, the program also names files incrementally.

<BR>

<P>To use rotatelogs, you'll need to compile it. You can do this easily by issuing the following commands:

<BR>

<PRE>

<FONT COLOR="#000080">cd /usr/local/etc/httpd/support

cc -o rotatelogs rotatelogs.c

strip rotatelogs</FONT></PRE>

<P>After a few moments, the program rotatelogs will be built. Next, you'll need to specify that output to the logfiles should be redirected to rotatelogs. The rotatelogs program uses the following syntax:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">rotatelogs <I>logfilename time</I></FONT></PRE>

<P>Where <I>logfilename</I> is the path to a logfile. <I>logfilename</I> will be used as the base name for the log. It's followed by a number that represents the system time. A new logfile will be started at the end of <I>time</I>. <I>time</I> specifies the rotation time in seconds.

<BR>

<P>To rotate the access and error logs every 24 hours, you'll need to modify the TransferLog and ErrorLog directives in your httpd.conf file like this:

<BR>

<PRE>

<FONT COLOR="#000080">TransferLog &quot;|/usr/local/etc/httpd/support/rotatelogs /usr/local/etc/httpd/logs/access_log 86400&quot;

ErrorLog &quot;|/usr/local/etc/httpd/support/rotatelogs /usr/local/etc/httpd/logs/error_log 86400&quot;</FONT></PRE>