Table of contents
- Backup "data" exists in the form of "backup images" created by Amanda.
- "Backup volume images" are created by Amanda client programs and are stored in one or more recording "medium" (whether logical or physical "medium").
- Backup volume images are composed of a sequence of one or more "DLE images" created by Amanda applications.
- Amanda stores the DLE images in a "staging area", and then moves the images to backup media, subject to a "media used per backup run" limit.
- If a DLE image does not completely fit on the media allocated to the backup run, the DLE image remains in the staging area.
- DLE images may be "split" into "chunks" (need to fix this term), so that individual DLE images may span multiple media ("media spanning").
- Physical tapes, DVDs, etc. are examples of Amanda recording "media". For disk-based and S3 backup devices, "vtape" mediums are used.
- The "backup volume images" created during a single Amanda "backup run" contain all of the backup data collected by Amanda from backup clients for each "DLE" in the "backup set".
- "Backup volume images" may span multiple "backup volume mediums", if "spanning" has been enabled by setting "backup media per run" to a value greater than "1 medium" on the "Backup When" page.
- "Backup volume" refers to the logical collection of "backup volume images" and "backup volume media" used for a single Amanda "backup run".
- A "medium" occupies a "slot" in a "device binding".
- A "device binding" defines a device and device properties for use by a specific "backup set".
- A "device binding" is defined on the new ZMC "Backup Where" page by identifying a "device profile" and defining the properties and characteristics unique to the "backup set".
Without the concept of "medium"/"vtape" some media management and backup configuration features in ZMC become nearly impossible to understand and explain in the GUI. Merging the distinctly different concepts of "vtape", "slot", "volume", and/or "data" leads to ambiguities and confusion. Thus, I propose maintaining these distinctions in the ZMC, as long as the ZMC GUI exposes form fields and emits output requiring such distinctions.
ZMC Devices
Storage devices are first created in ZMC as device profiles. These profiles are then connected to a ZMC backup set to create a "device binding". A device profile specifies general, immutable, characteristics of a storage device, while a device bindings provide backup-set specific values for the device (e.g. which slots to use).
ZMC Config Files
For the docs? Definitely for internal consumption, and possibly edited for customers. The information below explains how to easily bypass our license restrictions, so lets include an approval / edit cycle involving Paddy and Chander, before publishing anything to AEE docs, KB articles, etc.
When manually editing DLEs and using ZMC to also manage the Amanda configuration / disklist file, certain additional requirements are imposed by ZMC on the disklist file format.
Product of brainstorm between Gavin & Paul follows:
- DLEs must have a property "zmc_type". Without this property, ZMC will ignore
the DLE. Thus, cloning/copying a ZMC-created DLE and then removing "zmc_type" defeats ZMC's limited license usage restriction on each backup type.
- DLEs must have exactly one dumptype named "zmc_*_base", where '*' names a
backup plugin type (e.g. 'solaris', 'unix', 'windows', 'linuxOracle', 'pgsql', etc.). This dumptype will be called the "backup plugin dumptype".
- DLEs must have exactly one "application dumptype". Application dumptypes
wrap a previously defined application-tool in a dumptype definition. The wrapping may include other normal dumptype parameters that override earlier copies of that parameter. For example, a DLE may specify both "zmc_solaris_base" and "zmc_amsuntar_app". The "zmc_*_base" dumptype must be the first item in the DLE definition. The "zmc_*_app" must be the *last* item in the DLE definition. In the example above, "zmc_amsuntar_app" includes an override for "estimate", and forces that parameter to have the value "server" (i.e. the only supported value). This way, even manually edited DLEs will comply with constraints imposed by Amanda application plugins.
- If customers need to alter a dumptype in
/etc/amanda/templates.d/zmc_dumptypes, they should instead copy it to /etc/amanda/templates.d/zmc_user_dumptypes and edit the copy. The former file will be upgraded (overwritten) when upgrading AEE.
ZMC=>Amanda Terminology Translation
- archive (applied to media) = setting "no-reuse" column in tapelist (see medium status)
- backup cycle = Amanda's "dumpcycle" parameter.
- backup set: A fully configured ZMC backup set includes:
- backup volumes per run = "runtapes" parameter.
- Amanda configuration
- device binding named /etc/amanda/<Amanda configuration>/[disk|changer|tape|s3]-[2|3]-<device profile name>.yml
- device binding configuration file created by Yasumi from the YAML file above, have the same file name, but a ".conf" suffix.
- Amanda <device-profile-name>-changer.conf containing the usual things found in Amanda changer.conf files.
- amanda.conf file with: includefile <binding.conf file from above>
- backup volume = all rows in the Amanda configuration's "tapelist" file having the same timestamp
- chunk = split
- device binding = sum of a per-device "changer.conf" file, and all the Amanda ".conf" parameters for a particular physical (e.g. tape changer) or virtual device (e.g. S3, Amand vtape changer).
- media = one or more vtapes/tapes/etc.
- medium status = a row in Amanda configuration's "tapelist" file
- volumes in rotation = Amanda's "tapecycle" parameter.
- many more to come