Backup Strategies and Operations

Published on December 2016 | Categories: Documents | Downloads: 39 | Comments: 0 | Views: 171
of 15
Download PDF   Embed   Report

Comments

Content

Using at
Use at when you want to execute a command or multiple commands once at some
future time.
In Linux, the at command requires that the atrun command be started in root's crontab
file. Many Linux distributions ship with at enabled, but some do not. To enable the at
utility on your system, become superuser and edit root's crontab file:
$ su root
Password:
# crontab -e

and add the following line:

* * * * * directory/atrun

where directory is the location where the atrun executable is stored. On my system
that's /usr/lib, so the entry is:
* * * * * /usr/lib/atrun

This causes atrun to be executed every minute. After a minute or so of adding the
atrun line and saving the crontab file, any existing at commands are evaluated and
executed if the time is right. (Before this, you may have been able to enter at
commands, but they were never executed.)
To demonstrate the at command, let's have it print ``hello'' on your current terminal
window after a few minutes. First, get the time and your current terminal device:
$ date
Tue Oct 3 15:33:37 PDT 1995
$ tty
/dev/ttyp2

Now run the at command. Specify a time in the command line, press Return, and then
enter the command, followed by another Return and a Control-D:
$ at 15:35
echo "hello" > /dev/ttyp2
^D
Job c00ceb20b.00 will be executed using /bin/sh

The at command takes input up to the end-of-file character (press Control-D while at
the beginning of a line). It reports the job number and informs you that it will use
/bin/sh to execute the command. In two minutes, hello should appear on the display
of /dev/ttyp2. Note that you can enter a series of commands, one per line---at will read
each line up to the end-of-file and execute the file as a /bin/sh shell script at the
specified time. Suppose you want to set an alarm. One way to tell at to do something
is to use the relative form of timing, specifying a time relative to now. If you want your
computer to beep at you in 25 minutes, enter:
$ at now + 25 minutes
echo ^G > /dev/ttyp4

^D
Job c00ceb7fb.00 will be executed using /bin/sh

and you are beeped in 25 minutes. There is a great deal of flexibility allowed in
entering time specifications. For example, at recognizes military time, ``am'' and
``pm'', month abbreviations, times including the year, and so on. My at man page even
claims that at accepts teatime, noon, and other constructs. Refer to the at man page for
more examples of valid time specifications.
You must tell at your tty location or it won't send output to your terminal window. If
you prefer, you can receive mail:
$ at 4:55pm Friday
echo '5 p.m. meeting with Carol' | mail raithel
^D
Job c00ceb7fb.01 will be executed using /bin/sh

To get a list of your pending at jobs, enter:
$ atq

If you are superuser, atq shows you the pending at jobs of all users. To delete a job,
enter:
$ atrm job_number

where job_number is the job number returned by atq. The superuser can also remove
other user's jobs.

The at command schedules a command to be run once at a particular time. This can be
any command that you normally have permission to run; anything from a simple
reminder message, to a complex script. You start by running the at command at the
command line, passing it the scheduled time as the option. It then places you at a
special prompt, where you can type in the command (or series of commands) to be run
at the scheduled time. When you're done, press Control-D on a new line, and your
command will be placed in the queue.
A typical at command sequence looks like this (commands you type are shown here in
the blue box, or in bold face below):
at 9:30 PM Tue

warning: commands will be executed using /bin/sh
at> echo "Well gosh golly, it's 9:30 PM on Tuesday."
at> ^D
job 1 at Tue Nov 16 09:30:00 2014

So let's take a look at what we see here. When we ran the command, the first
thing atdid was give us a "warning" telling us what command shell our commands will
be run with: in this case, /bin/sh, the Bourne Shell. This is the traditional standard
Unix shell.
It then places us at the at> prompt. Here we type in a simple echo command, which
simply echoes a string of text. We press enter, and we're placed at a new at> prompt.
We then press Control-D, telling at we're all done with our commands. It then tells us
that our job is job number 1 and that it will run next Tuesday.

Backup Strategies and Operations
The simplest backup strategy is to copy every file from the system to a backup medium. This is called a full backup. Full
backups by themselves are good for small systems.
The downside of a full backup is that it can be time-consuming. Restoring a single file from a large backup such as a tape
archive can be almost too cumbersome to be of value. Sometimes a full backup is the way to go, and sometimes it is not. A
good backup and recovery scheme identifies when a full backup is necessary and when incremental backups are preferred.
NOTE

If you use your Red Hat Linux system for business, you should definitely have a backup strategy. Creating a formal plan to
regularly save critical information, such as customer accounts or work projects, is essential to avoid financial disaster. Even
more important: After you devise your backup plan, stick to it!
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.
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). Then 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:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday

