One of the most important goals of system
administration is to protect the integrity of the valuable data on
a system. There are several aspects to this (for example, securing
the system against intruders, and protecting the system's data against
deliberate or accidental removal). Many things (for example device
failure) can cause data loss, and there are many tools to insure you
can recover valuable data in the event of a loss of the primary copy:
- Data Backups
By making copies of disk-based data onto external
media that you can store away from your system, you ensure that you
can recover the data should something happen to your primary copies.
Data can also be shipped over a network to a computer at a different
location. The important thing is to have copies of all your important
data somewhere other than on your system. To protect against loss
from flood, fire, or other disasters, you should store at least one
copy of all important data in a location other than where your system
The term data backup usually refers to the act of making an offline copy of the data
- Disk Mirroring
By making multiple identical copies of all data as
they are written, you ensure that you can recover/access data (from
a mirror copy) in the event a device fails and the copy of that data
that is on it is destroyed.
Redundant Arrays of Independent Disks are another
form of mirroring data.
HP sells a product called Serviceguard specifically
designed to protect not only disk based data, but also all aspects
of your computing environment, minimizing the downtime that can result
from the loss of use of a specific server or some of its peripherals.
This section deals with data backups. For
additional information on the other ways of protecting your data (mentioned
above), see Appendix A.
There are many utilities to back up your
data to offline media (for example, optical media or magnetic tape
such as DLT cartridges).
Table 3-3 compares several commonly used utilities based
on many important backup criteria. This discussion focuses on the
file backup and file recovery procedures of fbackup, OmniBack II, tar, and cpio. Online backup of a JFS snapshot file system is also explained.
Refer to the HP-UX Reference for information on the other backup and
restore utilities: dump, ftio, pax, restore, rrestore, vxdump, and vxrestore.
The following topics are described in this section:
Choosing the Type of Storage Device
When you evaluate which media to use to back up
your data, consider the following:
How much data do you need
to back up (rough estimate)?
How quickly will you need
to retrieve the data?
What types of storage
devices do you have access to?
How automated do you want
the process to be? (For example, will an operator be executing the
backup interactively or will it be an unattended backup?)
How quickly will you need
to complete a backup?
|NOTE: To ensure against the possible destruction of
your system and its data, store the backup media away from your system.|
Use Table 3-2: “Criteria for Selecting Media ” to help you determine which
storage device to use for your backups. This table compares the supported
device types relative to each other; it does not give specific values.
For detailed information, consult the documentation that came with
your tape or disk drive for capacity information about the storage
Table 3-2 Criteria for Selecting Media
Storage Device Type
Holds Lots of Data?
Recovers and Backs Up Data Quickly?
Suggested for Unattended Backup?
|DLT tape drive||Excellent||Excellent|
|DLT tape library||Excellent||Excellent||Yes|
DDS format (DAT) tape drive
DDS format (DAT) tape drive
Optical disk multi-disk library
Optical disk single drive
Choosing a Backup/Recovery Utility
There are a number of different backup methods
you may wish to choose from depending on your system backup needs
and your workgroup configurations. Some recommended backup methods
HP SMH (System Management
HP-UX fbackup/frecover utilities
Choosing HP Omniback for Backup
If you are backing up large
numbers of systems, the HP Omniback II software product can be particularly
useful. HP Omniback II is faster than other backup methods and provides
for unattended backup as well. It allows you to efficiently centralize
and administer backup procedures.
Using HP Omniback II involves setting up a database
server and running Omniback software that directs and records the
backup process for clients.
For a detailed description, see the HP OpenView Omniback II Administrator’s Guide.
Choosing an HP-UX Backup/Recovery Utility
Table 3-3 compares
several HP-UX backup utilities based on selected tasks. For details
about specific commands, see the associated manpage.
Table 3-3 A Comparison of HP-UX Backup/Recovery Utilities
from tape errors
Minimal data loss.
resync option causes some data loss.
Skips over bad tape.
over bad tape.
use of tape
restore across a network
files to the same backup tape
the no-rewind device file to append multiple dumps.
Use tar -r.
With dump, can use the
no-rewind device file to append multiple dumps. 
With vxdump, can use the no-rewind device file to append multiple dumps. 
independent backups on a single tape
Not possible (fbackup rewinds
Use mt with no-rewind device to position the tape, then use cpio.
Use mt with no-rewind device to position the tape, then use tar.
Use mt with no-rewind device to position the tape, then use dump. 
Use mt with no-rewind device to position
the tape, then use vxdump. 
the files on the tape
Complex (must search
Complex (must search
entire backup). 
backup (Also see the above entry.)
Use the -xNv options.
a particular file
Relatively easy; use frecover.
Complex (Wildcards are allowed; searches the entire
Complex (Wildcards not allowed; searches the entire tape.)
Relatively easy; interactive commands available. 
interactive commands available. 
an incremental backup
Has a powerful multilevel backup.
Use find to locate new or modified files.
Use the -u option
to add any new or modified files to the end of archive.
Possible on a single file system only.
Possible on a single file system
files as they are backed up or restored
Possible. Use -v option.
Possible. Use -v option.
Possible. Use the -v option. 
Possible (on a
restore only). 
Possible (on a
restore only). 
a backup based on selected criteria (such as group)
Possible. Use find.
disk or file system boundaries
Use fbackup -n to cross NFS boundaries.
Possible. Use find.
absolute path names to relative location
Relative to the current directory. Use -X option.
Can specify path name on each file with cpio -ir.
Relative to the current directory. Use restore -r.
to the current directory. Use vxrestore -r.
decide on files to restore
Not possible. 
Can specify path
or name on each file with cpio -ir.
“Yes” or “no”
answer possible using tar -w.
In interactive mode, can specify which files.
In interactive mode, can specify
wildcards when restoring
Only in interactive mode.
Only in interactive mode.
of selecting files for backup from numerous directories
up a snapshot file system
restore extent attributes
Determining What Data to Back Up
To restore your system after a complete loss of
data, you will need copies of the following:
system files that you
have customized (such as /etc/passwd)
system files that you
have added since your original installation
any additional products
that were installed since your original installation
Defining What Files and Directories to Back Up
If you are backing up using the fbackup command, you must define which directories and files you want to
- Included Files
Included files are directories
and files to include in your backup. When you specify a directory,
all of the files and subdirectories are included in the backup. Identify
included files with the -i option of the fbackup command or with a graph file (see following definition).
- Excluded files
Excluded files are files
within your included directories to exclude from the backup. In other
words, they are the exceptions. Identify excluded files with the -e option to the fbackup command or with
a graph file (described below)
- Graph files
Graph files are text files
that contain a list of directories and files to back up. If you use
HP SMH to back up your system, HP SMH creates the graph files for
you (in /etc/sam/br) using the included and excluded
files. Graph files contain one entry per line. Entries that begin
with the character i indicate included files; those that begin with the character e indicate excluded files. For example:
The above file will cause all of the directory /home with the exception of /home/deptD to be backed up.
You can identify a graph file with the -g option of the fbackup command.
Determining How Often to Back Up Data
Evaluate the applications running on your system
and the needs of your users to determine how critical the data on
your system is to them. Consider the following:
How often do the contents
of files change?
How critical is it that
files’ contents be up-to-date?
Full Backups vs. Incremental Backups
Once you have identified a list of files to include
and exclude, decide whether you want all of the
files represented by your list to be backed up (a full backup) or only those files that have changed or
that have been created since the last time you backed up this set
of files (an incremental backup).
A backup level is a level you define that identifies
the different degrees of incremental backups. Each backup level has
a date associated with it that indicates when the last backup at that
level was created. You can have up to ten backup levels (0 through
9). For example, level 0 is a full backup; level 1 backs up files
that changed since the last level 0 backup; level 2 backs up files
that changed since the last level 1 backup, and so on.
This brings up the question, “how does fbackup know when the previous backup was created?”
This information is contained in the file /var/adm/fbackupfiles/dates, a file that is updated only when all of the following conditions
The -u option is used with fbackup.
A graph file is used to
indicate which files should be included/excluded when a backup is
Neither the -i nor the -e option is used (graph file used instead)
The backup completed successfully
Backup levels are a way of specifying varying
degrees of incremental backup. For example, suppose you wanted to
set up the following backup schedule:
On the first day of the
month, back up an entire set of selected files (a monthly, full backup).
Every Friday, back up
all files in the selected set that have changed since the previous
Friday (a weekly, incremental backup so that you can back up and restore
files that have been active within the month, relatively quickly).
Every day except Friday
(or the first of the month), back up all of the files in the selected
set that have changed since the previous day (a daily, incremental
backup, so that you can quickly back up and restore files that have
been active within the last week).
There are three “layers” (levels)
associated with the above schedule (the once per month level, the
once per week level, and the once per day level). The once per month
level is a full backup. The other two are incremental backups. The
problem is how to distinguish between the two types of incremental
backup. This is accomplished with backup levels.
The file /var/adm/fbackupfiles/dates contains information about when the last backup at each backup level
was performed. This information is used by fbackup, along with the modification date stamps on the files themselves,
to determine which files in the specified set are to be included with
the backup that is currently being created.
As previously stated, you can have up to 10 backup
levels. When you run fbackup, you can tell it which
level to use. fbackup will use the level you give
it as follows:
Level 0 is always considered
a full backup
Higher levels are generally
used to perform incremental backups.
When doing an incremental
backup of a particular graph (specified by a graph file name), at
a particular level, fbackup will search the file
/var/adm/fbackupfiles/dates to find the date
of the most recent backup of the same graph that was done at a lower
level. If no such entry is found, the beginning of time is assumed.
All files in the specified graph that have been modified since this
date are backed up
Example of Setting Backup Levels
Assume you want the following three backup levels:
Level 0 - full monthly backup
Level 1 - weekly backup on Friday
Level 2 - daily backup, except Friday
There are three ways you can implement these levels:
use HP SMH, enter the fbackup command and specify
a backup level on the command line, or automate the commands (see “Setting Up an Automated Backup Schedule”). The figure below
illustrates the level numbers for implementing this example.
Date: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ... 1
Day: Su M T W Th Fr Sa Su M T W Th F Sa Su ...
Backup level 0 2 2 2 2 1 2 2 2 2 2 2 1 2 2 ... 0
If your data becomes corrupt on Thursday the 12th,
do the following to restore your system to its Wednesday the 11th
Restore the monthly full
backup tape from Sunday the 1st.
Restore the weekly incremental
backup tape from Friday the 6th.
Restore the incremental
backup tape from Wednesday the 11th.
For information on the actual method and commands
to restore these tapes, see “Restoring Your Data”.
Backing Up Your Data Using the fbackup Command
The /usr/sbin/fbackup command
is the recommended HP-UX backup utility. The fbackup command can do the following:
indicate specific files
or directories to include or exclude from a backup
specify different levels
of backup on a daily, a weekly, or monthly basis
create an online index
when used in conjunction
with the crontab utility can automate backups
|NOTE: As fbackup does its work, it
will not back up files that are active (open) when it encounters them.
For this reason, it is best to back up your system when there are
few or no users logged in. If you can do so, you should change your
system’s run-level to the system administration state (single-user
mode) before using fbackup. This will insure that
you are the only one logged in when the backup is run. As a result,
a minimum number of files will be active, thereby reducing the number
of files that are intended for, but not included in, the backup.|
When changing to the single-user state, all the
subdirectories are unmounted. Therefore, you must remount them if
necessary before backing up. For information about changing to the
single-user state, see shutdown(1M). If you shut down the system
to single-user state, mount the file systems (other than root (/)) that you want backed up.
General Procedure for Using the fbackup Command
To use the fbackup(1M) command:
Ensure that you have superuser
Ensure that files you
want to back up are not being accessed. The fbackup command will not back
up files that are active (opened) or locked.
Verify that the backup
device is properly connected.
Verify that the backup
device is turned on.
Load the backup device
with write-enabled media. If the backup requires additional media, fbackup will prompt you when to load or change media.
If possible, change to
a single-user state. Then mount any directories you want to back up.
Create the backup using fbackup. For example, the
fbackup -f /dev/rmt/0m
can be used to back up the entire contents of /home to the device file /dev/rmt/0m. For more information on fbackup, see fbackup(1M). For more information on the /dev file formats, see the Configuring HP-UX for Peripherals manual and see mt(7).
Creating the Index File on the Local Device
If you use the fbackup command, an index is written
at the beginning of each tape listing all files in the graph file
being backed up. However, since this index is written before the files are actually backed up, if a file is removed after the index is written but before the file is backed up to tape (or something else happens that prevents
the file from being backed up), the index will not be completely accurate.
If you tell fbackup to make
an online index file (using the -I option), it will
create the file after the backup is complete.
Therefore, the only index that will be accurate is the online index,
which is produced after the last volume has been written (the index
created using the fbackup -I option).
Also, fbackup assumes all files
remaining to be backed up will fit on the current tape for the index
contained on that media. Therefore, if you did not use the -I option on fbackup or removed the index
file, extract an index from the last media
of the set.
Use the /usr/sbin/frecover utility
to list the contents of the index at the beginning of a backup volume
made with fbackup. For example, the command
frecover -I /tmp/index2 -f /dev/rmt/0m
specifies that the device file for the magnetic
tape drive is /dev/rmt/0m and you want to put
the listing of the index in the file /tmp/index2.
Backing Up NFS Mounted Files with fbackup
When backing up files that
are NFS mounted to your system, fbackup can only
back up those files having “other user” read permission
unless you have superuser capability. (To recover the files, you will
need “other user” write permission.) To ensure the correct
permissions, log in as superuser on the NFS file server and use the root= option to the /usr/sbin/share command
to share the permissions, then back up as root. For more information, see share(1M) and the NFS Administrator’s
Examples of fbackup Commands
Here are a series of examples showing a variety
of ways that fbackup can be used.
Example: Backing Up to a DDS (DAT) Tape
For this example, we want to do a full backup
and do not care about doing future incremental backups. Therefore,
we do not need to specify a backup level (nor do we need to use the -u option to update the dates file).
We could also specify “level 0” to indicate a full backup.
fbackup -i /home
Example: Backing Up to a DLT Tape
(You plan to do a future incremental backup.)
This example will back up the entire structure except
the invoices directory. The device file for this
example is /dev/rmt/1h, specified using the -f option. For this example, we need to plan for the incremental
backup (next example), so we must do three things:
Use a graph file to specify
which files will be included/excluded.
Specify the -u option to update the file /var/adm/fbackupfiles/dates.
Specify a backup level.
Because this will be a full backup, we’ll
use the backup level 0. Any backup level would do as long as it is
the lowest backup level in use. See “Backup Levels” for details about how backup levels
are interpreted by fbackup.
The graph file for this example will be /var/adm/fbackupfiles/graphs/g1 and its contents will
The fbackup command to accomplish
the above is:
fbackup -f /dev/rmt/1h -0 -u -g /var/adm/fbackupfiles/graphs/g1
Example: Incremental Backup to a DLT Tape
This example is an extension of the previous one.
All characteristics of the previous example will remain the same except
that this will be an incremental backup at a point in time following
the previous example’s backup.
We’ll use the backup level 5. The exact
number is not critical as long as it is higher than the level used
in the previous example. See “Backup Levels” for details about how backup levels
are interpreted by fbackup.
fbackup -f /dev/rmt/1h -5 -u -g /var/adm/fbackupfiles/graphs/g1
Example: Backing Up to Two Devices
This example will show how it is possible to specify
more than one device to receive the output from fbackup. When more than one device is specified, the second one is written
to when the media on the first device has filled up. If the media
on the first device fills up and the remaining data to be backed up
will fit on the media on the second device, an unattended backup is
possible. With only one device, a media change would be required in
Also in this example, an index file will be created
called /tmp/index. An index is written to the
beginning of each tape, listing all files in the specified “graph”
being backed up. However, if a file is removed after the index is
written but before the file is backed up to tape (or something else
happens that prevents the file from being backed up), the index will
not be completely accurate. If you tell fbackup to make an online
index file (using the -I option), it will create
the file after the backup is complete. Therefore, the online index
file will be completely accurate with respect to which files are on
each volume of the backup.
For example to back up every file on the entire
system to the two magnetic tape drives represented by device files /dev/rmt/0m and /dev/rmt/1m, enter:.
fbackup -f /dev/rmt/0m -f /dev/rmt/1m -i / -I /tmp/index
You would typically use both tape drives in the
same tape density mode.
Backing Up Files on a Remote System
If you are administering a workgroup,
it is likely that only some of the systems in the workgroup will have
storage devices such as tape drives or optical disk drives attached
locally. In this situation you will need to perform remote backups.
Remote Backup Using fbackup
To perform a remote backup using fbackup, enter:
#fbackup -f system-name:/dev/rmt/0m -v -i /dir1
For information on recovering files remotely using
the frecover command, see “Restoring Your Data”.
find . -hidden -depth -fsonly hfs -xdev \
| cpio \ -ovxcB2>/tmp/index \
| remsh system-name -l user \
"cat - | dd of=/dev/rmt/0m obs=5k"
If the relative path is root (/), then you will perform a full backup. The /tmp/index file is an index file of the backup. The -v option
causes the output to be written to standard error.
Note that cpio via network
does not support multiple tapes.
To perform a remote backup using tar, enter:
tar cvf - . | remsh remote-system dd of=/dev/rmt/0m
For information on restoring files remotely using
the tar command, “Restoring Your Data”.
Setting Up an Automated Backup Schedule
If possible, use HP SMH to
set up an automated backup schedule.
If you use HP-UX commands, you can automate your
backup procedure using the crontab utility, which
uses with cron, the HP-UX process scheduling facility.
For details, see cron(1M) and see crontab(1).
|NOTE: If you schedule fbackup using
the crontab utility, be aware that fbackup is an interactive utility. If fbackup needs attention
(tape change, device not online, and so on), it will prompt for input.
If the input is not provided, an automated backup may fail or not
Creating an Automated Backup Schedule
Use the crontab utility to specify
an input file containing information about the backup procedures you
want to automate. The crontab utility allows you
to specify an input file containing the date, time, and run-strings
of the backup procedures (processes) that you want to automate. This
file (the input to the crontab utility) contains
lines that have six required fields each. The fields are separated
by spaces or tabs. Each entry in this file has the following format:
minutes hours dates months days runstring
Specifies the minutes
of the hour (0-59)
Specifies the hours of
the day (0-23)
Specifies particular dates
of the month (1-31)
Specifies particular months
of the year (1-12)
Specifies particular days
of the week (0-6 with 0 representing Sunday)
Specifies the command
line or script file to execute
Therefore, to schedule the ps command (see ps(1)) to execute at 5:10 p.m. (17:10)
on every Friday and Monday during June, July, and August, you would
make an entry in your crontab input file that looks
10 17 * 6,7,8 1,5 ps >> /tmp/psfile 2>&1
When using crontab, redirect
any output that is normally sent to the terminal to a file. In this
example, 2>&1 redirects any error
messages to the file psfile.
An example backup strategy may consist of a full
backup (performed once per week) and an incremental daily backup.
Assume that the backups are to be performed at 4:03am and the media
is DDS (DAT) tape. The following crontab file implements
the example backup strategy:
3 4 * * 1 incrback >> monbackup
3 4 * * 2 incrback >> tuebackup
3 4 * * 3 incrback >> wedbackup
3 4 * * 4 incrback >> thubackup
3 4 * * 5 incrback >> fribackup
3 4 * * 6 fullback >> satbackupfull
In the above example incrback and fullback are example shell scripts. Be sure
to set the PATH variable appropriately or use complete
paths to any scripts that you include in the crontab input file. Scripts like these may be used to:
Warn any users who are
logged in that the system is going down (for backup purposes).
Shutdown the system (to
single user mode).
Mount any file systems
that you wish to back up.
Run fbackup to perform the actual backup.
Return the system to multiuser
The output redirection can be specified in the crontab input file or within the script contained in the crontab input file.
|TIP: To edit
the crontab input file directly, use the crontab -e option.|
Displaying an Automated Backup Schedule
To list your currently scheduled processes, enter:
This displays the contents of your activated crontab input file.
Activating an Automated Backup Schedule
Before you activate a new crontab input file, you should view the currently scheduled processes (see “Displaying an Automated Backup Schedule”). Consider adding
these processes to your crontab input file.
To activate all of the processes defined in your crontab input file and cancel any previously scheduled
processes not defined in your crontab input file,
After your crontab backup has
been activated, make sure that:
The system clock is set
The backup device is properly
connected and the HP-UX I/O system recognizes the device file specified
in the fbackup run string.
Adequate media has been
loaded in the backup device.
The backup device is connected
to your system and is turned on.
The NFS mounted files
you want backed up have the correct permissions. See “Backing Up NFS Mounted Files with fbackup” for more information.
Backing Up If You Are Using LVM
you are running LVM, you must maintain the backup configuration files
for each volume group. After making changes to the configuration of
the disks or the logical volumes within a given volume group, the vgcfgbackup command is run automatically to record the
group’s configuration (vgcfgbackup saves
the configuration of each volume group in /etc/lvmconf/volume_group_name.conf).
To ensure recovery of LVM information following
disk corruption, you must back up both the /dev and /usr directories. Include
the /usr directory in the root volume group during
your backup. If, however, the /usr directory
was not originally part of the root volume group, you can still create
a new logical volume in the root volume group and move the /usr directory within it.
For information on saving volume group configuration
information using vgcfgbackup, see HP-UX
System Administrator’s Guide: Logical Volume Management.
Backing Up Large Files
A large file is defined as one whose size is greater than
2 GB. See the HP-UX Large Files White Paper Version 1.4 for more information.
Backup Utilities that Support Large Files
The following backup utilities will back up large
Neither of the preceding commands require any
user intervention to backup large files.
Backup Utilities that Do Not (fully) Support Large Files
The following backup utilities do not support large files:
Supports files <8GB
Does not support large
files (>2GB) and cannot process cpio archives containing large files
written by pax)
Supports files <8GB
in size for ustar and cpio formats, (but will support any size file in pax format).
Does not support large
Attempts to back up any files greater than 2 GB
using the preceding utilities will fail.
If you use fbackup to back up large
files (> 2 GB), then those files can only be restored on a large file
system. For instance, suppose that you back up a file system containing
large files; you cannot restore those files to a file system that
is not enabled for large files.
If a backup contains large files and an attempt
is made to restore the files on a file system that does not support
large files, the large files will be skipped.
Backing Up a JFS Snapshot File System
|NOTE: Creating and backing up a JFS snapshot file system
requires that you have the optional HP OnLineJFS product installed
on your system.|
The Journaled File System (JFS)
enables you to perform backups without putting the file system off-line.
You do this by making a snapshot of the file system, a read-only image
of the file system at a moment in time. The primary file system remains
online and continues to change. Once you create the snapshot, you
back it up with any backup utility except dump.
How to Create and Back Up a JFS Snapshot File System
Determine how large the snapshot file system needs to
be, and create a logical volume to contain it.
Use bdf to assess the primary file system size and consider the following:
Block size of the file
system (1024 bytes per block by default)
How much the data in this
file system is likely to change (15 to 20% of total file system size
For example, to determine how large to make a
snapshot of lvol4, mounted on /home, examine its bdf output:
# bdf /home
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol4 40960 38121 2400 94% /home
Allowing for 20% change to this 40 MB file system,
you would want to create a logical volume of 8 blocks (8 MB).
Uselvcreate to create a logical volume to contain the snapshot file system.
lvcreate -L 8 -n lvol1 /dev/vg02
creates an 8 MB logical volume called /dev/vg02/lvol1, which should be sufficient to contain
a snapshot file system of lvol4.
See lvcreate(1M) for syntax.
Make a directory for the
mount point of the snapshot file system.
Make and mount the snapshot
In the following example, a
snapshot is taken of logical volume /dev/vg00/lvol4, contained in logical volume /dev/vg02/lvol1, and mounted on /tmp/house:
mount -F vxfs -o snapof=/dev/vg00/lvol4 \
See mount_vxfs(1M) for syntax.
Back up the snapshot file
system with any backup utility except dump.
For example, to use tar(1) to archive
the snapshot file system /tmp/house, ensuring
that the files on the tape will have relative path names:
cd tmp; tar cf /dev/rmt/0m house
Alternatively, the following vxdump(1M) command backs up a snapshot file system /tmp/house, which has extent attributes:
vxdump -0 -f /dev/rmt/0m /tmp/house