BACKUP(5) BACKUP(5)
NAME
backup - incremental backup files
DESCRIPTION
The backup system consists of a number of client machines,
and a `backup machine', which has a database and a
collection of backup copies of files. On clients files
concerned with backup live in a directory, normally defined
in the shell script The file needed on both client and
backup machine, has up to three lines, namely the backup
machine name, the default backup device, and the directory,
hereafter called $FM, where the rest of the backup software
lives on the backup machine. Client systems normally have
just the first line. The rest of this description applies
to the backup machine.
The databases live in $FM/db and are maintained in cbt(3)
form. The main database, called stores two mappings. The
first maps filename-time pairs to backup copy names, thus:
/n/bowell/usr/jim/goo//519487622 v/v22/17
The number after is the inode change date, expressed in sec-
onds since the epoch; see stat(2). If the backup copy is
still on magnetic disk, it will be called $FM/v/v22/17; oth-
erwise it will be v22/17 on some optical disk. (The mapping
of backup copy name to optical disk name is kept in
$FM/adm/volidmap.) The second mapping maps filenames to the
time of their most recently backed-up version:
/n/bowell/usr/jim/goo 520514116
The second database, dir, maps directoryname-time pairs to
the contents of that directory. This allows quick recovery
of file trees.
The third database, fs, maps filename-time pairs to (essen-
tially) inodes. This allows efficient implementation of
backup mount; see backup(1).
The program $FM/bin/dbupdate manages these databases. The
dir and fs databases are optional; they will be updated only
if they already exist. The program also assigns the backup
copy names into a flat directory structure. A new directory
is used when the total size of the files in the current
directory would exceed 20000K bytes, rounding each file size
up to a multiple of 4K.
The backup copy of a file consists of a header that gives
the original inode, pathname and owner (as a string),
BACKUP(5) BACKUP(5)
followed by the contents of the file. Directories are
stored as a sequence of entry names.
To prevent multiple writers into a database, a lockfile is
used. The content of this file is the process id of the
process accessing the database. Locks are removed by exe-
cuted by rc(8) when the system boots.
The backup system supports multiple filemap databases (this
allows the current database to be kept small). The list of
database names is kept in one per line in order of increas-
ing priority. The last name is assumed to be the active
database; all the others are read-only.
Programs such as sweep and dbupdate leave droppings in the
log file
Statistics of the numbers of files and bytes saved for users
of a given system are kept in Each file consists of a
sequence of records with a machine-independent structure;
generally, one record per user per day. The records are
maintained by which processes the file that is maintained by
dbupdate.
To allow quick searching for filenames with full regular
expressions, a simple sorted list of all saved filenames is
often kept, normally in
The device (and system) used for recovering files can be
specified in many ways. In order of decreasing priority: a
-f option in backup recover or backup fetch (see backup(1)),
a default device on the client system (in line 2 of the
default device on the backup system.
FILES
SEE ALSO
backup(1), worm(8), backup(8), cbt(1), stat(2)
A. Hume, `The File Motel: an Owner's Manual', this manual,
Volume 2