Level 0 backup
Level 1 backup
Level 1 backup
Level 1 backup
Level 1 backup
Level 1 backup
Level 1 backup

The advantage of this backup scheme is that it requires only two sets of backup media. Restoring the full system from the
level 0 backup and the previous evening's incremental can perform a complete restore. The negative side is that the amount
backed up grows throughout the week, and additional media might be needed to perform the backup. Here is the second
strategy:
Sunday
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday

Level 0 backup
Level 1 backup
Level 2 backup
Level 3 backup
Level 4 backup
Level 5 backup
Level 6 backup

The advantage of this backup scheme is that each backup is relatively quick. Also, the backups stay relatively small and
easy to manage. The disadvantage is that it requires seven sets of media. Also, you must use all seven sets to do a
complete restore.
When deciding which type of backup scheme to use, you need to know how the system is used. Files that change often
should be backed up more often than files that rarely change. Some directories, such as /tmp, never need to be backed
up.

Performing Backups with tar and cpio
A full backup with tar is as easy as this:

$ tar cf backup.tar /

This example uses tar's f option, followed by the name of the desired backup archive and a designated directory tree to
back up. Note that if you have a dual-boot system, and have Windows or another operating system available under
the /mnt directory, those systems will also be backed up! You should also know that the GNU tar command can also
perform on-the-fly compression usinggzip by including the z option like this:

$ tar czf backup.tgz /

In this example, a compressed archive of the root directory is created and saved in the file named backup.tgz (also
known as acompressed tarball). This is handy for creating single archives of known directories all at once.
An incremental backup takes a bit more work. Fortunately, the find command is a wonderful tool to use with backups to
find all files that have changed since a certain date. It can also find files that are newer than a specified file. With this
information, it is easy to perform an incremental backup. The following command finds all files in the current directory ( .)

that have been modified today and backs up those files with the tar command to
an archive on /dev/rmt1:

$ find . -mtime 1 ! -type d | tar cT - >/dev/rmt1

The

! -type d

says that if the object found is a directory, don't give it to the

tar

command for archiving. This

is done becausetar follows the directories, and you don't want to back up an entire directory unless everything in it
has changed. Of course, thefind command can also be used for the
same task as the preceding

tar

cpio

command. The following command performs the

command, but for the entire filesystem (/):

$ find / -mtime -1 | cpio -o >/dev/rmt1

As mentioned, the

find

command can find files that are newer than a specified file. The

touch

command updates the

time of a file and may be used to touch a file after a backup has completed. Then, at the next backup, you simply search
for files that are newer than the file you touched. The following example searches for files that are newer than the
file

/tmp/last_backup

and performs acpio to archive the data:

$ find / -newer /tmp/last_backup -print | cpio -o > /dev/rmt0

With

tar,

the same action is completed this way:

$ find / -newer /tmp/last_backup | tar cT - >/dev/rmt0

NOTE

You may want to touch the file before you start the backup to ensure that the next backup gets any files modified during
the current backup.

Once you have found a reliable search command and determined a reliable destination for your backup, you can then
automate the process by using a

crontab

setting. For example, one simple approach to back up the

each day might be to place your command line (as an executable script) in the

/home

/etc/cron.daily

Hat Linux provides (by default) hourly, daily, weekly, and monthly operations in your system's

directory

directory. Red

/etc/crontab

file,

which looks like this:

...
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
...
If you take a look under the

001 0anacron

/etc/cron.daily

logrotate

directory, you'll see

makewhatis.cron

slocate.cron

tmpwatch

002
These files are executable shell scripts that are run (according to the

/etc/crontab.daily

entry) each day at

4:02 a.m. If your backup operations take too long and can possibly run into the morning work hours, you should adjust
this setting, or create your own

001 30 2 * * *

/etc/crontab

entry, such as:

/bin/tar cvzf /backup/daily.tgz /home

002
This example will back up the

/home

directory to the file named

taper

Script

morning at 2:30 a.m.

Performing Backups with the

daily.tgz

under the

/backup

directory each

The

taper

script (/usr/sbin/taper), included with Red Hat Linux, is a backup and restore program with a

graphical interface you can use to maintain compressed or uncompressed archives on tapes or removable media (even over a
network!). Using

taper

is easy; the format of a

taper

command line looks like this:

# taper <-T tape-type> <option> <device>
You first need to decide what type of device (or media) you'd like to use with

taper.

This program supports a number

of devices, which are listed in Table 22.2 along with the command lines to use.

Table 22.2. Device Support by

taper

Device

Type
/dev/zftape Floppy tape driver
/dev/ht0
IDE tape driver
file
File on hard disk
/dev/ftape Floppy tape driver
/dev/fd0
Removable floppy
drive
/dev/sda4
Removable Zip drive

