Backup3G/User Guide/Drives and Drive Pools

From Documentation

Current revision

Removable media drives are used in backup3G to write backup and archive data and perform recovery. Typically backups are written to high-capacity tape formats such as DLT, DAT, and Exabyte. backup3G also supports many other tape and disk formats.

This section describes:

• drives and drive pools
• physical and logical drives
• drive operations and load operations.

Autoloading devices such as tape stackers, jukeboxes, and automated tape libraries are supported through an optional module called COSstacker. See the COSstacker User Guide for details.

About Drives and Drive Pools

There are three types of information kept about drives.

• Drive details: the device name and the media types that the drive can read
• Load operations: the commands for loading and unloading media
• Drive operations: the actions that can be performed for reading, skipping through, and rewinding a tape.

Initiate backups from a single master host

All backups are initiated from a single host. This ‘master host’ contains the media database and a table of drives that are available to be used for backups.

Drives and data objects may be physically located on any networked UNIX. Linux or Windows host.

Example

There are three hosts in a network, called hostA, hostB and hostC. Each host has a single tape drive attached. Weekly backups are run from hostA to back up all files on hostA, hostB and hostC. Some of these backups are written to the drive on hostA, and some to the drive on hostB. No backups are run on hostC.

• hostA’s drive table should contain details of the tape drives on hostA and hostB. hostC’s drive doesn’t need to be added to the drive table as it is not used for backups.
• hostB and hostC don’t need a drive table, as all backups are initiated from hostA, the master host.

Drive Pools

If the time available to run backups is limited, scheduling backups to specified drives can be inefficient. You may have jobs waiting on one drive while another is idle.

Instead, you can queue backups to a pool of similar drives so that each job can start as soon as a suitable drive is free. This is especially effective for silos with multiple drives.

Drive pools are defined in the backup3G configuration module, under the Maintain drives and stackers option. To configure a backup to use a pool, simply select the pool name when defining the backup job. Drive pools have an @ symbol at the end of the name to distinguish them from single drives.

Note

All the drives in a pool must be able to read and write the same media type.

Volume changing

Each drive on the network has an associated ‘volume-changing’ mechanism. This is chosen from a table of volume-changing methods, analogous to backup methods. The advantage of this is that a backup job itself doesn’t need to ‘know’ how to load the next volume – the instructions are stored with the drive information. As each volume is finished, the method arranges for the next tape to be loaded. Volumes can be changed manually by an operator, or automatically by a tape stacker device.

Recovering from drive errors

If a multi-volume backup job encounters an I/O error or unexpected end-of-tape, backup3G unloads the volume and the incomplete part is rewritten from the start of the next volume.

Physical and Logical Drives

A physical drive is simply a removable media drive which is physically connected to a computer. However, backup3G treats each physical drive unit as one or more logical drives, depending on:

• which media types the drive can read
• whether the drive can be switched between two or more hosts
• the unit is a jukebox containing multiple drives
• whether it can be loaded both manually and automatically.

Backup3G locks the physical drive while it is in use, to avoid two jobs accessing it from two different logical drives. In this situation the second job is locked out until the first releases the drive.

Some examples:

• Host A has a single cartridge tape drive, called ctape, which will be used to do filesystem backups to QIC-250 tapes and to back up user files to QIC-24 tapes.
  The physical drive ctape should be defined as two logical drives, ctape for using high-density tapes, and ctape-low for low-density tapes. When the site’s backup jobs are being set up, the system administrator would select the logical drive ctape-low for the user backups, and ctape for the filesystem backups.
• DAT-XXX is a DAT drive that can be switched between two hosts, A and B.
  This drive should be defined as two logical drives, A-DAT-XXX and BDAT-XXX. The drive details will be the same except for the operator message and of course the host name. An operator message reminds the operator to switch the drive to the correct host before loading the tape – for example:
  “Please ensure that drive DAT-XXX is switched to host A”
• Y is an Exabyte drive with an attached tape stacker. Backup tapes will be loaded automatically from the stacker, but when files are restored from backup the tapes will be loaded manually into the drive.
  Y should be defined as two logical drives: one with auto-load operations for doing backups; and one with manual load operations to load single tapes for file recovery. The loading location should be set to the stacker location in the first case and the main media library in the second.

Drive and Device Locking

If a backup job is assigned to a physical drive that is still being used by another job, the second job is held until the first job ends and the drive is freed. Note that pending jobs are not queued: if two jobs are waiting on a busy drive, either may run first. Similarly, a load device is locked for the duration of a load or unload operation. If a backup job is assigned to a drive pool, it doesn’t have to wait for a particular drive, but can use any drive in the pool that becomes free.

