Backups and Restores
Backups and Restores
Copyright(c) Management Analytics, 1995 - All Rights Reserved
Copyright(c), 1990, 1995 Dr. Frederick B. Cohen - All Rights Reserved
Problem:
Backups may take many tapes or disks, and the programs provided
with UNIX are not tolerant of any user errors. For example, if a
tape is write locked, the backup typically fails rather than asking you
to write enable the tape. On restoration, a bad tape or out of
sequence tape will cause the entire restoration to fail, and it has to
be started from scratch.
Prevention:
Be very systematic and careful with UNIX backups, and use the
``verify'' mode if one exists on your system to assure that the backups
are accurate. Clean your tape drives and test your tapes regularly.
Detection:
The `verify' mode detects bad backups in many cases, but the
best detection mechanism is to restore tapes periodically on another
system and check to assure the integrity of the restored information
with cryptographic checksumming techniques.
Cure:
The cure to physical problems is normally hardware maintenance.
Problem:
Restoring files replaces on-line versions of those files. If
several files are lost or destroyed, the restoration of entire
directories is usually performed as a convenience, but this may
overwrite newer versions of some files. In databases, restoring lost
parts of the database may leave an inconsistent database state. UNIX
software provides options for overwriting older versions only,
overwriting all version, or never overwriting, and you have to be
careful to make the right choice.
Prevention:
To prevent this sort of problem, it is common to use database
integrity techniques. These can be found in good books on databases.
Another good way of preventing such problems is to always deal with the
database as a whole, and keep sequential backups for replay if
restoration is needed.
Detection:
This sort of problem is usually detected when massive failures
result or wrong results are detected by people.
Cure:
Regeneration of the database from transaction records is a
standard recovery method.
Problem:
Restoring from backups typically restores file protections,
but protection may have been changed since the backup was performed.
This means that protection state changes must be redone after
restoration in order to keep a consistent state. Whenever you restore
or load software from a backup tape, it may create protection problems.
For example, if you load a program that was saved with the superuser
as its owner, you may give the user a method for attaining
superuser privileges. Similar protection problems may make the file
inaccessible after restoration without the superuser taking special
action. When two systems have different integers associated with
Uids, a restored file may be accessible by the wrong user.
Prevention:
The way to prevent this is to be very careful and thoughtful about
how you use tapes and the storage and retrieval facility. A common practice
inside an organization is to have a single set of standard Uids and Gids
which never change, but this does not apply for imported software.
Detection:
It is straight forward to write a customized program to check
the number and location of files owned by each user, and detect large
numbers of changes in these statistics. This will detect large scale
problems of this sort, but is easily avoided by a sophisticated attacker.
Cure:
The cure is to change the owner and group to the appropriate
settings. This is easily automated for recursive directory structures
via the UNIX `find' command in combination with the Chown and
Chgrp commands.