Command Line
# taper –T z
# taper –T i
# taper –T l
# taper –T f
# taper –T r
# taper –T r –b /dev/sda4

(-b denotes the device and

archive file)
/dev/sda

SCSI tape drive

# taper –T s

Qualities of a Good Backup
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, trade-offs must be made. For example, backups stored offsite are good for disaster recovery, but are
not always available.

Above all, backups need to be reliable. A reliable backup medium will last for several years, whereas a reliable archive
medium should last much longer. Of course, if the backups are never successfully written to the backup medium, it does not
matter how good the medium is, and today's ever-increasing storage requirements can tax even the very best hardware and
strategies.

Speed is more or less important, depending on the system and use of the data. If a time window is available when the
system is not being used and the backup can be automated, speed is not an issue. On the other hand, restoration might be
an issue. The time it takes to restore the data is as important as the need to have the data available.

Availability is a necessary quality. Performing regular backups does no good if, when they are needed, they are unavailable.
Backups for disaster recovery may not be available locally and don't always include data timely enough to restore a single
file accidentally deleted by a user. 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.

Fast, available, reliable backups are no good 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, and a nontechnical user might have to perform the restoration. Obviously, documentation is a
part of usability.

UNICOS/mp Disks and File Systems Administration - S-2377-22
TM

Prev
Section

Chapter 7. Maintaining XFS File Systems

Next Section

7.2. Mounting and Unmounting File Systems
File systems must be mounted to be used.
Note: Use of the Cray Programming Environment Server (CPES) requires that some
file systems be cross-mounted between the Cray X1 system and CPES. See the Cray
Programming Environment Server (CPES) Administration Guide for more
information.
Figure 7-1 illustrates the mounting process. When a file system is mounted, the name
of the device file for the file system (/dev/rdsk/dks0d2s7 in Figure 7-1) and the name
of a directory (/proj in Figure 7-1) are given. This directory, /proj,is called a mount
point and forms the connection between the file system containing the mount point
and the file system to be mounted. Mounting a file system tells the kernel that the
mount point is to be considered equivalent to the top level directory of the file system
when pathnames are resolved. In Figure 7-1, the files a, b, and c in
the /dev/rdsk/dks0d2s7 file system become/proj/a, /proj/b, and /proj/c as shown in
the bottom of the figure.
Figure 7-1. Mounting a File System

When you mount a file system, the original contents of the mount point directory are
hidden and unavailable until the file system is unmounted. However, the mount point
directory owner and permissions are not hidden. Restricted permissions can restrict
access to the mounted file system.
Unlike other file systems, the root file system ( /) is mounted as soon as the kernel is
running and cannot be unmounted because it is required for system operation.
The usr file system, if it is a separate file system from the root file system, must also
be mounted for the system to operate properly.
You can mount file systems in several ways:
 Manually with the mount command.
 Automatically when the system is booted, using information in the
