Backing Up Data

One of the most important goals of system administration is to protect the integrity of the valuable data on a system. There are several aspects to this (for example, securing the system against intruders, and protecting the system's data against deliberate or accidental removal). Many things (for example device failure) can cause data loss, and there are many tools to insure you can recover valuable data in the event of a loss of the primary copy:

Data Backups

By making copies of disk-based data onto external media that you can store away from your system, you ensure that you can recover the data should something happen to your primary copies. Data can also be shipped over a network to a computer at a different location. The important thing is to have copies of all your important data somewhere other than on your system. To protect against loss from flood, fire, or other disasters, you should store at least one copy of all important data in a location other than where your system resides.

The term data backup usually refers to the act of making an offline copy of the data being protected.

Disk Mirroring

By making multiple identical copies of all data as they are written, you ensure that you can recover/access data (from a mirror copy) in the event a device fails and the copy of that data that is on it is destroyed.

RAIDs

Redundant Arrays of Independent Disks are another form of mirroring data.

Serviceguard

HP sells a product called Serviceguard specifically designed to protect not only disk based data, but also all aspects of your computing environment, minimizing the downtime that can result from the loss of use of a specific server or some of its peripherals.

This section deals with data backups. For additional information on the other ways of protecting your data (mentioned above), see Appendix A.

There are many utilities to back up your data to offline media (for example, optical media or magnetic tape such as DLT cartridges).

Table 3-3 compares several commonly used utilities based on many important backup criteria. This discussion focuses on the file backup and file recovery procedures of fbackup, OmniBack II, tar, and cpio. Online backup of a JFS snapshot file system is also explained. Refer to the HP-UX Reference for information on the other backup and restore utilities: dump, ftio, pax, restore, rrestore, vxdump, and vxrestore.

The following topics are described in this section:

Choosing the Type of Storage Device

When you evaluate which media to use to back up your data, consider the following:

How much data do you need to back up (rough estimate)?
How quickly will you need to retrieve the data?
What types of storage devices do you have access to?
How automated do you want the process to be? (For example, will an operator be executing the backup interactively or will it be an unattended backup?)
How quickly will you need to complete a backup?




	NOTE: To ensure against the possible destruction of your system and its data, store the backup media away from your system.

Use Table 3-2: “Criteria for Selecting Media ” to help you determine which storage device to use for your backups. This table compares the supported device types relative to each other; it does not give specific values. For detailed information, consult the documentation that came with your tape or disk drive for capacity information about the storage media.

Table 3-2 Criteria for Selecting Media

Storage Device Type	Holds Lots of Data?	Recovers and Backs Up Data Quickly?	Suggested for Unattended Backup?
DLT tape drive	Excellent	Excellent	No ^[1]
DLT tape library	Excellent	Excellent	Yes
DDS format (DAT) tape drive	Very Good	Good	No ^[1]
DDS format (DAT) tape drive autoloader	Very Good	Good	Yes
Hard disk	Good	Excellent	No
Optical disk multi-disk library	Good	Good	Yes ^[1]
Optical disk single drive	Good	Good	No ^[1]
^[1]You can perform an unattended (automatic) backup if all of the data will fit on one tape, optical disk, and so on.

Choosing a Backup/Recovery Utility

There are a number of different backup methods you may wish to choose from depending on your system backup needs and your workgroup configurations. Some recommended backup methods are:

HP OpenView Omniback II
HP SMH (System Management Homepage)
HP-UX fbackup/frecover utilities

Choosing HP Omniback for Backup

If you are backing up large numbers of systems, the HP Omniback II software product can be particularly useful. HP Omniback II is faster than other backup methods and provides for unattended backup as well. It allows you to efficiently centralize and administer backup procedures.

Using HP Omniback II involves setting up a database server and running Omniback software that directs and records the backup process for clients.

For a detailed description, see the HP OpenView Omniback II Administrator’s Guide.

Choosing an HP-UX Backup/Recovery Utility

Table 3-3 compares several HP-UX backup utilities based on selected tasks. For details about specific commands, see the associated manpage.

Table 3-3 A Comparison of HP-UX Backup/Recovery Utilities

Task	Backup Utility
Task	fbackup frecover	cpio	tar	dump restore^[1]	vxdump vxrestore^[2]
Recover from tape errors	Minimal data loss.	`resync` option causes some data loss.	Not possible.	Skips over bad tape.	Skips over bad tape.
Efficient use of tape	Medium.	Low.	High.	High.	High.
Backup/ restore across a network	Possible.^[3]	Possible^[4]	Possible.^[5]	Possible. ^[6]	Possible. ^[7]
Append files to the same backup tape	Not possible.	Can use the no-rewind device file to append multiple dumps.	Use tar -r.	With dump, can use the no-rewind device file to append multiple dumps. ^[8]	With vxdump, can use the no-rewind device file to append multiple dumps. ^[8]
Multiple, independent backups on a single tape	Not possible (fbackup rewinds the tape).	Use mt with no-rewind device to position the tape, then use cpio.	Use mt with no-rewind device to position the tape, then use tar.	Use mt with no-rewind device to position the tape, then use dump. ^[8]	Use mt with no-rewind device to position the tape, then use vxdump. ^[8]
List the files on the tape	Relatively easy^[9]	Complex (must search entire backup).^[10]	Complex (must search entire backup). ^[11]	Relatively easy.^[12]	Relatively easy.^[13]
Verify backup (Also see the above entry.)	Use the `-xNv` options.	Not possible.	Not possible.	Not possible.	Not possible.
Find a particular file	Relatively easy; use frecover.	Complex (Wildcards are allowed; searches the entire tape.)	Complex (Wildcards not allowed; searches the entire tape.)	Relatively easy; interactive commands available. ^[14]	Relatively easy; interactive commands available. ^[15]
Do an incremental backup	Has a powerful multilevel backup.	Use find to locate new or modified files.	Use the `-u` option to add any new or modified files to the end of archive.	Possible on a single file system only.	Possible on a single file system only.
List files as they are backed up or restored	Possible. Use `-v` option.^[16]	Possible. Use `-v` option.^[17]	Possible. Use the `-v` option. ^[18]	Possible (on a restore only). ^[19]	Possible (on a restore only). ^[20]
Do a backup based on selected criteria (such as group)	Not possible.	Possible. Use find.	Not possible.	Not possible.	Not possible.
Cross disk or file system boundaries	Use fbackup -n to cross NFS boundaries.	Possible. Use find.	Possible.	Not possible.	Not possible.
Restore absolute path names to relative location	Relative to the current directory. Use `-X` option.	Limited. Can specify path name on each file with cpio -ir.	Not possible.	Relative to the current directory. Use restore -r.	Relative to the current directory. Use vxrestore -r.
Interactively decide on files to restore	Not possible. ^[21]	Can specify path or name on each file with cpio -ir.	“Yes” or “no” answer possible using tar -w.	In interactive mode, can specify which files.	In interactive mode, can specify which files.
Use wildcards when restoring	Not possible.	Possible.	Not possible.	Only in interactive mode.	Only in interactive mode.
Ease of selecting files for backup from numerous directories	High.	Medium.	Low.	Not possible.	Not possible.
Back up a snapshot file system	Not possible.	Possible.^[22]	Possible.^[22]	Not possible.	Possible.
Backup/ restore extent attributes	Possible.	Not possible.	Not possible.	Not possible.	Possible.
^[1]For High Performance File Systems (HFS) only. For remote systems, use rdump/rrestore ^[2]For Journaled File Systems (JFS or VxFS). For remote systems, use rvxdump/rvxrestore ^[3]Use the “`-f remote_system:remote_device_file`” option on fbackup ^[4]Use *find \| cpio -o \| remsh `host`* "dd of=`/dev/tape` obs=`blocksize`" ^[5]Use find \| tar cvf - \| remsh `host` "dd of=`/dev/tape` obs=`blocksize`"** ^[6]Use rdump -f `remote_system`:`remote_device_file` ^[7]Use rvxdump -f `remote_system`:`remote_device_file` ^[8]Separate backups will be on one tape. ^[9]Use *frecover -f `device_or_file`* -I index or frecover -rNvf `device_or_file` 2> index ^[10]Use cpio -it < `device_or_file` > index ^[11]Use tar -tvf `device_or_file` > index ^[12]Use restore -tf `device_or_file` > index ^[13]Use vxrestore -tf `device_or_file` > index** ^[14]Use restore -i -f `device_or_file` ^[15]Use vxrestore -i -f `device_or_file` ^[16]Use *fbackup -i `path`* -f `device_or_file` -v 2 >index ^[17]Use find . \| cpio -ov > `device_or_file` 2 > index ^[18]Use tar -cvf `device_or_file` * 2 > index ^[19]Use restore -t or restore -trv. ^[20]Use vxrestore -t or vxrestore -trv. ^[21]However, you can use frecover -x -i`path`** to specify individual files. ^[22]If the snapshot file system has extent attributes, you will need to use vxdump `filesystem`.

Determining What Data to Back Up

To restore your system after a complete loss of data, you will need copies of the following:

all user files
system files that you have customized (such as /etc/passwd)
system files that you have added since your original installation
any additional products that were installed since your original installation

Defining What Files and Directories to Back Up

If you are backing up using the fbackup command, you must define which directories and files you want to back up:

Included Files

Included files are directories and files to include in your backup. When you specify a directory, all of the files and subdirectories are included in the backup. Identify included files with the -i option of the fbackup command or with a graph file (see following definition).

Excluded files

Excluded files are files within your included directories to exclude from the backup. In other words, they are the exceptions. Identify excluded files with the -e option to the fbackup command or with a graph file (described below)

Graph files

Graph files are text files that contain a list of directories and files to back up. If you use HP SMH to back up your system, HP SMH creates the graph files for you (in /etc/sam/br) using the included and excluded files. Graph files contain one entry per line. Entries that begin with the character i indicate included files; those that begin with the character e indicate excluded files. For example:

i /home
e /home/deptD

The above file will cause all of the directory /home with the exception of /home/deptD to be backed up.

You can identify a graph file with the -g option of the fbackup command.

Determining How Often to Back Up Data

Evaluate the applications running on your system and the needs of your users to determine how critical the data on your system is to them. Consider the following:

How often do the contents of files change?
How critical is it that files’ contents be up-to-date?

Full Backups vs. Incremental Backups

Once you have identified a list of files to include and exclude, decide whether you want all of the files represented by your list to be backed up (a full backup) or only those files that have changed or that have been created since the last time you backed up this set of files (an incremental backup).




	NOTE: A full backup does not mean a backup of every file on your system. It means a backup of every file on your include list, regardless of when it was last backed up. To ensure consistency, do not modify or use different graph files between full and incremental backups

Backup Levels

A backup level is a level you define that identifies the different degrees of incremental backups. Each backup level has a date associated with it that indicates when the last backup at that level was created. You can have up to ten backup levels (0 through 9). For example, level 0 is a full backup; level 1 backs up files that changed since the last level 0 backup; level 2 backs up files that changed since the last level 1 backup, and so on.

This brings up the question, “how does fbackup know when the previous backup was created?” This information is contained in the file /var/adm/fbackupfiles/dates, a file that is updated only when all of the following conditions are true:

The -u option is used with fbackup.
A graph file is used to indicate which files should be included/excluded when a backup is performed.
Neither the -i nor the -e option is used (graph file used instead)
The backup completed successfully

Backup levels are a way of specifying varying degrees of incremental backup. For example, suppose you wanted to set up the following backup schedule:

On the first day of the month, back up an entire set of selected files (a monthly, full backup).
Every Friday, back up all files in the selected set that have changed since the previous Friday (a weekly, incremental backup so that you can back up and restore files that have been active within the month, relatively quickly).
Every day except Friday (or the first of the month), back up all of the files in the selected set that have changed since the previous day (a daily, incremental backup, so that you can quickly back up and restore files that have been active within the last week).

There are three “layers” (levels) associated with the above schedule (the once per month level, the once per week level, and the once per day level). The once per month level is a full backup. The other two are incremental backups. The problem is how to distinguish between the two types of incremental backup. This is accomplished with backup levels.

The file /var/adm/fbackupfiles/dates contains information about when the last backup at each backup level was performed. This information is used by fbackup, along with the modification date stamps on the files themselves, to determine which files in the specified set are to be included with the backup that is currently being created.

As previously stated, you can have up to 10 backup levels. When you run fbackup, you can tell it which level to use. fbackup will use the level you give it as follows:

Level 0 is always considered a full backup
Higher levels are generally used to perform incremental backups.
When doing an incremental backup of a particular graph (specified by a graph file name), at a particular level, fbackup will search the file /var/adm/fbackupfiles/dates to find the date of the most recent backup of the same graph that was done at a lower level. If no such entry is found, the beginning of time is assumed. All files in the specified graph that have been modified since this date are backed up

Example of Setting Backup Levels

Assume you want the following three backup levels:

Level 0 - full monthly backup
Level 1 - weekly backup on Friday
Level 2 - daily backup, except Friday

There are three ways you can implement these levels: use HP SMH, enter the fbackup command and specify a backup level on the command line, or automate the commands (see “Setting Up an Automated Backup Schedule”). The figure below illustrates the level numbers for implementing this example.

Date:         1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 ... 1
Day:          Su M  T  W  Th Fr Sa Su M  T  W  Th F  Sa Su ...
 
Backup level  0  2  2  2  2  1  2  2  2  2  2  2  1  2  2  ... 0

If your data becomes corrupt on Thursday the 12th, do the following to restore your system to its Wednesday the 11th state:

Restore the monthly full backup tape from Sunday the 1st.
Restore the weekly incremental backup tape from Friday the 6th.
Restore the incremental backup tape from Wednesday the 11th.

For information on the actual method and commands to restore these tapes, see “Restoring Your Data”.

Backing Up Your Data Using the fbackup Command

The /usr/sbin/fbackup command is the recommended HP-UX backup utility. The fbackup command can do the following:

indicate specific files or directories to include or exclude from a backup
specify different levels of backup on a daily, a weekly, or monthly basis
create an online index file
when used in conjunction with the crontab utility can automate backups




	NOTE: As fbackup does its work, it will not back up files that are active (open) when it encounters them. For this reason, it is best to back up your system when there are few or no users logged in. If you can do so, you should change your system’s run-level to the system administration state (single-user mode) before using fbackup. This will insure that you are the only one logged in when the backup is run. As a result, a minimum number of files will be active, thereby reducing the number of files that are intended for, but not included in, the backup. When changing to the single-user state, all the subdirectories are unmounted. Therefore, you must remount them if necessary before backing up. For information about changing to the single-user state, see shutdown(1M). If you shut down the system to single-user state, mount the file systems (other than root (`/`)) that you want backed up.

General Procedure for Using the fbackup Command

To use the fbackup(1M) command:

Ensure that you have superuser capabilities.
Ensure that files you want to back up are not being accessed. The fbackup command will not back up files that are active (opened) or locked.
Verify that the backup device is properly connected.
Verify that the backup device is turned on.
Load the backup device with write-enabled media. If the backup requires additional media, fbackup will prompt you when to load or change media.
If possible, change to a single-user state. Then mount any directories you want to back up.
Create the backup using fbackup. For example, the command
fbackup -f /dev/rmt/0m -i /home
can be used to back up the entire contents of /home to the device file /dev/rmt/0m. For more information on fbackup, see fbackup(1M). For more information on the /dev file formats, see the Configuring HP-UX for Peripherals manual and see mt(7).

Creating the Index File on the Local Device

If you use the fbackup command, an index is written at the beginning of each tape listing all files in the graph file being backed up. However, since this index is written before the files are actually backed up, if a file is removed after the index is written but before the file is backed up to tape (or something else happens that prevents the file from being backed up), the index will not be completely accurate.

If you tell fbackup to make an online index file (using the -I option), it will create the file after the backup is complete. Therefore, the only index that will be accurate is the online index, which is produced after the last volume has been written (the index created using the fbackup -I option).

Also, fbackup assumes all files remaining to be backed up will fit on the current tape for the index contained on that media. Therefore, if you did not use the -I option on fbackup or removed the index file, extract an index from the last media of the set.

Use the /usr/sbin/frecover utility to list the contents of the index at the beginning of a backup volume made with fbackup. For example, the command

frecover -I /tmp/index2 -f /dev/rmt/0m

specifies that the device file for the magnetic tape drive is /dev/rmt/0m and you want to put the listing of the index in the file /tmp/index2.

Backing Up NFS Mounted Files with fbackup

When backing up files that are NFS mounted to your system, fbackup can only back up those files having “other user” read permission unless you have superuser capability. (To recover the files, you will need “other user” write permission.) To ensure the correct permissions, log in as superuser on the NFS file server and use the root= option to the /usr/sbin/share command to share the permissions, then back up as root. For more information, see share(1M) and the NFS Administrator’s Guide.

Examples of fbackup Commands

Here are a series of examples showing a variety of ways that fbackup can be used.

Example: Backing Up to a DDS (DAT) Tape

For this example, we want to do a full backup and do not care about doing future incremental backups. Therefore, we do not need to specify a backup level (nor do we need to use the -u option to update the dates file). We could also specify “level 0” to indicate a full backup.

fbackup -i /home

Example: Backing Up to a DLT Tape

(You plan to do a future incremental backup.)

This example will back up the entire structure except the invoices directory. The device file for this example is /dev/rmt/1h, specified using the -f option. For this example, we need to plan for the incremental backup (next example), so we must do three things:

Use a graph file to specify which files will be included/excluded.
Specify the -u option to update the file /var/adm/fbackupfiles/dates.
Specify a backup level.

Because this will be a full backup, we’ll use the backup level 0. Any backup level would do as long as it is the lowest backup level in use. See “Backup Levels” for details about how backup levels are interpreted by fbackup.

The graph file for this example will be /var/adm/fbackupfiles/graphs/g1 and its contents will look like:

i /home
e /home/text/invoices

The fbackup command to accomplish the above is:

fbackup -f /dev/rmt/1h -0 -u -g /var/adm/fbackupfiles/graphs/g1

Example: Incremental Backup to a DLT Tape

This example is an extension of the previous one. All characteristics of the previous example will remain the same except that this will be an incremental backup at a point in time following the previous example’s backup.

We’ll use the backup level 5. The exact number is not critical as long as it is higher than the level used in the previous example. See “Backup Levels” for details about how backup levels are interpreted by fbackup.

fbackup -f /dev/rmt/1h -5 -u -g /var/adm/fbackupfiles/graphs/g1

Example: Backing Up to Two Devices

This example will show how it is possible to specify more than one device to receive the output from fbackup. When more than one device is specified, the second one is written to when the media on the first device has filled up. If the media on the first device fills up and the remaining data to be backed up will fit on the media on the second device, an unattended backup is possible. With only one device, a media change would be required in this situation.

Also in this example, an index file will be created called /tmp/index. An index is written to the beginning of each tape, listing all files in the specified “graph” being backed up. However, if a file is removed after the index is written but before the file is backed up to tape (or something else happens that prevents the file from being backed up), the index will not be completely accurate. If you tell fbackup to make an online index file (using the -I option), it will create the file after the backup is complete. Therefore, the online index file will be completely accurate with respect to which files are on each volume of the backup.

For example to back up every file on the entire system to the two magnetic tape drives represented by device files /dev/rmt/0m and /dev/rmt/1m, enter:.

fbackup -f /dev/rmt/0m -f /dev/rmt/1m -i / -I /tmp/index

You would typically use both tape drives in the same tape density mode.

Backing Up Files on a Remote System

If you are administering a workgroup, it is likely that only some of the systems in the workgroup will have storage devices such as tape drives or optical disk drives attached locally. In this situation you will need to perform remote backups.

Remote Backup Using fbackup

To perform a remote backup using fbackup, enter:

#fbackup -f system-name:/dev/rmt/0m -v -i /dir1

For information on recovering files remotely using the frecover command, see “Restoring Your Data”.

Remote Backup Using cpio

cd relative-path

find . -hidden -depth -fsonly hfs -xdev \
  | cpio \ -ovxcB2>/tmp/index \
  | remsh system-name -l user \
  "cat - | dd of=/dev/rmt/0m obs=5k"

If the relative path is root (/), then you will perform a full backup. The /tmp/index file is an index file of the backup. The -v option causes the output to be written to standard error.

Note that cpio via network does not support multiple tapes.

Remote Backup Using tar

To perform a remote backup using tar, enter:

cd relative-path

tar cvf - . | remsh remote-system dd of=/dev/rmt/0m

For information on restoring files remotely using the tar command, “Restoring Your Data”.

Setting Up an Automated Backup Schedule

If possible, use HP SMH to set up an automated backup schedule.

If you use HP-UX commands, you can automate your backup procedure using the crontab utility, which uses with cron, the HP-UX process scheduling facility. For details, see cron(1M) and see crontab(1).




	NOTE: If you schedule fbackup using the crontab utility, be aware that fbackup is an interactive utility. If fbackup needs attention (tape change, device not online, and so on), it will prompt for input. If the input is not provided, an automated backup may fail or not complete.

Creating an Automated Backup Schedule

Use the crontab utility to specify an input file containing information about the backup procedures you want to automate. The crontab utility allows you to specify an input file containing the date, time, and run-strings of the backup procedures (processes) that you want to automate. This file (the input to the crontab utility) contains lines that have six required fields each. The fields are separated by spaces or tabs. Each entry in this file has the following format:

minutes hours dates months days runstring

where:

minutes: Specifies the minutes of the hour (0-59)
hours: Specifies the hours of the day (0-23)
dates: Specifies particular dates of the month (1-31)
months: Specifies particular months of the year (1-12)
days: Specifies particular days of the week (0-6 with 0 representing Sunday)
runstring: Specifies the command line or script file to execute




	NOTE: Specify multiple values in a field by separating them with commas (no spaces), as in `10,20,30`. The value `*` in any field represents all legal values.

Therefore, to schedule the ps command (see ps(1)) to execute at 5:10 p.m. (17:10) on every Friday and Monday during June, July, and August, you would make an entry in your crontab input file that looks like this:

10 17 * 6,7,8 1,5 ps >> /tmp/psfile 2>&1

When using crontab, redirect any output that is normally sent to the terminal to a file. In this example, 2>&1 redirects any error messages to the file psfile.

An example backup strategy may consist of a full backup (performed once per week) and an incremental daily backup. Assume that the backups are to be performed at 4:03am and the media is DDS (DAT) tape. The following crontab file implements the example backup strategy:

3 4 * * 1 incrback >> monbackup
3 4 * * 2 incrback >> tuebackup
3 4 * * 3 incrback >> wedbackup
3 4 * * 4 incrback >> thubackup
3 4 * * 5 incrback >> fribackup
3 4 * * 6 fullback >> satbackupfull

In the above example incrback and fullback are example shell scripts. Be sure to set the PATH variable appropriately or use complete paths to any scripts that you include in the crontab input file. Scripts like these may be used to:

Warn any users who are logged in that the system is going down (for backup purposes).
Shutdown the system (to single user mode).
Mount any file systems that you wish to back up.
Run fbackup to perform the actual backup.
Return the system to multiuser operating mode.

The output redirection can be specified in the crontab input file or within the script contained in the crontab input file.




	TIP: To edit the crontab input file directly, use the crontab -e option.

Displaying an Automated Backup Schedule

To list your currently scheduled processes, enter:

crontab -l

This displays the contents of your activated crontab input file.

Activating an Automated Backup Schedule

Before you activate a new crontab input file, you should view the currently scheduled processes (see “Displaying an Automated Backup Schedule”). Consider adding these processes to your crontab input file.

To activate all of the processes defined in your crontab input file and cancel any previously scheduled processes not defined in your crontab input file, enter:

crontab your_crontab_file

After your crontab backup has been activated, make sure that:

The system clock is set properly.
The backup device is properly connected and the HP-UX I/O system recognizes the device file specified in the fbackup run string.
Adequate media has been loaded in the backup device.
The backup device is connected to your system and is turned on.
The NFS mounted files you want backed up have the correct permissions. See “Backing Up NFS Mounted Files with fbackup” for more information.

Backing Up If You Are Using LVM

If you are running LVM, you must maintain the backup configuration files for each volume group. After making changes to the configuration of the disks or the logical volumes within a given volume group, the vgcfgbackup command is run automatically to record the group’s configuration (vgcfgbackup saves the configuration of each volume group in /etc/lvmconf/volume_group_name.conf).

To ensure recovery of LVM information following disk corruption, you must back up both the /dev and /usr directories. Include the /usr directory in the root volume group during your backup. If, however, the /usr directory was not originally part of the root volume group, you can still create a new logical volume in the root volume group and move the /usr directory within it.

For information on saving volume group configuration information using vgcfgbackup, see HP-UX System Administrator’s Guide: Logical Volume Management.

Backing Up Large Files

A large file is defined as one whose size is greater than 2 GB. See the HP-UX Large Files White Paper Version 1.4 for more information.

Backup Utilities that Support Large Files

The following backup utilities will back up large files.

dd
fbackup, frecover

Neither of the preceding commands require any user intervention to backup large files.

Backup Utilities that Do Not (fully) Support Large Files

The following backup utilities do not support large files:

tar: Supports files <8GB in size
cpio: Does not support large files (>2GB) and cannot process cpio archives containing large files written by pax)
pax: Supports files <8GB in size for ustar and cpio formats, (but will support any size file in pax format).
ftio: Does not support large files (>2GB)

Attempts to back up any files greater than 2 GB using the preceding utilities will fail.

Restoring Large Files

If you use fbackup to back up large files (> 2 GB), then those files can only be restored on a large file system. For instance, suppose that you back up a file system containing large files; you cannot restore those files to a file system that is not enabled for large files.

If a backup contains large files and an attempt is made to restore the files on a file system that does not support large files, the large files will be skipped.

Backing Up a JFS Snapshot File System




	NOTE: Creating and backing up a JFS snapshot file system requires that you have the optional HP OnLineJFS product installed on your system.

The Journaled File System (JFS) enables you to perform backups without putting the file system off-line. You do this by making a snapshot of the file system, a read-only image of the file system at a moment in time. The primary file system remains online and continues to change. Once you create the snapshot, you back it up with any backup utility except dump.

How to Create and Back Up a JFS Snapshot File System

Determine how large the snapshot file system needs to be, and create a logical volume to contain it.
1. Use bdf to assess the primary file system size and consider the following:
  - Block size of the file system (1024 bytes per block by default)
  - How much the data in this file system is likely to change (15 to 20% of total file system size is recommended)
  For example, to determine how large to make a snapshot of lvol4, mounted on /home, examine its bdf output:
  # bdf /home Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol4 40960 38121 2400 94% /home
  Allowing for 20% change to this 40 MB file system, you would want to create a logical volume of 8 blocks (8 MB).
2. Uselvcreate to create a logical volume to contain the snapshot file system.
  For example,
  lvcreate -L 8 -n lvol1 /dev/vg02
  creates an 8 MB logical volume called /dev/vg02/lvol1, which should be sufficient to contain a snapshot file system of lvol4.
  See lvcreate(1M) for syntax.
Make a directory for the mount point of the snapshot file system.
For example,
mkdir /tmp/house
Make and mount the snapshot file system.
In the following example, a snapshot is taken of logical volume /dev/vg00/lvol4, contained in logical volume /dev/vg02/lvol1, and mounted on /tmp/house:
mount -F vxfs -o snapof=/dev/vg00/lvol4 \ /dev/vg02/lvol1 /tmp/house
See mount_vxfs(1M) for syntax.
Back up the snapshot file system with any backup utility except dump.
For example, to use tar(1) to archive the snapshot file system /tmp/house, ensuring that the files on the tape will have relative path names:
cd tmp; tar cf /dev/rmt/0m house
Alternatively, the following vxdump(1M) command backs up a snapshot file system /tmp/house, which has extent attributes:
vxdump -0 -f /dev/rmt/0m /tmp/house