One of the more common tasks of a system administrator is helping users recover lost or corrupted files. To perform that task effectively, you must set up procedures for backing up files at frequent and regular intervals. This chapter discusses how to back up and restore files, and describes the following tasks:
Backing up data
Choosing a backup schedule
Performing a full backup
Performing an incremental backup
Performing a remote backup
Using backup scripts
Restoring data
Restoring a file system
Restoring a file system on a new partition
Restoring files
Restoring files interactively
Performing remote restores
Note
You can also use the SysMan
dxarchivercommand to perform some of these tasks.
The Tru64 UNIX operating system has other facilities you can use to back up and restore files:
NetWorker SingleServer Save and Restore
A component of Tru64 UNIX, used for single system archiving, and packaged as an optional subset to the operating system
POLYCENTER NetWorker Save and Restore
A separately licensed product, used for networked systems archiving
The
btcreate
and
btextract
utilities
You can use these utilities to create and restore standalone, bootable tapes of the operating system and file systems.
These capabilities are briefly surveyed in the following sections. Then, the archiving tasks are described.
NetWorker SingleServer Save and Restore is a graphical interface that enables you to back up and recover local files on a single machine to a local tape or loader. NetWorker SingleServer is shipped with preconfigured settings that provide you with the ability to start backing up files immediately.
With the command-line utilities, a user must know what utility (
tar,
cpio,
dump/restore, or
vdump/vrestore) was used to perform a backup in order to restore
information from the archive.
NetWorker SingleServer eliminates the need to
know what utility was used to perform the backup.
The NetWorker SingleServer utility offers the following features:
Preconfigured settings
Templates for electronically labeling tapes
Ability to perform unattended backups
Five backup schedules
Five preconfigured policies for managing backed-up files
Two preconfigured directives that assist you in streamlining backups
Notification of NetWorker activity
Easy recovery of files
Network SingleServer is licensed free of charge with the Tru64 UNIX base operating system. It can be easily upgraded to provide backup and archive services to a group of systems in a heterogeneous environment. The full NetWorker Save and Restore product allows you to back up and restore files in a distributed environment.
NetWorker Save and Restore consists of both server and client software.
You must register a NetWorker license PAK in the license database to use the
full product.
Additional prerequisite or optional software licenses may also
be required.
NetWorker Save and Restore Version 4.4 adds support for cluster
server failover.
In the Available Server Environment (ASE), you can configure
the cluster members to allow the NetWorker server to migrate between the members
by defining NetWorker as a highly available application.
By installing the
NetWorker Server on each cluster member and configuring cluster members as
NetWorker servers, NetWorker will automatically fail over as directed by the
ASE manager.
NetWorker subsets are available on the Associated Products,
Volume 2 CD-ROM in the following subsets, where
***
is
the release number, such as 440:
Release Notes and Documentation (BRXRNOTES***)
Server for Tru64 UNIX (BRXSOAKIT***)
Tru64 UNIX Client (BRXCKIT***)
Reference Pages (BRXSMAN***)
All subsets are applicable to NetWorker SingleServer except
for
BRXCKIT***.
See the NetWorker Save and Restore for Tru64 UNIX
Software Product Description (SPD xx.xx) for a complete description of features.
You can create a bootable Standalone System (SAS) kernel on tape. The SAS kernel has a built-in memory file system (mfs), which contains the minimum commands, files, and directories needed to restore the system image. This is referred to as the miniroot file system.
To create the SAS kernel, you must use the
btcreate
utility.
Once you have created the kernel, you can restore the customized
image using the
btextract
utility.
The following sections
provide an overview of the
btcreate
and
btextract
utilities.
For information on syntax and examples, see the reference
page for each utility.
The following restrictions apply to creating bootable standalone system kernels on tape:
Although 32 MB memory configurations are no longer supported with this
release, you may want to create bootable tapes for such configurations running
previous versions of Tru64 UNIX (Digital UNIX).
In this case, note that
bootable tape will not function with the
-m mfs
option
for the
btcreate
command on systems with 32 MB memory configurations.
After booting the kernel from tape, commands that use shared libraries will
core dump if you attempt to use this option.
Use the
-m ufs
option while creating the tape on systems with 32 MB memory configurations.
Bootable tape does not support the bootable kernel built with the
/usr/sys/conf/GENERIC
kernel configuration file.
Be sure to use
a system-specific custom kernel.
Cross-platform bootable tapes are not supported. Using a bootable tape on a platform other than the one on which it was created is not supported. For example, you cannot create a tape on a 4100 system and boot from it on a 1000A system.
To build a bootable SAS kernel on UFS or AdvFS file systems only, you
must use the
btcreate
utility.
This section provides an
overview of the information you must have to create the SAS kernel on tape.
The
btcreate
utility provides both a noninteractive
and interactive user interface.
Both require that you have superuser privileges
before using.
To execute, this utility requires 156000 blocks (512 bytes
per block) of disk space in the
/usr
directory.
To prepare for a
btcreate
session, you must have
the following information available:
Name of the configuration file in the
/usr/sys/conf
directory.
Name of the disk partition (for example,
rz2e)
where the miniroot file system is to reside.
Minimum size needed on the disk
is 30720 blocks (512 bytes per block).
This disk partition should not be
mounted when
btcreate
is executed.
Name of the tape device, for example
nrmt0h,
where the SAS kernel and file systems are to reside.
Device name, mount point, and type of each file system (UFS or AdvFS) that you want to back up to the tape device. The following shows valid UFS and AdvFS entries:
UFS:
/dev/rz1a / ufs /dev/rz1g /usr ufs
AdvFS:
root_domain#root / advfs usr_domain#usr /usr advfs
Note
Do not select swap partitions for file system backups.
An addlist_file, which lists the files or directories you want to include on the miniroot file system.
An fslist_file, which specifies the file systems to back up.
A
/usr/lib/sabt/sbin/custom_install.sh
script, if you want to customize the restored system image.
The file must
be written in the Bourne shell language (sh1) as it is
the only shell provided on the miniroot file system.
The
btcreate
utility copies the
custom_install.sh
file onto
tape and places it in the
sbin
directory on the miniroot
file system.
The
btextract
utility invokes the
custom_install.sh
script before exiting.
To create the SAS kernel, the
btcreate
utility copies
the
/usr/sys/conf/YOUR_SYSTEM_NAME
configuration file to
/usr/sys/conf/YOUR_SYSTEM_NAME.BOOTABLE
and modifies it as follows:
config vmunix root on md pseudo-device memd 30720
These modifications indicate that a memory file system of 30720 is being configured. The memory file system and the disk partition where the miniroot file system reside are equivalent in size.
After modifying the configuration file, the
btcreate
utility executes the
doconfig
command and moves the bootable
kernel to the
/usr/sys/bin
directory.
For information on
syntax format and flags, see the
btcreate
reference page.
When selecting disk partitions while restoring file systems from tape, add 5 percent to the needed file size displayed on the console.
To use the
btcreate
utility, your system must have
at least 156,000 512-byte blocks of free space in the
/usr
directory.
You will not have enough space if your system uses an RZ26 (or
smaller disk) with the default partitions when you have installed all of the
subsets and kernel options.
To overcome this limitation, you can reclaim
the required space by removing some subsets or by creating and mounting new
partitions.
The following steps show you how to create and mount new partitions
for a UNIX file system (UFS).
If you prefer to use AdvFS, use the
mkfdmn
and
mkfset
commands.
Run the
newfs
command to re-create a new
partition, as shown in the following example for system FLAWLESS:
#newfs /dev/rz1d
Change the current working directory to the
/usr/sys
directory:
#cd /usr/sys
Make a
SYSTEM.BOOTABLE
directory under
the
/usr/sys
directory, where
SYSTEM
is the system name
FLAWLESS:
#mkdir FLAWLESS.BOOTABLE
Mount the new partition on the SYSTEM.BOOTABLE directory:
#mount /dev/rz1d /usr/sys/FLAWLESS.BOOTABLE
The mounted device should have at least 75,000 512-blocks available
Create another new partition:
#newfs /dev/rz1b
Mount the partition:
#mount /dev/rz1b /mnt
Change the current working directory to/usr/sys/bin.
Copy the contents of the
/usr/sys/bin
directory
to the
/mnt
directory:
#cp * /mnt
Unmount the
/mnt
directory:
#umount /mnt
Mount the new partition on
/usr/sys/bin
as follows:
#mount /dev/rz1b /usr/sys/bin
After completing these steps, your system should have the necessary
space to run
btcreate.
If you are using AdvFS, the
/usr/sys/bin
file system must be copied during the
btcreateprocedure, to copy the entire contents of the
/usr
file system.
The
btextract
utility is a shell script that restores
file systems from tapes that contain the bootable Standalone System (SAS)
kernel.
The SAS kernel is created using the
btcreate
utility.
You have the option of performing a DEFAULT restore or an ADVANCED restore
of the system.
Performing a DEFAULT restore, you can duplicate the customized system
on more than one machine of the same hardware platform type; however you cannot
specify which disk partitions to use for the restore operation.
Instead, the
btextract
utility restores file systems using the disk partition
information gathered during the
btcreate
session; all existing
information is overwritten.
Performing an ADVANCED restore, you can specify which disk partition to use, but the customized system can only be duplicated on a machine of the same hardware platform type.
To use the
btextract
utility, place the system in
a halt state, initialize the system, then boot from the tape as follows:
>>> init >>> show dev >>> boot -fl "nc" MKA500
In the previous example, the
show
dev
command provides the device name under BOOTDEV and
MKA500
is the BOOTDEV.
After the initial boot is complete, the shell invokes the
btextract
utility.
If you created a
/usr/lib/sabt/sbin/custom_install.sh
script during the
btcreate
session, the
btextract
utility invokes the
custom_install.sh
script before exiting.
See the
btcreate
reference page
for more information.
After the
btextract
utility completes its task, you
must shut down the system, then reboot the system from the restored disk as
follows:
# shutdown -h now >>> boot DKA100
In this example,
DKA100
is the BOOTDEV.
For more information and examples, see the
btextract(8)
reference
page.
The following sections describe restrictions and requirements.
When using QIC tape drives to create bootable tapes, you must use only high-density tapes of 320 or more megabytes. The QIC-24, QIC-120, and QIC-150 format tapes of fixed-512 blocks will not work. Tapes with a variable block size, such as the QIC-320 and QIC-525, will work with bootable tape. Using an improperly configured QIC tape drive to create a bootable tape will result in an I/O error, a write error, or permission denied error. Therefore, you must take one of the following actions:
Configure the drive at installation time
Rebuild the kernel if the drive was attached to the system after the installation
A QIC tape created with the
btcreate
utility
may fail with the following error when booted:
failed to send Read to mka... /
Be sure that the tape is write protected before booting.
If you are creating a bootable tape with a UFS file system that extends
to multiple tapes, the
/sbin/dump
command displays a message
indicating that the tape must be changed.
If the tape is not changed promptly,
warning messages repeat periodically until the tape is changed.
When you
change the tape, the warning messages stop.
The behavior of the open call to a tape device has changed. You can no longer use write mode to open a write-protected tape. The attempt to open the tape will fail, returning the following message:
EACCES (permission denied)
If an application is written so that it attempts to open the tape
device with
O_RDWR
when the intention is only to read the
tape, the open attempt will fail.
Applications should be changed to open the
device with
O_RDONLY.
For applications that cannot be changed,
use the following command to obtain the previous behaviour of the open call:
#sysconfig -r cam_tape open_behaviour=0
For this release, bootable tape will not work with the LSM product. The following processor platforms are supported:
DEC 3000-500, 3000-400, 3000-300, 3000-600, 3000-300X, and 3000-900
DEC 2100
AlphaStation 200, and 600
AlphaServer 1000A, 2100, 4100, 8200(ev5) , and 8400(ev5). The minimal revision of console firmware for the 8200 and 8400 is version 5.2.
For tape drives, you must ensure that the kernel was built with the tape drive connected to your system. If the drive was not connected when the kernel was built, you will see dump errors and the system will not be able to boot from the tape drive. The following tape devices are supported:
TLZ06, 4mm, 2.0GB/4.0G
TLZ07, 4mm, 4-8G
TZK10, QIC tape, 320MB-525 MB
TZK11, QIC tape, 2.0G
TZ86, 5-1/4-inch cartridge
It is important that all the files on your system, data files as well as system files, be protected from loss. Therefore, you should back up your entire system, including the system software. Most system files are static; that is, once they are installed they do not often change. Therefore, they do not need to be backed up as frequently as data files, which are dynamic, meaning they change constantly. Incremental backups are also possible.
Each file system backup is a single process. To ease the backup process, organize your file systems so that dynamic files are on file systems that are backed up regularly and static files are on file systems that are backed up occasionally. You may find that you have dynamic files on file systems that are backed up occasionally. If this happens and you wish to back them up regularly, just prior to performing a backup, copy the frequently changing files to systems that are backed up regularly. This allows you to back up those files without backing up an entire file system. You could write a shell script to automate these tasks for you.
The
dump
command copies all designated UFS file systems,
or individual files and directories changed after a specified date, to a file,
pipe, magnetic tape, disk, or diskette.
The
vdump
command
copies all AdvFS filesets.
Refer to the
AdvFS Administration
guide for information
on copying AdvFS file systems.
You must have superuser privileges to use the
dump
command.
Note
To produce valid backups on a UFS file system, you must back up a file system while it is inactive. It is recommended that you unmount the file system and check it for consistency. As an added precaution, put the system into single-user mode before starting your backup operations. This is not true for AdvFS. Refer to the AdvFS Administration guide for information on restoring AdvFS file systems.
The remainder of this section describes the procedure for shutting down a system and unmounting and checking the integrity of a file system.
You can back up the system while in either multiuser mode or single-user
mode.
However, backups performed on file systems actively being modified
might corrupt the backup data.
The
dump
command operates
by checking the inodes of the files you want to back up.
The inodes contain
data such as table entries and other statistics.
When you use the
dump
command to back up files in a file system, an inode is attached
to each file.
If the system or user activity changes a file after the inode
data is recorded, but before the file is backed up, the backup may be corrupted.
To shut down the system, unmount a file system, and check the integrity of a file system:
Shut down the system.
For example, to shut down the system in 5 minutes and give users periodic warning messages, enter:
#/usr/sbin/shutdown +5 'System going down to perform backups'
Use the
umount
command with the
-a
option to unmount the file systems that you want to back
up:
#/sbin/umount -a
Note that the root file system remains mounted.
Use the
fsck
command to ensure the integrity
of the file system.
For example, to check a file system for an RZ57, unit 0, partition
c, enter:
#/sbin/fsck -o /dev/rz0c
This chapter describes a backup strategy that uses the
dump
and
restore
group of backup commands.
Other
backup strategies are possible.
For example, you could use the
find
command to produce a list of files that must be backed up and
pipe the list to a backup program such as
tar
or
cpio.
Refer to the
find(1),
tar(1), and
cpio(1)
reference pages for more information.
When deciding how often to back up each file system, you should think about the balance between the potential loss of user time and data and the time it takes you to perform backups. Ask yourself the question, "How much information can I afford to lose?" The answer will help you determine your minimum backup interval. On most systems the backup interval is daily, but you can choose any other interval.
It is not necessary to back up all the files in a file system at each
backup.
Back up only those files that have changed since a previous backup;
this is called an incremental backup.
Using the
dump
and
restore
commands, you can perform up to nine levels of incremental
backups.
For example, while a level 0 dump backs up an entire file system,
a level 1 dump backs up only those files since the last level 0 dump, and
a level 7 dump backs up only those files since the last lower level dump.
To integrate incremental backups into your file backup schedule, you need to balance the time and tape space required for backup against the amount of time it could take you to restore the system in the event of a system failure. For example, you could schedule backup levels following the 10-day sequence:
0 1 2 3 4 5 6 7 8 9
On the first day you save an entire file system (level 0). On the second day you save changes since the first backup and so on until the eleventh day when you restart the sequence. This makes the amount of time spent and data saved on each backup relatively small each day except the first; however, if a system failure on the tenth day requires that you restore the entire system, you must restore all ten tapes.
Most systems follow some variant of the common Tower of Hanoi backup schedule. Once a month you make a level 0 dump to tape of all the regularly backed up file systems. Then once a week, you make a level 1 dump to start a daily sequence of:
...3 2 5 4 7 6 9 8 9 9 ...
If you do backups only once a day on the weekdays, you end up with a monthly backup schedule as follows:
0 1 3 2 5 4 1 3 2 5 4 ...
This schedule, although slightly complex, requires that you restore at most four tapes at any point in the month if a system failure corrupts files. Of course, doing a level 0 dump daily requires that you restore at most one tape at any point, but requires a large amount of time and tape storage for each backup. On most days in the Tower of Hanoi schedule, very little time and tape storage are required for a backup.
You should set up a schedule for performing a full backup of each
file system on your entire system, including all the system software.
A conservative
schedule for full system backups is to do one with each normal level 0 dump
(using Tower of Hanoi, once a month), but you can set any schedule you like
within the reliability of your storage media, which is about two years for
magnetic tapes.
To back up your file system, use the
dump
command, which has the following command syntax:
dump
options
filesystem
The
options
parameter specifies
a list of flags and their arguments and the
filesystem
parameter specifies the file system to be backed up.
You should specify the
file system with a full pathname.
The
dump
command can
back up only a single file system at a time, but there may be several
dump
processes simultaneously writing files to different tape devices.
The
dump(8)
reference page describes the command options that you use
to specify the characteristics of the tape device, such as block size, tape
storage density, and tape length.
The following list describes the most commonly
used options to the
dump
command:
-integerSpecifies the dump level as an integer (0-9).
A dump level
of 0 causes a full dump of the specified file system.
All other dump levels
cause an incremental backup.
That is, only files that have changed since
the last dump of a lower dump level are backed up.
The
/etc/dumpdates
file contains a record of when the
dump
command
was used on each file system at each dump level.
The
-u
option to the
dump
command updates the
dumpdates
file.
-f
dump_fileWrites the dump to the device specified by
dump_file
instead of to the default device,
/dev/rmt0h.
When
dump_file
is specified as a dash ( - ), the
dump
command writes to the standard
output.
-uUpdates the
/etc/dumpdates
file with the
time of the dump and the dump level for the file system in the backup.
You
use this file during incremental dumps (by using the dump level option) to
determine which files have changed since a particular dump level.
You can
edit the
/etc/dumpdates
file to change any record or fields,
if necessary.
The
dump(8)
reference page describes the format of this file.
To back up your entire file system to the default backup device, use
the
dump
command for each file system on your machine.
The
dump
command has the following command syntax:
dump
-0u
filesystem
The
filesystem
parameter specifies
the name of a file system on your machine.
The
-0u
option causes a level 0 dump and updates the
/etc/dumpdates
file with the time and date of the backup for each file system.
This creates
an initial point on which to base all future incremental backups until the
next full or level 0 dump.
Note that each file system must be backed up individually.
For example, if you want to perform a level 0 dump of the root,
/usr, and
/projects
file system partitions, follow
these steps:
To back up the root file system, load a tape into your tape drive and enter:
#dump -0u /
After completing the backup, remove the tape from your tape drive.
To back up the
/usr
file system, load a
new tape into your tape drive and enter:
#dump -0u /usr
After completing the backup, remove the tape from your tape drive.
To back up the
/projects
file system, load
a new tape into your tape drive and enter:
#dump -0u /projects
You can either back up each file system on an individual tape,
or you can back up multiple file systems on one tape by specifying the no-rewind
device,
/dev/nrmt0h, as the output device.
The following
examples show the root,
/usr, and
/projects
file systems being backed up on one tape:
#dump -0uf /dev/nrmt0h /#dump -0uf /dev/nrmt0h /usr#dump -0uf /dev/nrmt0h /projects
The previous example may require additional media management to cross-reference dump files with tapes, especially when a single dump file spans media. Exercise care when labeling this type of backup media.
You should set up a routine as part of your backup schedule to make it easier to remember which backup to do each day. This routine should include a mechanism for logging your backups and their dump level and for listing the tapes on which they are made. Because of the chance of system corruption, you should not keep this information on the computer system.
Once you have established a system for making incremental backups, the
procedure is simple.
Assume you use the following backup schedule to do a
daily backup of
/usr:
0 1 9 9 9 1 9 9 9 9 ...
On Monday, perform a level 0 dump:
#dump -0u /usr
On Tuesday, perform a level 1 dump:
#dump -1u /usr
The level 1 dump backs up all the files that changed since Monday. On Wednesday through Friday you perform a level 9 dump (which always backs up all the files that have changed since Tuesday's level 1 dump):
#dump -9u /usr
To perform the same level 9 dump to the
tape device named
/dev/rmt1h
instead of the default tape
device, use the
-f
option as shown in the following
example:
#dump -9uf /dev/rmt1h /usr
The argument to the
-f
option specifies a tape device local to the system from
which you are performing the dumps.
Some machines in a networked system environment might lack a local
tape drive that you can use for making backup tapes.
You can use the
rdump
command to make backups on a remotely located tape device.
The
rdump
command is identical to the
dump
command except that it requires the
-f
option to
specify the machine name and an attached backup device.
The
rdump
command has the following command syntax:
rdump
-f
machine:device
options
filesystem
The
machine
parameter specifies
the name of the remote machine that has the backup device and
device
specifies the name of the backup device on that remote
machine.
The colon (:) between the
machine
and
device
parameters is necessary
just as in other network file-addressing mechanisms.
The
options
parameter refers to the same
list of flags available with the
dump
command.
The filesystem parameter refers to the local file system to be backed up.
The
rdump
command updates the
/etc/dumpdates
file on the local machine in the same way as does the
dump
command.
The
rdump
command starts a remote
server,
/usr/sbin/rmt, on the remote machine to access
the storage medium.
This server process should be transparent.
Refer to
the
rmt(8)
reference page for more information.
To back up the
/projects
file system from
machine1
onto a tape drive on
machine2
with the
attached backup device
/dev/rmt0h, enter the following
command from
machine1.
The name of
machine1
must be in the
/.rhosts
file of
machine2
to allow access from
machine1
to
machine2.
#rdump -0uf machine2:/dev/rmt0h /projects
The
dump(8)
reference page describes the options
to the
rdump
command.
You can automate the backup process by using shell scripts.
The
cron
daemon can execute these shell scripts late in the evening
when there is less chance of the
dump
commands making errors
due to a changing system.
Backup shell scripts often perform the following tasks:
Determine the dump level
Warn the system of the dump
Make a listing of tape contents
Notify the operator upon completion
Some time during the day, load a tape into the tape drive.
At the specified time, the
cron
daemon runs the backup
shell scripts.
When the shell procedures are finished, remove the backup
tape and archive it.
Note that backup shell scripts are best used when the dump is small
enough to fit on a single tape.
You will need to specify the no-rewind device
and the
-N
option to the
dump
command to inhibit the tape from automatically going off line when each dump
completes.
When
dump
reaches the end of the tape, it will
take the tape off line and someone will need to be available to replace the
tape.
Occasionally, you will have to retrieve files from your backup tapes, and you will likely need to restore entire file systems at some time. If you have set up a good backup procedure, then restoring files or full file systems should be a simple task.
If a serious problem occurs, you may have to restore your entire system. Before restoring, determine what caused the problem with the system.
After determining the cause of the problem, reinstall your system from the initial boot tapes. The installation instructions that came with your system explain this procedure.
Once your system is up and running, restore the system to the state
it was in just prior to the system crash.
If you are using AdvFS, use the
vrestore
command.
Refer to the
AdvFS Administration
guide for information
on restoring the AdvFS file system.
If you are using UFS, use the
restore
command to restore data from tapes made with the
dump
command.
Because the
dump
command saves
a single file system at a time, you must execute the
restore
command for each file system you wish to restore.
The
restore
command has the following command syntax:
restore
options
The
options
parameter indicates the
flags and arguments that you use to specify the characteristics of the tape
device and special restore options.
Refer to the
restore(8)
reference page
for more information about these options.
The following list describes the
most commonly used options to the
restore
command:
-iThe
i
(interactive) flag starts interactive
restoration of files from the tape.
After reading directory information from
the tape, this option provides a shell-like interface that allows you to select
the files you want to restore.
The commands available in interactive mode
are described in
Section 11.4.3.
-rThe
r
(restore) flag restores the entire
contents of the file system on the backup tape into the current working directory.
You should not do this except to restore an entire file system into an empty
directory or to restore file system incremental dumps.
-sThe
s
(skip) flag identifies which dump
file on the media the
restore
command will use.
This is
useful when the dump media contains more than one dump image and not all of
them will be restored.
To effectively use this option, you must be consistent
in the order in which you dump images to the tape.
For example, if you dump
multiple file systems to a single backup tape nightly, dump the file systems
in the same order each night.
This will assist you in locating a particular
file or file system at restore time.
-t
namesThe
t
(table of contents) flag creates
a list of files and directories on the tape that matches the
names
argument.
If you specify
names,
the
restore
command returns a list of the files and directories
that are on the tape that matches the specified names.
The
names
argument should be specified as
./filename .
For example, if the
.rhosts
file and the
staff
directory exist on the tape, the
restore -t ./.rhosts ./staff
command will list the file and the
directory.
If you do not specify
names, the
restore
command returns a complete listing of the backed up files
on the tape.
-x
namesThe
x
(extract) flag restores from the
tape the files and directories specified by the
names
argument.
The
names
argument contains a list of
files and directories to be restored from the tape.
Specify
names
as
./filename .
For
example, the
restore -x ./.rhosts ./staff
command will
restore the
.rhosts
file and the
./staff
directory.
If
names
specifies a directory name,
then all the files in the directory are recursively restored.
-f
dump_fileThe
f
flag used with the
dump_file
argument restores the dump from the device specified
by the
dump_file
argument instead of the default
device,
/dev/rmt0h.
-F
command_fileThe
F
flag used with the
command_file
argument specifies a file from which interactive
restore commands are read.
You should use this option in conjunction with
the
-i
option.
If you are restoring a file system other than root or
/usr, go to
Section 11.4.1.
If you are restoring
the root and
/usr
file systems, go to
Section 11.4.5.
If the
/var
directory is on a separate file system than
/usr, go to
Section 11.4.5.
There may be times when you will need to restore a file system. This section describes a general procedure for restoring a file system. To restore individual files, go to Section 11.4.2.
When you restore a UFS file system, you create a new file system and restore the files from the dump files by using the following command syntax. Refer to the AdvFS Administration guide for information on restoring an AdvFS file system.
newfs
raw_device
mount
block_device
[ filesystem]
cd
filesystem
restore
-Yrf
dump_file
If the disk does not have a label,
write the label by using the
disklabel
command before you
create the new file system.
Use the following command syntax to determine
if the disk has a label:
disklabel
-r
disk
Writing a label with customized partition table settings may affect the entire disk. Use the following command syntax to write the default disk partition table:
disklabel
-rw
disk disk_type
The
disk
parameter specifies the disk that
includes the device mnemonic and unit number.
The
disk_type
parameter specifies the type of disk associated with the
disk
as described in the
/etc/disktab
file.
Invoke the editing option of the
disklabel
command
to use the customized partition table settings.
Refer to
Chapter 7
or to
disklabel(8)
for more information.
The raw_device parameter specifies the full raw device pathname of the disk device on your system. The block_device parameter specifies the full block device pathname of the disk device on your system. The filesystem parameter specifies the full pathname of the file system you want to make available. The dump_file parameter specifies the full pathname of the file containing the dump data.
The following example shows the commands you use to restore a file system
called
/usr/projects
on an RZ57 disk from a tape:
#disklabel -rw rz1 rz57#newfs /dev/rrz1c#mount /dev/rz1c /usr/projects#cd /usr/projects#restore -Yrf /dev/rmt0h
When users lose files, they ask their system administrator to restore
those files.
Users may also ask you to restore an earlier version of a file.
Whatever the reason for a file restoration, determine which tape contains
the correct version of the file.
If you are restoring a file on UFS, use
the
restore
command to restore the file.
If you are restoring
a file on AdvFS, refer to the
vrestore(8)
reference page for information.
By asking when the file was lost and when it was last modified, you
can use your backup log to determine which tape contains the most recent version
of the wanted file.
Use the
-t
option with the
restore
command to determine whether a file is on the selected tape.
Use the following syntax:
restore
-t
./filename
The
-t
option creates a list of files
and directories on the tape that matches the
./filename
argument.
For example, to list the contents of the
working
subdirectory of the
/usr
file system on a particular backup
tape, load the tape and enter:
#restore -t ./working
To create a list of the entire contents of a backup tape, load the backup tape and enter:
#restore -t
Make a listing of each backup tape after you create it. This verifies a successful backup and gives you a place to look up what files are on the tape.
After determining the location of the file, create a new directory for
the file.
If you restore the file into an existing directory and the file
already exists, the restored file will overwrite the existing file.
Restore
the file by using the following form of the
restore
command:
restore
-x
./filename
The file will be restored into your current working directory.
For example, to restore the
working/old.file
file
from a
/usr
file system backup tape into your current directory,
load the backup tape and enter:
#restore -x ./working/old.file
To restore the entire contents of the working subdirectory from the same tape, enter:
#restore -x ./working
If your dump media contains multiple dump images, you need to know the sequence of the dump images in order to restore a file from one of the images. To examine the contents of the first dump image on the media, load the tape and enter:
#restore -ts 1
The
-s
option
followed by the number
1
specifies the first dump image.
For example, to restore the
working/old.file
file
from a
/usr
file system, which is the third dump image
on the backup tape into your current directory, load the backup tape and enter:
#restore -xs 3 ./working/old.file
To ease the task of restoring multiple files, use the
-i
option to the
restore
command.
This option
starts an interactive
restore
session.
The interactive
mode has commands similar to shell commands.
To begin an interactive
restore
session, enter:
#restore -i
The system responds with the following prompt:
restore >
The following command-line options are available in the interactive restore mode:
ls
[
directory
]Lists files in the current or specified directory. Directory entries end with a / (slash). Entries that have been marked for reading begin with an * (asterisk).
cd
[
directory
]Changes the current directory to the directory specified by directory.
pwdLists the pathname of the current directory.
add
[
files
]Adds the files in the current directory or the files specified
by
files
to the list of files recovered from the
tape.
Once they are specified to be read by the
add
command,
files are marked with an * (asterisk) when they are listed with the
ls
command.
delete
[
files
]Deletes all the files in the current directory or the files specified by files from the list of files recovered from the tape.
extractRestores from the tape the files that are marked to be read
into the current working directory.
The
extract
command
prompts you for the logical volume that you want to mount (usually 1), and
whether the access modes of the dot (.) are affected; answer
yes
when you are restoring the entire
root
directory.
setmodesSets owner, access modes, and file creation times for all
directories that have been added to the files-to-read list; no files are recovered
from the tape.
Use this command to clean up files after a
restore
command has been prematurely aborted.
verboseToggles verbose mode.
In verbose mode, each file name is
printed to the standard output.
By default, verbose mode is set to off.
This is the same as the
-v
command line option to
the
restore
command.
helpLists a summary of the interactive commands.
?Lists a summary of the interactive commands.
whatLists the tape header information.
quitQuits the interactive restore session.
xitExits from the interactive restore session.
The
xit
command is the same as the
quit
command.
To interactively restore the
./working/file1
and
./working/file2
files from a backup tape, load the
tape and enter:
#restore -i
Once in interactive mode, follow these steps to add the files to the list of files to be extracted:
Change to the
working
directory:
restore >cd working
At the prompt, enter the file name.
restore >add file1
Enter the name of the second file.
restore >add file2
Extract the files.
restore >extract
You are prompted for the logical volume you want to mount;
usually you respond to this prompt with
1.
You have not read any tapes yet. Unless you know which volume your file(s) are on you can start with the last volume and work towards the first.Specify next volume #:1
You are then asked whether the extract affects the access modes of the dot
(.).
For this example, reply with
n.
set owner/mode for '.'? [yn]n
Once the files are extracted, quit the interactive session.
restore >quit
The
file1
and
file2
files
are now in the current directory.
You can automate this procedure in a command file that is read by the
-F
option to the
restore
command.
For
example, the following command file, named
restore_file,
performs the restore operation shown in the previous example:
cd working add file1 add file2 extract 1 n quit
To read and execute this shell script, enter the following command:
#restore -iF restore_file
The result of the procedure in this script is identical to that of the previous interactive restore session.
There may be times when you need to perform remote restores.
You can
use the
rrestore
command to perform restores to local directories
from a remote tape device.
The
rrestore
command requires
the
-f
option to specify the machine name and its
backup device.
The
restore
command has the following syntax:
rrestore
-f
machine:device
[options]
The
machine
argument specifies the
name of the remote machine where the backup device is attached, and
device
specifies the name of the backup device on that remote
machine.
The colon ( : ) between
machine
and
device
is necessary just
as in other network file-addressing mechanisms.
The
options
for the
rrestore
command are the same as for the
restore
command.
See
Section 11.4
for a description of the options.
To restore the
./working/file1
file onto the local
directory on machine1 from a backup tape mounted on machine2 where the backup
device
/dev/rmt0h
is attached, enter the following command
from machine1.
The name machine1 must be in the
/.rhosts
file of machine2 to allow access from machine1 to machine2.
#rrestore -xf machine2:/dev/rmt0h ./working/file1
The
rrestore
command starts a remote
server,
/usr/sbin/rmt, on the remote machine to access
the storage medium.
This process should be transparent.
Refer to the
rmt(8)
reference page for more information.
See
Section 11.4
for
a description of the options to the
rrestore
command.
This
section describes a procedure for restoring the root and
/usr
file systems.
The root file system must be restored before you can restore
the
/usr
file system.
If the
/var
directory
is on a file system other than
/usr, repeat the steps in
this section for restoring
/var.
The procedure in this section requires that you have access to the most
recent dump files of your root and
/usr
file systems.
You should use this procedure only when a catastrophic error occurs on the
system disk, such as a disk crash or when an inadvertent deletion of either
the root or
/usr
file systems renders the system inoperative.
The following example assumes that you are restoring from level 0 dump files and that you are using the text-based (or character cell) interface to the task.
Load the installation software.
For removable media such as
tape or CD-ROM, insert the media into the appropriate drive.
For RIS
installations, verify that the inoperative system has been registered on the
RIS server.
See
Sharing Software on a Local Area Network
for details.
If the dump file is located
on a remote system, include the hostname of the inoperative system in the
/.rhosts
file of the remote system.
For security reasons, be sure
to delete the hostname from the
/.rhosts
file after the
restore operation has completed.
Boot the Tru64 UNIX software as described for your processor
and distribution media in the
Installation Guide.
If your system had a graphical
interface, the
Installation Setup
screen would be displayed,
rather than the following menu.
However, in both cases you would select the
UNIX Shell
option.
Select the UNIX Shell option at the prompt.
Create the special files for the root file system device and dump file device.
If you are restoring dump files from a local system, change
to the
/dev
directory and use the
MAKEDEV
command with the following command syntax:
MAKEDEV
mnemonic
The mnemonic parameter refers to a device mnemonic. See Appendix A for a list of the supported device mnemonics. For example, to create the special files for an RZ57 disk, unit number 0, and a TLZ06 tape, unit number 5, enter:
#cd /dev#./MAKEDEV rz0 tz5
If you are restoring dump files from a remote system, change
to the
/dev
directory and use the
MAKEDEV
command with the following command syntax:
MAKEDEV
mnemonic
The mnemonic parameter refers to a device mnemonic. See Appendix A for a list of the supported device mnemonics. For example, to create the special files for an RZ57 disk, unit number 0, enter:
#cd /dev#./MAKEDEV rz0
After creating the system disk special file, configure the
network by configuring the network interface and creating the hostname database
( /etc/hosts ).
Use the
ifconfig
command with the following syntax to configure the network interface:
ifconfig
interface_id
local_address
mask
The
interface_id
parameter refers
to the network device mnemonic.
Refer to the
uerf(8)
reference page
for information about obtaining an interface ID.
The
local_address
parameter specifies the Internet address for the local host.
The
netmask
mask
parameter
specifies how much of the address to reserve for subdividing networks into
subnetworks.
You can get the
netmask
value by entering
the
ifconfig
command on a system within the immediate area.
For example, to get the
netmask
value from the system
ln0, enter:
#ifconfig ln0
Refer to the
hosts(4)
and
ifconfig(8)
reference pages for more information.
Enter the following commands to configure
the network for the system
localsystem, with an Internet
address of 120.105.5.1, connected by an Ethernet interface to the remote system
remotesystem, with an Internet address of 120.105.5.2:
#cd /etc#echo "127.0.0.1 localhost" >> hosts#echo "120.105.5.2 remotesystem" >> hosts#ifconfig ln0 120.105.5.1 netmask 0xfffffc00
Some older systems broadcast all 0s instead of all 1s.
In this situation, you must also specify the
broadcast address.
Change to the root directory.
#cd /
If the disk does not have a label, which could occur if the
disk was physically damaged or replaced, write the default disk partition
tables and bootstrap programs.
The disk partitions and bootstrap programs
should be operational.
To determine if the disk has a valid label, use the
disklabel
command with the following syntax:
disklabel
-r
disk
Use the
disklabel
command with the following
syntax to write the default disk partition table:
disklabel
-rw
disk
disk_type
The
disk
parameter specifies the
disk that includes the device mnemonic and unit number.
The
disk_type
parameter specifies the type of disk associated with
disk
as described in the
/etc/disktab
file.
For example, to write the default disk partition tables on an RZ57 disk, unit
0, enter the following command:
#disklabel -rw rz0 rz57
Note
The
disklabelcommand used in this procedure writes the default disk partition tables to the disk. Writing a label with customized partition table settings may affect the entire disk. If the disk you are restoring has customized partition table settings, invoke the editing option of thedisklabelcommand. Refer to Chapter 7 or to thedisklabel(8) reference page for more information.
Create a new root file system by using the following command syntax:
newfs
raw_device
The raw_device parameter specifies the full raw device pathname of the disk device on your system. For example, to create a new file system on an RZ57, unit 0, enter:
#newfs /dev/rrz0a
Mount the file system by using the following command syntax:
mount
block_device[ /mnt]
The block_device parameter specifies the full block device pathname of the disk device. For example, to mount the file system created in the previous step, enter:
#mount /dev/rz0a /mnt
Restore the file system:
If you are restoring dump files from a local file system,
change to the
/mnt
directory, insert the medium containing
the dump file, and enter the
restore
command with the following
command syntax:
restore
[ -Yrf]
[ dumpfile]
The dumpfile parameter specifies the pathname of the file that contains the dump data. For a tape, you would enter the following commands:
#cd /mnt#restore -Yrf /dev/rmt0h
If you are restoring dump files from a remote system, change
to the
/mnt
directory and use the
rsh
command with the following syntax:
rsh
[ remote_hostname ]
[ "dd if=dumpfile bs=blocksize" | restore -Yrf -]
The remote_hostname parameter specifies the host name of the remote system that contains the dump file. The dumpfile parameter specifies the full pathname of the dump file on the remote system, and the blocksize parameter is necessary for reading from a tape.
The dump file must be read with the same block size as was used when writing to the tape. The default dump record size is 10 KB.
For example, to restore a dump file on a TLZ06 from the remote system
remotesystem
that was written using the default block size, enter:
#cd /mnt#rsh remotesystem "dd if=/dev/rmt0h bs=10k" | restore -Yrf -
Change to the root directory and unmount the file system.
#cd /#umount /mnt
Restore the
/usr
file system.
If the
/usr
file system is on the same
device as root, the process is similar to steps 7 through 10.
To restore
the
/usr
file system on the
g
partition
of the same device as the root file system from the same tape device, enter
the following sequence of commands.
If you are using AdvFS, this step will
not work.
Use the procedure in step 11a.
#newfs /dev/rrz0g#mount /dev/rz0g /mnt#cd /mnt#restore -Yrf /dev/rmt0h#cd /#umount /mnt
Use the following procedure to restore the
/usr
directory on AdvFS from a tape mounted on
rmt0
to a drive
other than root:
#cd /dev#MAKEDEV rz1#cd /#disklabel -rw rz1 rz57#mkfdmn /dev/rz1c usr_domain#mkfset usr_domain usr#mount -t advfs usr_domain#usr /usr#vrestore -x -D /usr
If the
/usr
file system is on a different
device from root, the process is similar to steps 4 through 10.
To restore
/usr
on an RZ57, unit 1,
c
partition from the
same tape device, enter the following sequence of commands:
#cd /dev#MAKEDEV rz1#cd /#disklabel -rw rz1 rz57#newfs /dev/rrz1c#mount /dev/rz1c /mnt#cd /mnt#restore -Yrf /dev/rmt0h#cd /#umount /mnt
Halt the system.
#halt
Boot the system as described for your processor and distribution media in the Installation Guide.
The following text-based example shows a portion of the restoration
procedure for the root and
/usr
file systems to an RZ57,
unit 0, from a TLZ06, unit 5.
The backslashes in this example indicate line
continuation and are not in the actual display.
.
.
.
Select one of the following options: 1) Default Installation 2) Custom Installation 3) UNIX Shell Enter your choice: 3 # cd /dev # MAKEDEV rz0 tz5 MAKEDEV: special file(s) for rz0: rz0a rrz0a rz0b rrz0b rz0c rrz0c rz0d rrz0d rz0e rrz0e rz0f \ rrz0f rz0g rrz0g rz0h rrz0h MAKEDEV: special file(s) for tz5: rmt0l nrmt0l rmt0h nrmt0h rmt0m nrmt0m rmt0a nrmt0a # cd / # disklabel -rw rz0 rz57 # newfs /dev/rrz0a Warning: 575 sector(s) in last cylinder unallocated /dev/rrz0a: 40960 sectors in 39 cylinders of 15 tracks, \ 71 sectors 21.0MB in 3 cyl groups (16 c/g, 8.72MB/g, 2048 i/g) super-block backups (for fsck -b #) at: 32, 17152, 34272, # mount /dev/rz0a /mnt # cd /mnt # restore -Yrf /dev/rmt0h # cd / # umount /mnt # newfs /dev/rrz0g Warning: 105 sector(s) in last cylinder unallocated /dev/rrz0g: 614400 sectors in 577 cylinders of 15 tracks, 71 \ sectors 314.6MB in 37 cyl groups (16 c/g, 8.72MB/g, 2048 i/g) super-block backups (for fsck -b #) at: 32, 17152, 34272, 51392, 68512, 85632, 102752, 119872, 136992, 154112, 171232, 188352, 205472, 222592, 239712, 256832, \ 272672, 289792, 306912, 324032, 341152, 358272, 375392, 392512, 409632, \ 426752, 443872, 460992, 478112, 495232, 512352, 529472, 545312, 562432, \ 579552, 596672, 613792, # mount /dev/rz0g /mnt # cd /mnt # restore -Yrf /dev/rmt0h # cd / # umount /mnt # halt syncing disks... done halting.... (transferring to monitor)
The following text-based example shows a portion of the restoration
procedure for the root and
/usr
file systems to an RZ57,
unit 0, from a remote tape device.
The remote system is called
remotesystem
and has an Internet address of 120.105.5.2.
The local
system is called
localsystem
and has an Internet address
of 120.105.5.1.
.
.
.
Select one of the following options: 1) Default Installation 2) Custom Installation 3) UNIX Shell Enter your choice: 3 # cd /dev # MAKEDEV rz0 MAKEDEV: special file(s) for rz0: rz0a rrz0a rz0b rrz0b rz0c rrz0c rz0d rrz0d rz0e rrz0e rz0f rrz0f rz0g \ rrz0g rz0h rrz0h # cd /etc # echo "127.0.0.1 localhost" >> hosts # echo "120.105.5.2 remotesystem" >> hosts # ifconfig ln0 120.105.5.1 netmask 0xfffffc00 # cd / # disklabel -rw rz0 rz57 # newfs /dev/rrz0a Warning: 575 sector(s) in last cylinder unallocated /dev/rrz0a: 40960 sectors in 39 cylinders of 15 tracks, 71 sectors 21.0MB in 3 cyl groups (16 c/g, 8.72MB/g, 2048 i/g) super-block backups (for fsck -b #) at: 32, 17152, 34272, # mount /dev/rz0a /mnt # cd /mnt # rsh remotesystem "dd if=/dev/rmt0h bs=10k" | restore -Yrf - 1743+0 records in 1743+0 records out # cd / # umount /mnt # newfs /dev/rrz0g Warning: 105 sector(s) in last cylinder unallocated /dev/rrz0g: 614400 sectors in 577 cylinders of 15 tracks, 71 sectors 314.6MB in 37 cyl groups (16 c/g, 8.72MB/g, 2048 i/g) super-block backups (for fsck -b #) at: 32, 17152, 34272, 51392, 68512, 85632, 102752, 119872, 136992, 154112, 171232, 188352, 205472, 222592, 239712, 256832, 272672, 289792, 306912, 324032, 341152, 358272, 375392, 392512, 409632, 426752, 443872, 460992, 478112, 495232, 512352, 529472, 545312, 562432, 579552, 596672, 613792, # mount /dev/rz0g /mnt # cd /mnt # rsh remotesystem "dd if=/dev/rmt0h bs=10k" | restore -Yrf - 19922+0 records in 19922+0 records out # cd / # umount /mnt # halt syncing disks... done halting.... (transferring to monitor)