Backup3G/User Guide/Appendix C - Backup Methods and Drivers

From Documentation

Current revision

A backup method is the ‘how to’ of a backup step. It contains the command(s) that will write the backup data. backup3G comes with a number of standard backup methods and driver scripts.

These scripts use standard UNIX utilities to provide a uniform set of facilities for backing up and recovering files across a network. In effect the drivers ‘top up’ the basic facilities provided by cpio, dump, and tar.

This appendix describes:

• how multi-part backup methods work
• how to customize the behavior of backup methods by passing optional arguments from a backup item
• features of the driver scripts supplied with backup3G.

Appendix D—Defining Backup Methods describes how to create a new backup method.

Multi-part Backup Methods: How They Work

The recommended method for multi-part backup of filesystems and lists of files and directories is ‘full cpio - MP’. The recommended backup method for multi-part backup of raw partitions and large files is ‘image copy - MP’.

Multi-part backup methods based on FSmcpio call a program FSbusplit to split the backup. FSbusplit uses the size of the file or filesystem and the part size and capacity of the backup medium to calculate how many parts and volumes to split the backup over. FSbusplit uses an algorithm that tries to minimize the number of partitions needed.

By default, FSmcpio can back up files larger than the part size but smaller than the capacity of the volume. FSmcpio simply writes the file to a single larger than usual part. Files larger than the volume’s capacity are rejected with a warning message. To reject files larger than the part size, specify the -B flag to FSmcpio in the Options field of the backup item.

The multi-part methods automatically issue a “change media” request after writing the last part on each volume. The method used to change volumes depends on the logical drive definition. If the last partition on the previous volume was incomplete it is rewritten in full at the start of the new volume.

Although it isn’t mandatory, it is best if multi-part backup steps start writing at the beginning of a volume (backup3G assumes this when it does its capacity calculations). If the multi-part step starts half-way through a volume, it’s likely to write up to the physical end-of-volume, and so the last part will have to be restarted on the next volume.

To sum up, if a multi-part step is not the first in a job to write data, you should insert a ‘change media’ backup step before it to force backup3G to start writing at the start of a new volume.

Each of the multi-part backup methods has a corresponding ‘single-part’ method.

For example:

‘full cpio’

writes a backup step in cpio format to a single tape file or part.

‘full cpio - MP’

writes a backup step in cpio format, if necessary in more than one part or over more than one volume.

We recommend that you use a multi-part backup method where possible, particularly where the directory being backed up:

• won’t fit on a single volume
• is growing, and may not fit in future
• is very large, and you want to speed recovery of selected files by splitting the backup into several parts.

For backups that are guaranteed not to exceed the capacity of a single volume, the advantage of the single-part methods is that they will start up marginally faster.

Capacity and Part Size

You can tune the Multi-part size and Capacity parameters for a media type to make your backups run more efficiently. The following principles should be used as a guide.

• Capacity should be slightly less than the theoretical maximum capacity of the media type, to allow for the label and for variations in the actual tape length among different vendors. A rule-of-thumb is to subtract about 2%.
• Multi-part size should be larger than the size of the largest file.
• One part cannot span volumes, so Multi-part size must not be larger than the capacity of the volume.
• It should be small enough so that the time taken to read or write a part is fairly small (say less than 10 minutes).
• Small parts are more efficient if the data are compressed, either by hardware compression or by use of a compressed backup method. See Data Compression.
• Large parts are faster for recovering a full filesystem but slower for recovering selected files.

If the Multi-part size field is left blank, then the Capacity field will be used in its place. That is, each volume will contain one whole partition.

If both Capacity and Multi-part size are defined, backup3G calculates how many partitions can fit on the output volume, and requests a media change after it has written the last full partition or if an I/O error (End of Media) occurs.

If Capacity is not defined, it defaults to unlimited capacity. This means that partitions will be written to the volume until an I/O error occurs. backup3G assumes this means that end-of-volume has been reached, though it could also be due to some other cause such as a physical defect on the tape.

Caution

By default, FSmcpio will back up a file larger than the part size. However, if Capacity is null, the partitioning algorithm can’t reject files larger than the real capacity of the volume. The backup step will keep requesting a new volume, trying to write the file in full, until it runs out of scratch volumes or is cancelled.

To avoid this, either exclude such files from the backup; set a realistic value for capacity; or specify the -B flag in the Options field.

Passing Options to a Backup Method

Each backup item includes an Options field, with which you can pass optional flags and arguments to the backup command as command line parameters.

For example, the cpio backup methods supplied with backup3G accept several flags that change the way backups are done. Some of these can be specified through fields in the backup item. One example is the Index field. This passes the -I flag that instructs FScpio to create an online index. Other flags have no field set aside for them in the ‘Backup item’ prompt form. Some examples:

-s <files>  back up this list of files
-x <files>  exclude from the backup this list of files
-d          perform a deleting backup
-z          use the alternate index method ls_index

Example: exclude unwanted files from backup

You have a backup item to backup the filesystem /user2 on host mama using the backup method ‘full cpio - MP’. You want to exclude core and object files and certain temporary files of the form tmpxxxx. To exclude these files from the backup, you would:

1. Select Maintain backup jobs from the backup3G configuration menu.
2. Select Items > Maintain.
3. Select the backup item from the list displayed.
4. Select Maintain > Change.
5. In the Options field, enter -x "*/*.o */core */tmp*"

Figure 45 — Passing arguments to the backup method

These options will be appended to the cpio command at run time.

Note

Backup3G does not validate any of the options when you create or change the backup item. If any of the options are unrecognized or the syntax is incorrect, the backup step will fail when the backup job tries to execute the command.

You can specify more than one flag. The only limit is the length of the Options field.

If you have added your own backup methods to the set provided with backup3G, use Options to take advantage of any flags and features that are recognized by your backup command but aren’t built in to the backup item prompt form.

Backup3G Driver Scripts

Backup3G includes several backup drivers. These drivers use the standard utilities cpio, dump, and tar, and provide a uniform set of facilities to backup and recover files across a network and to create online indexes. In effect the drivers ‘top up’ the basic facilities provided by cpio, dump, and tar to a common level.

Another driver, FSimage, performs an image copy of a raw disk partition or very large file.

Table 10 shows what features are supported by each driver. Refer to the manual page for more information. Generally we recommend that you use a backup method based on FSmcpio. For particular uses other drivers may be more suitable. See below for notes on working with particular FS backup drivers.

¹writes a 1 KB header followed by a byte-by-byte copy of the data.

²dump is not available under AIX or SCO.

³FSdump uses the ls_index method to create the index when the backup first starts.

⁴copies the specified files/directories to another directory using cpio -p.

FScpio

FScpio can’t back up a read-only filesystem

FScpio is not suitable for backing up a read-only filesystem.

There are two problems. First, cpio will not be able to reset the access times of the files. Second, the .FSbackup file cannot be created as FScpio cannot write to the filesystem.

To back up a read-only filesystem you should use a different backup method, one not based on FScpio.

Backing up symbolic links with FScpio

The FScpio -y flag allows backup of data pointed to by symbolic links, whereas normally only the links themselves are backed up.

FScpio uses find(1) to gather the list of files to be backed up. The -y flag tells find to follow symbolic links.

Note that if the file being pointed to is in another filesystem, you must also use the -m flag (‘cross mount points’) to allow FScpio to back up the file.

FSdump

FSdump backup methods and online indexes

Backup3G generates an online index by extracting directory information about the files being backed up, using options on the underlying backup command. For example, both cpio and tar have flags -tv that list file details. The backup drivers FScpio and FStar use these flags (with a little help from sed) to generate output similar to that produced by ls -l.

However, the BSD dump command doesn’t have any options to produce equivalent file information. FSdump gets around this by doing an ls command just before the backup. However, there are a few points you should be aware of:

• the filesystem must be mounted to do an index; dump permits backup of an unmounted filesystem, but the ls command will fail
• the index can only be created at the same time as the original backup. FScpio and FStar can extract file information later from the backup volume; FSdump cannot. This also means that you cannot verify a dump format backup by creating an index from the backup volume, as you can with other methods
• because the ls is done before the dump starts, the index may not be completely accurate if the filesystem is active during the backup. For example, if a file is changed after FSdump creates the index but before the file is backed up, the backup itself will be correct but the index will show the modification time, permissions, owner and file size as they were before the file was edited.
  If this is a problem, the safest method is to mount the filesystem as readonly before running the backup, then re-mount it as read-write afterwards. Alternatively, you can define backup methods that will perform the mounts.

FSimage

Recovering a disk partition using FSimage

Note that there can be a potential problem on some systems when restoring an image backup:

If the size of the disk partition is not a multiple of the tape block size, some tape drives will pad out the incomplete last block. When the partition is restored the last block is written in full back to disk. The result is that the restored partition is larger than the original. Most operating systems handle this correctly, but success cannot be guaranteed for all tape drives and all systems.

The image copy methods based on FSimage can write a 1 KB header. This is used in the recovery to ensure that the file, when recovered, has exactly the same size, owner, group, and permissions. backup3G writes the header by default; we recommend that you accept this behavior to avoid the padding problem.

If you choose not to have backup3G write a header, another solution is to make sure that the size of the disk partition is a multiple of the tape block size. For example, with a 200 MB disk partition (204,800 KB), possible tape block sizes are: