fbackup.1m (2010 09)
f
fbackup(1M) fbackup(1M)
(TO BE OBSOLETED)
The use of fbackup for backing up NFS mounted file systems is not guaranteed to work as expected if
the backup is done as a privileged user. This is due to the manner in which NFS handles privileged-user
access by mapping user root and uid 0
to user nobody, usually uid -2, thus disallowing root privileges
on the remote system to a root user on the local system.
The utility set comprised of
fbackup and frecover
was originally designed for use on systems
equipped with not more than one gigabyte of total file system storage. Although the utilities have no pro-
gramming limitations that restrict users to this size, complete backups and recoveries of substantially
larger systems can cause a large amount of system activity due to the amount of virtual memory (swap
space) used to store the indices. Users who want to use these utilities, but are noticing poor system-wide
performance due to the size of the backup, are encouraged to back up their systems in multiple smaller
sessions, rather than attempting to back up the entire system at one time.
Due to present file-system limitations, files whose inode data, but not their contents, are modified while a
backup is in progress might be omitted from the next incremental backup of the same graph. Also,
fbackup does not reset the inode change times of files to their original values.
fbackup should not be used with no-rewind devices, for example,
/dev/rmt/0mn or
/dev/rtape/tape1_BESTn
on systems where legacy Device Special Files (DSF) is disabled.
fbackup allocates resources that are not returned to the system if it is killed in an ungraceful manner.
If it is necessary to kill fbackup, send it a
SIGTERM, not a SIGKILL.
If sparse files are backed up without using data compression, a very large amount of media can be con-
sumed.
fbackup creates volumes with a format that makes duplication of volumes by dd impossible (see dd(1)).
Copying an
fbackup volume created on one media type to another media type does not produce a valid
fbackup volume on the new media because the formats of volumes on raw magnetic tape, on a regular
file, and on rewritable optical disks are not identical.
When configuring the parameter
blocksperrecord
(see -c option), the record size is limited by the
maximum allowed for the tape drive. Common record sizes include 128 blocks for DLT and DDS tape
drives, and 60 blocks for the HP 7980. Note also that the blocksize used in earlier releases (7.0 and
before) was 512 bytes, whereas it is now 1024 bytes. This means that the same value specified in block-
sperrecord in an earlier release creates blocks twice their earlier size in the current release; for example,
a blocksperrecord parameter of 32 would create 16-Kbyte blocks at HP-UX 7.0, but now creates 32-Kbyte
blocks. If blocksperrecord exceeds the byte count allowed by the tape drive, the tape drive rejects the
write, causing an error to be communicated to
fbackup which fbackup interprets as a bad tape. The
resulting write error message resembles the following:
fbackup (3013): Write error while writing backup at tape block 0.
Diagnostic error from tape 11...... SW_PROBLEM (printed by driver on console)
fbackup (3102): Attempting to make this volume salvageable.
DEPENDENCIES
NFS
Access control lists of networked files are summarized (as returned in st_mode by stat()), but not
copied to the new file (see stat (2)).
fbackup does not support QIC-120 and QIC-150 formats on QIC devices. If fbackup is attempted for
these formats, fbackup fails and the following message is displayed :
mt lu X: Write must be a multiple of 512 bytes in QIC 120 or QIC 150
AUTHOR
fbackup was developed by HP.
FILES
/var/adm/fbackupfiles/dates database of past backups
SEE ALSO
cpio(1), ftio(1), pax(1), dump(1M), frecover(1M), restore(1M), rmt(1M), stat(2), acl(5), mt(7).
HP-UX 11i Version 3: September 2010 − 7 − Hewlett-Packard Company 7