file /etc/fstab.
 Automatically when the file system is accessed (called automounting, which
applies to NFS (remote) file systems only.
You can unmount file systems in two ways:
 Shut down the system (file systems are unmounted automatically)
 Manually unmount file systems with the umount command.

The following subsections explain the use of the mount and umount commands and the
file /etc/fstab to mount and unmount file systems.

7.2.1. Manually Mounting File Systems
The mount command is used to mount file systems manually. The basic forms of
the mount command include:
mount device_file mount_point_directory
mount host:directory mount_point_directory

Where device_file is a block device file. host:directory is the host name and pathname
of a remote directory that has been exported on the remote host by using
the exportfs command on the remote host (which requires
NFS). mount_point_directory is the mount point directory. The mount point must
already exist (you can create it with the mkdir command).
If you omit either the device_file or the mount_point_directory from
the mount command line, mount checks the file /etc/fstab to find the missing
argument. See Section 7.2.2 for more information about/etc/fstab.
For example, to mount a file system manually, use this command:
mount /dev/dsk/dks0d1s6 /usr

Another example, which uses a mnemonic device file name:
mount /dev/usr /usr

An example of a mount command for a file system that is listed in /etc/fstab is:
mount /d2

Other useful mount commands:
mount -a

Mount all file systems listed in /etc/fstab.
mount
-h host

Mount all file systems listed in /etc/fstab that are remote-mounted from
the system named host.

You can use the -t type option of the mount command to specify what type of file
system you are mounting. For a description of the file system types that the
UNICOS/mp operating system supports, seeSection 6.4 and the filesystems(7) man
page.
See the mount(8) man page for more information about the mount command.

7.2.2. Mounting File Systems Automatically With
the /etc/fstab File
The /etc/fstab file contains information about every file system and swap partition
that is to be mounted automatically when the system is booted to multi-user mode. In
addition, the /etc/fstab file is used by the mount command when only the device
block file or the mount point is given to the mount command. File systems that are not
mounted with the mount command, such as the /proc file system, are not listed
in /etc/fstab.
The procedure in this section explains how to add an entry for a file system
to /etc/fstab.
For each file system that is to be mounted every time the system is booted, a line
similar to this appears in the file /etc/fstab:
/dev/dsk/dks0d2s7 /test xfs rw,raw=/dev/rdsk/dks0d2s7 0 0

The fields in this line are defined as follows:
/
dev/dsk/dks0d2s7

The block device file of the partition where the file system is
located.

/test

The name of the directory where the file system will be mounted
(the mount point).
xfs

The type of file system. In this case, the file system is an XFS file
system.

rw, raw=

These are some of many options available when mounting a file
system (see the fstab(5) man page for a complete list). In this
instance, the file system is to be mounted read-write, so
that root and other users can write to it. The raw= option gives
the file system's raw device file name. It should be the last option
in the options list.
0 0

These two numbers represent the frequency of dump cycles and
the fsck pass priority. These two numbers must be added after the
last option in the options list (raw =). Thefstab(5) man page
contains additional information.

If you have already mounted the file system as described in Section 7.2.1, you can use
the mount command to determine the appropriate /etc/fstab entry. For example:
mount -p

This command displays all currently mounted file systems, including the new file
system in /etc/fstab format. Copy the line that describes the new file system
to /etc/fstab.
The mount command reads /etc/fstab sequentially; therefore, file systems that are
mounted beneath other file systems must follow their parent partitions
in /etc/fstab in order for their mount points to exist.
The swap partition on the system disk (partition 1) is not listed in /etc/fstab.
However, additional swap partitions added to the system are listed. For swap
partitions, the mount point field is not used. See the swap(8) man page for more
information.
See the fstab(5) man page for more information about /etc/fstab entries.

7.2.3. Mounting a Remote File System Automatically
With NFS software, you can automatically mount any remote file system whenever it
is accessed (for example, by changing directories to the file system with cd). The
remote file system must be exported with the exportfs command.

For complete information about NFS, see the UNICOS/mp Networking Facilities
Administration.
For complete information about setting up automounting, including all the available
options, see the automount(8) and exportfs(8) man pages.

7.2.4. Unmounting File Systems
File systems are automatically unmounted when the system is shut down. To manually
unmount file systems, use the umount command. The three basic forms of the
command are shown in Table 7-1. Local file systems can be unmounted with either of
the first two forms shown in the table; they are equivalent. Similarly, the first and
third forms are equivalent for remote file systems.
Table 7-1. Forms of the umount Command
Command

umount

mount_point_directory

umount

device_file

umount

host :directory

umount -a

For example, to unmount a local or remote file system mounted at
command:

/d2,

give this

umount /d2

To unmount the file system on the partition /dev/dsk/dks0d1s7, give this command:
umount /dev/dsk/dks0d1s7

To unmount the remote-mounted (NFS) file system depot:/usr/spool/news, give this
command:
umount depot:/usr/spool/news

To be unmounted, a file system must not be in use. If it is in use and you try to
unmount it, you get a Resource busy message. Error messages and their solutions are
explained in the umount(8) man page.
Prev Section
Maintaining XFS File Systems

Table of Contents | Title
Page | Index
Up one level

Next Section
Managing Disk Space

4.7.2. Using mount(8)

File systems are mounted using mount(8). The most basic syntax is as
follows:
# mount device mountpoint

This command provides many options which are described in mount(8), The
most commonly used options include:
Mount Options
-a

Mount all the file systems listed in /etc/fstab, except those marked
as “noauto”, excluded by the -t flag, or those that are already mounted.
-d

Do everything except for the actual mount system call. This option is
useful in conjunction with the -v flag to determine what mount(8) is
actually trying to do.
-f

Force the mount of an unclean file system (dangerous), or the
revocation of write access when downgrading a file system's mount
status from read-write to read-only.

-r

Mount the file system read-only. This is identical to using -o

ro.

-t fstype

Mount the specified file system type or mount only file systems of the
given type, if -a is included. “ufs” is the default file system type.
-u

Update mount options on the file system.
-v

Be verbose.
-w

Mount the file system read-write.
The following options can be passed to -o as a comma-separated list:
nosuid
Do not interpret setuid or setgid flags on the file system. This is also a
useful security option.
4.7.3. Using umount(8)

To unmount a file system use umount(8). This command takes one parameter
which can be a mountpoint, device name, -a or -A.
All forms take -f to force unmounting, and -v for verbosity. Be warned that f is not generally a good idea as it might crash the computer or damage data
on the file system.
To unmount all mounted file systems, or just the file system types listed after t, use -a or -A. Note that -A does not attempt to unmount the root file system.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close