|HP-UX Reference > F
TO BE OBSOLETED
HP-UX 11i Version 3: February 2007
fbackup — selectively back up files
/usr/sbin/fbackup -f device [-f device] ... [-0-9] [-nsuvyAEl] [-i path] [-e path] [-g graph] [-d path] [-I path] [-V path] [-c config]
/usr/sbin/fbackup -f device [-f device] ... [-R restart] [-nsuvyAEl] [-d path] [-I path] [-V path] [-c config]
fbackup combines features of dump and ftio to provide a flexible, high-speed file system backup mechanism (see dump(1M) and ftio(1)). fbackup selectively transfers files to an output device. For each file transferred, the file's contents and all the relevant information necessary to restore it to an equivalent state are copied to the output device. The output device can be a raw magnetic tape drive (for example, a DLT tape drive), the standard output, a rewritable magneto-optical disk, or a file.
The selection of files to back up is done by explicitly specifying trees of files to be included or excluded from an fbackup session. The user can construct an arbitrary graph of files by using the -i or -e options on the command line, or by using the -g option with a graph file. For backups being done on a regular basis, the -g option provides an easier interface for controlling the backup graph. fbackup selects files in this graph, and attempts to transfer them to the output device. The selectivity depends on the mode (full or incremental) in which fbackup is being used.
When doing full backups, all files in the graph are selected. When doing incremental backups, only files in the graph that have been modified since a previous backup of that graph are selected. If an incremental backup is being done at level 4 and the -g option is used, the database file is searched for the most recent previous backup at levels 0-3. If a file's modification time is before the time when the last appropriate session began and the i-node change time is before the time that same session ended, the file is not backed up. All directories lying on the path to a file that qualifies for the incremental backup will also be on the backup media, even if the directories do not qualify on their own status.
If fbackup is used for incremental backups, a database of past backups must be kept. fbackup maintains this data in the text file /var/adm/fbackupfiles/dates, by default. Note that the directory /var/adm/fbackupfiles must be created prior to the first time fbackup is used for incremental backups. The -d option can be used to specify an alternate database file. The user can specify to update this file when an fbackup session completes successfully. Entries for each session are recorded on separate pairs of lines. The following four items appear on the first line of each pair: the graph file name, backup level, starting time, and ending time (both in time() format). The second line of each pair contains the same two times, but in strftime() format. These lines contain the local equivalent of STARTED:, the start time, the local equivalent of ENDED:, and the ending time. These second lines serve only to make the dates file more readable; fbackup does not use them. All fields are separated by white space. Graph file names are compared character-by-character when checking the previous-backup database file to ascertain when a previous session was run for that graph. Caution must be exercised to ensure that, for example, graph and ./graph are not used to specify the same graph file because fbackup treats them as two different graph files.
The general structure of an fbackup volume is the same, no matter what type of device is used. There are some small specific differences due to differing capabilities of devices. The general structure is as follows:
Each file entry in the index contains the file size, the volume number and the pathname of the file. At the beginning of every volume, fbackup assumes that all files not already backed up will fit on that volume, an erroneous assumption for all but the last volume. Indices are accurate only for the previous volumes in the same set. Hence, the index on the last volume may indicate that a file resides on that volume, but it may not have actually been backed up (for example, if it was removed after the index was created, but before fbackup attempted to back it up). The only index guaranteed to be correct in all cases is the on-line index (-I option), which is produced after the last volume has been written.
Specific differences in the structure of fbackup volumes are listed below:
fbackup provides the ability to use UCB-mode tape drives. This makes it possible to overlap the tape rewind times if two or more tape drives are connected to the system.
There are several things the user will want to consider when setting up fbackup for regular use. These include type of device and media, full versus incremental frequency, amount of logging information to keep on-line, structure of the graph file, and on-line versus off-line backup.
The type of device used for backups can affect such things as media expenses, ability to do unattended backups, and speed of the backup. Using 36-track tapes will probably result in the highest performance, but require user intervention for changing tapes. Both DLT and DDS autochangers and libraries can provide unattended backups. A magneto-optical autochanger can also provide an unattended backup for a large system and long life media, however the media cost is high. Lower cost and good performance can be achieved with a single DLT tape drive, but multi-volume backups must be attended.
It is also important to consider how often full backups should be made, and how many incremental backups to make between full backups. Time periods can be used, such as a full backup every Friday and incrementals on all other days. Media capacities can be used if incremental backups need to run unattended. The availability of personnel to change media can also be an important factor as well as the length of time needed for the backup. Other factors may affect the need for full and incremental backup combinations such as contractual or legal requirements.
If backup information (output from the -V or -I options) is kept on-line, the required storage space must also be considered. Index file sizes are hard to predict in advance because they depend on system configuration. Each volume header file takes less than 2048 bytes. Of course the more information that is kept on-line, the faster locating a backup media for a recovery will be.
There are several ways to structure the graph file or files used in a system backup. The first decision involves whether to use one or more than one graph file for the backup. Using one file is simpler, but less flexible. Using two or more graph files simplifies splitting backups into logical sets. For example, one graph file can be used for system disks where changes tend to be less frequent, and another graph file for the users area. Thus two different policies can be implemented for full and incremental backups.
fbackup was designed to allow backups while the system is in use by providing the capability to retry an active file. When absolute consistency on a full backup is important, the system should probably be in single-user mode. However, incremental backups can be made while the system is in normal use, thus improving system up-time.
LC_COLLATE determines the order in which files are stored on the backup device and the order of output by the -I option.
LC_TIME determines the format and contents of date and time strings.
LC_MESSAGES determines the language in which messages are displayed.
If LC_COLLATE, LC_TIME, and LC_MESSAGES are not all specified in the environment, or if either is set to the empty string, the value of LANG is used as a default for each unspecified or empty variable. If LANG is not specified or is set to the empty string, a default of "C" (see lang(5)) is used instead of LANG. If any internationalization variable contains an invalid setting, fbackup behaves as if all internationalization variables are set to "C". See environ(5).
fbackup returns one of the following values:
If warnings occur, the operator should check the fbackup logs to verify the sanity of the backup.
In the following two examples, assume the graph of interest specifies all of /usr except /usr/lib (as described for the -g option above).
The first example is a simple case where a full backup is done but the database file is not updated. This can be invoked as follows:
/usr/sbin/fbackup -0i /usr -e /usr/lib -f /dev/rtape/tape4QIC150
The second example is more complicated, and assumes the user wants to maintain a database of past fbackup sessions so that incremental backups are possible.
If sufficient on-line storage is available, it may be desirable to keep several of the most recent index files on disk. This eliminates the need to recover the index from the backup media to determine if the files to be recovered are on that set. One method of maintaining on-line index files is outlined below. The system administrator must do the following once before fbackup is run for the first time (creating intermediate level directories where necessary):
A shell script that performs the following tasks could be run for each fbackup session:
When the session completes successfully, the index is automatically placed in the proper location.
The fbackup, frecover, and ftio commands are deprecated for creating new archives. In a future HP-UX release, creation of new archives with these commands will not be supported. Support will be continued for archive retrieval. Use the standard pax command (portable archive interchange) to create archives. See pax(1).
fbackup consists of multiple executable objects, all of which are expected to reside in directory /usr/sbin.
fbackup does not require special privileges. However, if the user does not have access to a given file, the file is not backed up.
For security reasons, configuration files and the chgvol and error executable files should only be writable by their owners.
In HP-UX 11i Version 3, the maximum value for fields returned via uname() was increased (from 8 to 256). To accommodate the larger size, a format change was necessary. A new magic number, FBACKUP*LABEL, was created to distinguish this new format.
Likewise with HP-UX 10.20, HP-UX added support for large files (greater than 2GB) and increased UID/GIDs (greater than 60,000). The magic number associated with this release through HP-UX 11i Version 2 (inclusive) is FBACKUP_LABEL.
Archives and files with formats and attributes that are unsupported on previous HP-UX releases could cause severe problems or unpredictable behavior if attempts were made to restore onto these systems. For this reason, fbackup creates tapes with a magic number that is only recognized on releases which support the features and format being archived. This prevents fbackup tape archives from being restored on earlier HP-UX systems than are supported. frecover still reads all tape formats so that fbackup tape archives created on earlier HP-UX systems can be restored.
EOF marks are used for checkpointing on all magnetic tape devices. On DLT tape devices, these EOF marks are also used for fast searching on a selective recovery; "fast searching" in this case means spacing to the nearest checkpoint before the desired file, and then reading until the file is found. With this dual purpose for checkpoints, caution should be used when changing the checkpoint frequency parameter.
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 programming 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 consumed.
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 HP7980. 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 blocksperrecord 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. etc.
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