Caution

If you want to initiate backups from two backup3G master hosts, don’t share drives between them, as one master will not know when the other has locked a device.

Recovery, archive and backup jobs submitted from the backup3G master host are all handled by the backup3G locking scheme. However, if one of the jobs using the drive is not a backup3G job, this scheme will fail.

Drive Operations and Load Operations

Load class

The load operations for a drive are the set of commands that are used to load and unload media. Collectively they are known as a ‘Load class’. Drive operations are the set of commands that can be issued to manipulate a tape once it is loaded.

The standard drive operations are: display status; skip forward or backward N files; rewind; and unload. Not all operations are available on every drive type – for example some but not all drives can eject a tape under software control.

The standard load operations are: load, load next and unload. These can be defined for both manual- and auto-loading drives. Note that ‘load’ and ‘load next’ are mutually exclusive, so only one should be defined for a given load class.

‘Unload’ is valid as both a drive operation and a load operation, but it can have slightly different functions. The ‘unload’ drive operation would normally rewind the tape and take the drive off-line, and possibly eject the tape. For a jukebox the ‘unload’ operation would also return the tape to its slot. If you use UNIX unload commands to unload a volume loaded through backup3G, the information in backup3G’s tables should be updated; refer to How To Perform Tape Drive Operations on page 141 for further information.

New drives

When a new drive is added you specify the class of drive operations and load operations. Then, whenever the drive is used, backup3G issues the correct command to manipulate the volume. The advantage of this is that the underlying commands to load, unload and position media are encapsulated in the drive definition. This means that the person who defines or runs the backup job doesn’t have to learn or remember details specific to the hardware or operating system.

Scheduling Backup Jobs to a Stacker

For sites with stackers it is convenient to pre-load the autoloader with tapes, then schedule several automatic backup jobs to write to the drive in turn without user intervention. If one of the jobs is still running when the following job is due to start, backup3G simply waits for the first job to finish.

There are two main differences between running jobs with a stacker drive as opposed to a manually loaded drive: how and when media are allocated to the job; and how new volumes are changed.

Media allocation

Manually-loaded drive: an operator is prompted to load the first volume for each job as it is scheduled or run.

Auto-loading drive: media allocation is a separate procedure from the running of any individual job. An operator loads a batch of scratch tapes into the stacker, then as each job runs it loads and unloads tapes as required.

Changing tapes

Manually-loaded drive: the user is prompted to load a new volume. The message appears on the user‘s screen if the backup is run interactively, or in the job status field of the Backup Monitor.

Auto-loading drive: as long as there are scratch media available, backup3G automatically unloads the previous volume and loads a new one from the stacker. When all the scratch tapes have been used, backup3G prompts the user to unload the stacker and allocate more tapes so that the current job can run.

Allocating Tapes to a Stacker

Media allocation is the loading of scratch tapes into slots in the stacker. Allocation is done from time to time as required, then backup jobs are run until all the scratch tapes have been used. The used tapes are returned to the media library and a new set of tapes is allocated to the stacker for the next round of jobs. This is done through Move > Alloc scratch in the Media module.

Backup3G asks for a certain number of media of the correct type to be allocated to the load device (that is, the stacker location). You can manually select the volumes yourself or let backup3G choose. backup3G lists the chosen media numbers and asks you to confirm that the tapes have been loaded in the nominated slots.

When a scheduled job runs, backup3G checks each volume to see that it is a scratch tape of the correct media type. If a tape is found that contains live data, backup3G unloads it and tries another volume. If backup3G detects that the wrong tape is loaded, it updates the slot number details in the media table.

It’s a good idea to allocate more scratch tapes than should be needed by the scheduled jobs. Any tapes that were incorrectly loaded are rejected and backup3G uses the ‘spares’ to successfully run all the scheduled jobs.

Insufficient slots in stacker

If the backup job requires more tapes than there are slots in the stacker, allocate as many tapes as the stacker can accommodate (for example if there are six free slots, allocate six tapes); backup3G will run the backup job, automatically issuing “change media” commands to the stacker as each new volume is needed. When the last tape has been used, the job is suspended and the job status changes to show that it is waiting for more media to be allocated.

Note that this requires the operator to check the Backup Monitor screen periodically to see whether it’s time to deallocate the tapes currently in the stacker and allocate some more. See To monitor the status of a backup job on page 95.