How To:Split Dumps Across Tapes

From wiki.zmanda.com
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This article is a part of the How Tos collection.

Amanda can span dumps across multiple volumes, enabling backups of DLEs larger than a single volume.

In Amanda earlier than Amanda-3.2, this was done with some dumptype parameters. For these versions, see How To:Split Dumps Across Tapes (Amanda-3.1 and earlier). This sort of configuration is deprecated in Amanda-3.2, but will still work.

Anatomy of Spanning

Briefly, Amanda spans by splitting each dumpfile into a series of parts, allowing for different parts to existing on different volumes. Parts have a configurable part size.

For most devices, Amanda can detect the end of a volume early enough to finish up a part cleanly (this is called LEOM support - logical end-of-medium). If this is the case, Amanda simply starts a new part on the next volume.

For devices that do not support LEOM, Amanda may fail to write a particular part completely. In this case, Amanda automatically retries the same part on the next volume, and the failed/partial part will be ignored during recoveries. In order to support retrying, Amanda must be able to "rewind" a part back to its first byte. Amanda supports a number of techniques to accomplish this. If holding disk is in use, Amanda simply re-reads the failed part from holding disk. Otherwise, Amanda can cache each part either on disk or in memory. Caching on disk enables larger parts, as memory is typically more constrained than disk space.

Configuring Spanning

First, if you want to span volumes, you'll need to let Amanda write to more than one volume in a run. To do that, set the globa runtapes parameter to something bigger than one, e.g.,

runtapes 5

Note that this parameter is a maximum, and while Amanda will try to fill it (promoting fulls if necessary), all 5 (in this case) tapes may not be used on every run. Any unused tapes will remain available for use on the next run. This can be helpful when your backup sizes change drastically from run to run.

The remaining spanning parameters are specified in the tapetype definition. You should already have a tapetype definition, named by the tapetype parameter, e.g.

tapetype "DLTXXVII"
...
define tapetype "DLTXXVII" {
   ...
}


The available spanning-related tapetype parameters are:

part_size
the size of the parts that Amanda should write
part_cache_type
the type of caching Amanda should do, when necessary (none, memory, or disk)
part_cache_dir
the directory in which the disk cache should be stored
part_cache_max_size
the part size to use when caching is in use

All of these parameters should appear in the tapetype definition.

Selecting a proper split size is a delicate matter. If the parts are too large, substantial storage space may be wasted in failed parts. If too small, large dumps will be split into innumerable tiny dumpfiles, adding to restoration complexity; furthermore, an excess of filemarks will cause slower tape drive operation and reduce the usable space on tape. A good rule of thumb is 1/10 of the size of a volume of storage media.

Disk Backups (Vtapes)

For vtapes, spanning is automatically enabled, as the VFS device supports LEOM. You can add a part_size if you'd like to split dumps into smaller parts; otherwise, Amanda will just fill each vtape with a single part before moving on to the next vtape.

Tape Backups

Some tape drives and kernels support LEOM. You can find out if yours does by running amtapetype(8). Note that the results of this test are not specific to the tape drive, as the kernel drivers must also support LEOM properly.

With LEOM Support

If your tape drive does support LEOM, you're in luck! Amanda can already span tapes. As a fail-safe, Amanda will still retry failed parts (which may happen if your tape drive fails -- not that that would ever happen!), if you set a part size. If your tape drive does support LEOM, first set the corresponding global device property:

device_property "LEOM" "TRUE"

(you could also set this in a 'define changer' section, if you'd like)

Then set the part size:

 part_size 40G # use about 1/10 of your tape size

Without LEOM Support

If you tape drive does not support LEOM, that's OK! Set the LEOM property to false:

device_property "LEOM" "FALSE"

and set up your splitting parameters in the tapetype definition. If all of your dumps use holding disk, you can just use

 part_size 40G # use about 1/10 of your tape size

if some of your dumps will skip the holding disk (this generally happens when dumps are larger than the holding disk), then set up some caching parameters. For splitting in memory:

 part_size 40G # use about 1/10 of your tape size
 part_cache_type memory
 part_cache_max_size 3G # use roughly the amount of free RAM on your system

For disk splitting:

 part_size 40G # use about 1/10 of your tape size
 part_cache_type disk
 part_cache_dir /mnt/sparedisk

If you have limited disk space for the part cache, specify a maximum size for cached parts:

 part_cache_max_size 30G # assuming only 30G of disk space is available

Cloud Storage

Cloud storage volumes are effectively infinite, so there is no EOM - thus, no need for spanning!

Related User's List Posts

  • Syntax and LEOM Configuration [1]

See Also