AMANDA-DEVICES(7)

📦
version 3.5.4 · 8 versions
, in ubuntu stonking

✨ amanda-devices 💅

ok bestie, this is the manual page for amanda-devices — the whole "how do I talk to my storage devices" situation. grab a snack, it's a long one 🍓

NAME

amanda-devices — Configuring and Using Amanda Devices 👑

DESCRIPTION

so the Device API is basically the ultimate matchmaker 🫶 — it defines a generic interface between Amanda and storage devices like tapes or disks. this page right here is all about the device drivers that ship with Amanda.

heads up tho: this is the user-level description of the API, so it does NOT get into the dev-only nitty gritty. if you want that, go read the Amanda source code and http://wiki.zmanda.com. iykyk 📚

and lemme define the vocab real quick because it gets confusing:

  • a "device driver" is the software that can talk to some kind of backend storage, e.g. a tape driver.
  • a "device" is the storage element itself, usually a piece of hardware.
  • and when we're talking about a device and its driver as one single unit? we also just call that a "device". confusing, i know, but that's the vibe. 💀

SPECIFYING DEVICES

device names are shaped like TYPE:NODE — where TYPE picks the device driver, and NODE hands extra info over to that driver. every driver's exact syntax is spelled out in its own section further down ⬇️

you can describe devices in amanda.conf(5) using "device" sections, like this:

define device top_drive {
    tapedev "tape:/dev/nst0"
    device-property "BLOCK_SIZE" "131072"
}

so that device definition makes a device "alias" — in this case named top_drive — which you can then name in the global tapedev or tpchanger parameter, like:

tapedev "top_drive"

the global tapedev parameter can also just take a literal device name, no alias needed. for example,

tapedev "file:/amdisks"

is equivalent to

tapedev "default"
define device default {
    tapedev "file:/amdisks"
}
💡 note that in both of those cases, the specified devices are actually accessed through the chg-single changer driver — go peek at amanda-changers(7) for the tea.

device properties that you specify outside of any device definition apply to all devices. this syntax is mostly there for backward compatibility and for simple Amanda configurations. and note: there's genuinely no way to provide properties specific to a device without defining a device alias. 😭

for the details on how devices are configured — and especially on how device properties are specified — see amanda-changers(7). for more on Amanda configuration in general, see amanda.conf(5).

⚠️ Note: there is genuinely no way to reset a device property back to its default value. once it's set, it's set. periodt.

PROPERTIES

device drivers use properties as the generic way to interact with the rest of Amanda. some properties get set by the device driver and used by Amanda to figure out how its devices should be used. other properties can be set by Amanda or by you to influence how the driver behaves. and properties are set per-device, so if you've got two tape devices, they will NOT be sharing property values. 💅

properties go in amanda.conf with the device-property parameter. the syntax looks like this:

device-property "FROBNICATOR_PATH" "/var/frobd/state"
device-property "BYTES_PER_FORTNIGHT" "128k"
device-property "USE_QUBITS" "no"

both the property name and the property value are always quoted. property names, just like Amanda configuration parameters, are not case-sensitive, and - (dash) and _ (underscore) can be used interchangeably. string values are given as simple strings, like FROBNICATOR_PATH in the example above. integer values can use any of the suffixes from the "VALUE SUFFIXES" section of amanda.conf(5), like BYTES_PER_FORTNIGHT up there. boolean values use the same names as in amanda.conf(5), like USE_QUBITS. and some properties have their own special formats, described below. ✨

some properties get set based on other configuration values, like tapetype parameters. those special cases are detailed under each relevant property below.

here's the order in which device properties are set:

  1. Tapetype parameters (including length, blocksize, and readblocksize) are translated into device properties and set accordingly.
  2. Device properties from any device-property configuration parameters are set, in the order they appear in the configuration file.

and properties described as read-only are not accessible to users — they're just listed here for completeness. 🙈

COMMON PROPERTIES

quick note before we dive in: some of these properties are currently unused and are only hanging around for future expansion. also not every device implements all of them, ok? ok.

  • APPENDABLE — (read-only) a boolean property that tells you whether this device supports appending data to volumes. 📎
  • BLOCK_SIZE — (read-write) the block size, in bytes, that will be used to write to the device. the usual suffixes ("kbytes", etc.) are allowed. the tapetype parameter blocksize sets this property.
  • CANONICAL_NAME — (read-only) the full canonical name for this device. this might not be the same as the user-supplied name, but it is a valid name by which to access this device. 🏷️
  • COMMENT — (read-write) a string property that is entirely for your convenience. every device supports it, but no device interprets its value in any way whatsoever. it's just vibes.
  • COMPRESSION — (read-write) a boolean representing the compression status of the device, and it can be used to enable and disable that compression. this applies mostly to tape devices, although bestie, many tape devices do not support setting compression from software. 💀
  • COMPRESSION_RATE — (read-only) the compression rate, as a decimal ratio. it may be a measured value over some unspecified period, or just a simple estimate. no cap.
  • CONCURRENCY — (read-only) indicates the level of concurrent access that this device supports.
  • FULL_DELETION — (read-only) indicates whether the device supports erasing the entire volume. aside from S3 and VFS, most devices cannot support this feature. 🌸
  • LEOM — (read-write) if this property is true, then the device can detect an EOM condition before actually running out of space, which lets Amanda forgo caching parts while writing. for some devices, you'll need to override the conservative default value of this property. 👑
  • MAX_BLOCK_SIZE — (read-only) the maximum block size this device can support. see BLOCK SIZES, below.
  • MEDIUM_ACCESS_TYPE — (read-only) the type of the media in the device: read only, WORM (Write Once, Read Many), read/write, or write only. write-only devices do not support recovery, but the data are not necessarily thrown out. (yes, that's the tea.)
  • MIN_BLOCK_SIZE — (read-write) the minimum block size this device can support. see BLOCK SIZES, below.
  • MAX_VOLUME_USAGE — (read-write) on devices that support it, this property limits the total amount of data written to a volume; attempts to write beyond this point will cause the device to simulate "out of space." zero means no limit. the tapetype parameter length sets this property.
  • ENFORCE_MAX_VOLUME_USAGE — (read-write) if this property is false, the limit set by the MAX_VOLUME_USAGE property (and thus the tapetype LENGTH parameter) will not be verified while writing to the device, letting the volume expand without limit. if this property is true, then MAX_VOLUME_USAGE will be enforced, limiting the total size of the volume. this property is not available on all devices; see below.
  • PARTIAL_DELETION — (read-only) indicates whether the device supports deletion of specific files. aside from linear tapes and S3, most devices can support this feature. it's currently unused by Amanda. 🙈
  • STREAMING — (read-only) the streaming requirement for this device. for example, tape drives often need a steady supply of data to avoid shoe-shining, while disk devices have no such requirement. streaming is accomplished by buffering device-output-buffer-size bytes of data. the allowed values are:
    • "none" — no streaming buffer necessary
    • "required" — fill the buffer before starting to write
    • "desired" — fill the buffer before starting to write, and if the buffer becomes empty, stop writing until it is completely full again
  • VERBOSE — (read-write) if this boolean property is set, then the device will produce verbose debugging output. most devices do not recognize this property. 📢

BLOCK SIZES

Amanda writes device data in blocks. on most devices the block boundaries are embedded in the media along with the data itself, so any subsequent reads have to use the same block sizes. on tape devices, the block size is dictated by what the hardware can do — buffer sizes, physical format, and so on.

historically Amanda supported a single, fixed block size — usually 32k. but the Device API adds the ability to specify a block size at runtime, using the BLOCK_SIZE property. devices provide MIN_BLOCK_SIZE and MAX_BLOCK_SIZE as a guide to the range of acceptable block sizes. and note that this does not mean every size in the range MIN_BLOCK_SIZE - MAX_BLOCK_SIZE is available — the device may require that block sizes be even multiples of some power of two, for example. consult the documentation for your hardware and operating system for more info. 🧚

most devices are flexible enough to read a volume using a different block size than the one it was written with. that's super useful when you're handling old volumes written with a smaller blocksize, or volumes of unknown blocksize. but unfortunately 😭 some tape devices don't detect oversized blocks correctly, and may lose data if the configured block size is smaller than the volume's block size. the tape device driver has a READ_BLOCK_SIZE property which specifies the minimum buffer size that will be allocated for reads from tape. if the hardware supports it, setting this property lets Amanda correctly read from tapes written with any blocksize less than or equal to READ_BLOCK_SIZE.

⚠️ Note: the RAIT device does not support flexible block sizes, because its parity algorithm requires that all child devices have the same, fixed block size. no exceptions, bestie. 💀

LEOM DETECTION

some Amanda devices can detect end-of-medium (i.e. running out of space on the device) before it actually happens. this early warning is called logical EOM, and where it's supported, Amanda can operate more efficiently since the possibility for data loss is reduced. ✨

the boolean LEOM property tells you whether or not a particular device supports LEOM detection. the sections below also describe the degree of support. 👀

💾 DEVICES 💾

okay bestie, this section is the guest list — every device driver that ships with Amanda, plus the basic tea on how to actually use them. For the full How-To (the deep lore), go check the Amanda wiki at http://wiki.zmanda.com. ✨

🕳️ Null Device 🕳️

tapedev "null:"

the null device driver only writes and literally throws every single byte in the trash. it's giving void, it's giving nothingness. it's generally only useful for testing purposes — like, do not trust it with your actual backups, babes. 💀

🌈 RAIT Device 🌈

tapedev "rait:tape:/dev/rmt/tps0d{4,5,6}n"

the RAIT device driver mirrors or stripes your data over multiple "child" devices. the child devices get specified with a shell-like syntax, where the alternatives sit inside braces and are separated by commas. braces and commas can be escaped with a backslash — and heads up, the backslash itself has to be escaped in most contexts. for example:

tapedev "rait:{file:/var/amanda/vtapes,tape:/dev/nst0}"
tapedev "rait:{comma-dev:foo\\,bar,brace-dev:foo\\}bar}" # quoting

if the braces contain a numeric range separated with two dots, that range gets filled in sequentially. if the first number has a leading zero, then the results will be zero-padded to the maximum length. example time:

tapedev "rait:file:/var/amanda/vtapes/drive{01..04}"

with two child devices, the RAIT device driver mirrors the data so the two devices contain identical data and either one can be used singly for recovery. with more than two devices, the RAIT device "stripes" data across all but one device and writes a parity block to the final device, which is usable for data recovery in the event of a device or volume failure. the RAIT device scales its blocksize as necessary to match the number of children that will be used to store data. it's giving RAID but make it Amanda. 💅

when a child device is known to have failed, you should reconfigure the RAIT device to replace that device with the text "ERROR", like:

tapedev "rait:{tape:/dev/st0,ERROR,tape:/dev/st2}"

this will cause the RAIT device to start up in degraded mode, reconstructing the data from the missing device. slay.

like ordinary RAID drivers, the RAIT device driver can automatically enter degraded mode when one of its child devices fails. but — and this is the big but — the RAIT device cannot automatically recover from any write error, nor write any data in degraded mode. when reading, certain errors may be fatal (rather than causing degraded mode). and in any case, labels on all volumes must initially match (labeled or otherwise). if you have lost one volume from a set, explicitly start the device in degraded mode as described above. no cap, do it explicitly or suffer. 😭

this device can detect LEOM if and only if all of the child devices can detect LEOM.

🧮 Child Device Block Sizes 🧮

the RAIT device driver requires that all of its child devices use the same block size. if no block sizes are specified, the driver selects the block size closest to 32k that is within the MIN_BLOCK_SIZE - MAX_BLOCK_SIZE range of all child devices, and calculates its own blocksize according to the formula:

rait_blocksize = child_blocksize * (num_children - 1)

if a block size is specified for the RAIT device, then it calculates its child block sizes according to the formula:

child_blocksize = rait_blocksize / (num_children - 1)

either way, it sets the BLOCK_SIZE property of each child device accordingly. math queen behavior, honestly. 🎀

☁️ S3 Device ☁️

tapedev "s3:foocorp-backups/DailySet1-"
device-property "S3_ACCESS_KEY" "MYACCESSKEY"
device-property "S3_SECRET_KEY" "MYSECRETKEY"

the S3 device driver uploads data to the Amazon S3 "storage cloud" ☁️✨. its device name is a slash-separated combination of bucket name and prefix: "s3:BUCKET/PREFIX". since buckets must be unique across all Amazon S3 users, and since the number of buckets allowed to each user is limited, the driver can store multiple Amanda volumes in a single S3 bucket, distinguished by prefix. the prefix and slash can be omitted if they are not needed: "s3:BUCKET".

the access and secret keys used to authenticate to Amazon S3 are provided as properties. 🔑

the S3 device driver stores each block in a distinct S3 object. because there's high HTTP overhead for each request, using larger than normal block sizes (> 1 megabyte) is recommended with the S3 device.

Amanda automatically creates a bucket when writing, if the bucket doesn't already exist. at that time, it specifies where Amazon should store the data based on the S3_BUCKET_LOCATION property. if this property is not set, Amazon's default value (equivalent to "*") is used. the bucket location has both billing and legal concerns, so you are encouraged to consult Amazon's documentation for details. bestie, read the fine print. 🙈

Amazon does not permit changes to bucket locations, so this is a permanent specification. if the bucket already exists and the property is set, then Amanda checks the property against the location of the bucket, and produces an error if they do not match.

Note 📝 if a location constraint is set, the bucket name must consist only of lower-case letters, numbers, dashes, and dots.

this driver supports the VERBOSE property, but use it carefully — it produces a great deal of output, and may cause spurious failures by filling your debug log partition. 💀 its logging is generally only useful for developers chasing down a problem in communications with Amazon's servers.

since Amazon storage is unlimited, the device never encounteres EOM, so LEOM detection is trivially enabled for this device. (yes, "encounteres" — that's a typo that lives in the original, and I'm keeping it fr fr.)

this driver supports the ENFORCE_MAX_VOLUME_USAGE property. default value is false. see COMMON_PROPERTIES, above.

🔧 Device-Specific Properties 🔧

in addition to the common properties, the S3 device supports the properties listed in this section.

most Amanda devices work just fine without any properties, but not the S3 device. a typical S3 configuration will have an access key and secret key specified:

device-property "S3_ACCESS_KEY" "27D3B8C6C4E7AA423C2B37C72A0D22C8"
device-property "S3_SECRET_KEY" "agphc2Q7Zmxragphc2RmO2xragpzZGY7a2xqCgr"

CHUNKED

(read-write) default: No. set to yes if the server support chunked transfer-encoding. Amazon do not support it, google support it.

CLIENT_ID

(read-write) the client_id for oauth2.

CLIENT_SECRET

(read-write) the client_secret for oauth2.

CREATE-BUCKET

(read-write) default: yes. if amanda create/delete the bucket.

REFRESH_TOKEN

(read-write) the refresh-token for oauth2.

MAX_RECV_SPEED

(read-write) maximum speed, in bytes per second, that this device will receive data from S3. if the average speed exceeds this value, the device will stop reading long enough to bring the average below this value. minimum value is 5120.

MAX_SEND_SPEED

(read-write) maximum speed, in bytes per second, that this device will send data to S3. if the average speed exceeds this value, the device will stop writing long enough to bring the average below this value. minimum value is 5120.

NB_THREADS_BACKUP

(read-write) the number of thread that send data to the s3 device, higher value can provide more throutput. 🔥

NB_THREADS_RECOVERY

(read-write) the number of thread that read data from the s3 device, higher value can provide more throutput. 🔥

OPENSTACK_SWIFT_API

(read-write) deprecated, set "STORAGE_API to "SWIFT-1.0". (that stray quote is the original's, not mine 💅)

PROXY

(read-write) the proxy hostname or IP in the format "host[:port]".

PASSWORD

(read-write) the password (for swift v2 and v3).

PROJECT-ID

(read-write) the projectid (for google).

READ-FROM-GLACIER

(read-write) default: NO. set it to "YES" if some files are transitioned to glacier. 🧊

REUSE-CONNECTION

(read-write) default: YES. set it to "NO" if reusing a connection cause some bug, this is sometime the case with big block size.

S3_ACCESS_KEY

(read-write) this property gives the Amazon S3 access key used to access the service.

S3_SESSION_TOKEN

(read-write) this property gives the Amazon S3 session token used to access the service.

S3_BUCKET_LOCATION

(read-write) location constraint for buckets on Amazon S3. as of this writing, it can be set to "*" (US Standard, i.e. lowest-latency choice of US East or West), "us-west-1" (US West, Northern California), "EU" (European Union), or "ap-southeast-1" (Asia Pacific). see: http://docs.amazonwebservices.com/general/latest/gr/index.html?rande.html for the most up-to-date list.

S3_MULTI_DELETE

(read-write) if the server support the multi delete protocol (only Amazon S3), default is "YES" for "S3" and "AWS4" STORAGE_API, default in "NO" for all others STORAGE_API.

S3_MULTI_PART_UPLOAD

(read-write) if the server support the multi part upload api (only Amazon S3), default is "NO". use less s3 objects.

SSL_CA_INFO

(read-write) path to CA certificate to use to verify the identity of the S3 server. only applicable when SSL/TLS is in use. the certificate should be in PEM format if OpenSSL or GnuTLS is being used with libcurl. multiple certificates can be bundled together simply by concatenating them. if NSS is being used, then it is the directory that the database resides in. the value is passed to curl_easy_setopt(3) as CURLOPT_CAINFO.

S3_HOST

(read-write) the host name to connect, in the form "hostname:port" or "ip:port", default is "s3.amazonaws.com".

S3_SECRET_KEY

(read-write) this property gives the Amazon S3 secret key used to access the service.

S3_SERVER_SIDE_ENCRYPTION

(read-write) set to the server side encryption algorithm to use. there is actually only one algorithm, it is "AES256". the encryption is done by Amazon on their server. see: http://docs.amazonwebservices.com/AmazonS3/latest/API/index.html?RESTObjectPUT.html for the most up-to-date list.

S3_SERVICE_PATH

(read-write) a path to add at the beginning of the URL.

S3_STORAGE_CLASS

(read-write) storage class for new objects.

  • S3 compatible
    • STANDARD
    • STANDARD_IA
    • REDUCED_REDUNDANCY
  • Google storage
    • STANDARD
    • DURABLE_REDUCED_AVAILABILITY
    • NEARLINE

S3_SSL

(read-write) whether or not to use SSL/TLS to secure communications with Amazon S3.

S3_SUBDOMAIN

(read-write) whether or not to use subdomain hostname.

S3_USER_TOKEN

(read-write) this property specifies the user token for Amanda Enterprise Edition customers.

STORAGE_API

  • S3 — Amazon S3 AWS Signature Version 2
  • AWS4 — Amazon S3 AWS Signature Version 4
  • SWIFT-1.0 — Openstack swift v1.0
  • SWIFT-2.0 — Openstack swift v2.0
  • SWIFT-3 — Openstack swift keystone v3
  • OAUTH2 — Google
  • CASTOR — Caringo CAStor

When you don't say anything, the vibe check lands on AWS4 if S3-HOST ends with .amazonaws.com — otherwise it's S3. That's the whole rule, bestie, no cap.

TENANT_ID 💜

(read-write) The tenant id (for swift v2).

TENANT_NAME 💜

(read-write) The tenant name (for swift v2).

PROJECT_NAME 💜

(read-write) Default: $USERNAME. The project name (for swift v3). Slay.

DOMAIN_NAME 💜

(read-write) Default: "Default". The domain name (for swift v3).

TIMEOUT 💜

(read-write) Slap a timeout on every single transfer to the cloud. Default is 0, and 0 literally means no timeout at all — it will simply wait forever, main character energy.

TRANSITION-TO-GLACIER 💜

(read-write) Default: -1. Set it to anything greater than or equal to zero and your volume gets transitioned to glacier that many days after it's set to no-reuse. Frosty. 🧊

USERNAME 💜

(read-write) The username (for swift v2 and v3).

VERBOSE 💜

(read-write) If true, verbose data about every single HTTP transaction gets dumped into the debug log. It's giving detective mode. 🔍

🌐 S3 URL 🌐

Here's the shape of the URL depending on whether you've got SSL and SUBDOMAIN turned on:

 SSL &&  SUBDOMAIN:   https://bucket.host/service_path/file
 SSL && !SUBDOMAIN:   https://host/service_path/bucket/file
!SSL &&  SUBDOMAIN:   http://bucket.host/service_path/file
!SSL && !SUBDOMAIN:   http://host/service_path/bucket/file

📼 Tape Device 📼

tapedev "tape:/dev/nst0"

Okay so this driver talks directly to a tape drive. It leans on your operating system's built-in tape support, which is basically the same energy as what you get from the command-line utilities dd(1) and mt(1). Iconic little duo.

The tape device name should be a path to the operating system's device file.

Now, there is no simple way to figure out whether a specific system (that's your OS and your tape hardware together) supports LEOM. So as a safe default, the tape device has LEOM detection disabled. Big sad. But on modern hardware and the common operating systems (Linux, *BSD, and Solaris, at minimum), LEOM support actually works fine. On those systems, turn LEOM on by setting the LEOM property to "true" in the right spot in your Amanda configuration. Do it. 💅

🎀 Device-Specific Properties 🎀

Most of these get detected automatically, but you can override them in the config file if the autodetection fumbles it. Lowkey important: tape drives are required to at least support the MTREW (rewind) operation. Every other operation can be emulated using MTREW and plain old read data operations. So if that's all your drive's got, you're still fine.

  • BROKEN_GMT_ONLINE — (read-write) Set this boolean property if your system's GMT_ONLINE macro returns incorrect results. Right now this is true for the Linux IDE-TAPE driver. Yeah, it's like that. 🙈
  • BSF — (read-write) This boolean property says whether the device driver is allowed to execute the MTBSF operation (backward seek file).
  • BSF_AFTER_EOM — (read-write) This boolean property says whether the device driver should execute an MTBSF (backward seek file) operation after MTEOM (seek to end of recorded data) in order to append.
  • BSR — (read-write) This boolean property says whether the device driver may use the MTBSR operation (backward seek record).
  • EOM — (read-write) This boolean property says whether the device driver may use the MTEOM command (seek to end of recorded data).
  • FINAL_FILEMARKS — (read-write) This integer property gives the number of filemarks that should be written at EOD. It's usually 1 or 2.
  • FSF — (read-write) This boolean property says whether the device driver may use the MTFSF operation (forward seek file).
  • FSF_AFTER_FILEMARK — (read-write) This boolean property says whether the device driver needs a FSF to get to the next file after the filemark is read. Defaults to "TRUE" on Solaris and "FALSE" on all other machines.
  • FSR — (read-write) This boolean property says whether the device driver may use the MTFSR operation (forward seek record).
  • NONBLOCKING_OPEN — (read-write) Set this boolean property to "true" if O_NONBLOCK must be used on the open call. Defaults to "true" on Linux and "false" on all other machines. Without it, Linux just sits there waiting for a few seconds if no tape is loaded — awkward. 💀 Solaris throws a weird error when it's set to "yes".
  • READ_BLOCK_SIZE — (read-write) This property (it used to be called READ_BUFFER_SIZE) sets the block size used for reads. It should be big enough to contain any block that might be read from the device (like, say, from a tape holding variable-sized blocks), and it must be larger than BLOCK_SIZE. This one is most often used when you're overwriting tapes with a new, smaller block size. The tapetype parameter READBLOCKSIZE sets this property. Peep BLOCK SIZES, above.

🛰️ NDMP Device 🛰️

tapedev "ndmp:my.filer.com:10000@st1"
device-property "NDMP_USERNAME" "jimmy"
device-property "NDMP_PASSWORD" "thelock"

This device lets Amanda chat with a tape service living on an NDMP server. The device name gives the hostname and optionally the TCP port of the NDMP server, and then — after the @ — the name of the tape device on the server (st1 up there in the example).

This device does support LEOM detection. Look at her go. ✨

🎀 Device-Specific Properties 🎀

The properties NDMP_USERNAME and NDMP_PASSWORD set the username and password used to access the NDMP server. Default for both is "ndmp".

  • INDIRECT — (read-write) The default is "yes". You can set it to "no" if the ndmp server can be configured with a window length of 0.
  • NDMP_AUTH — (read-write) The authentication method used to connect to the NDMP server. Pick one of "md5" (the default), "text", "none" (for an empty authentication attempt) or "void" (for no authentication attempt at all).
  • NDMP_PASSWORD — (read-write) Password for md5 or text authentication.
  • NDMP_USERNAME — (read-write) Username for md5 or text authentication.
  • READ_BLOCK_SIZE — (read-write) This property sets the block size that'll be used for reads. It needs to be big enough to contain any block that might be read from the device, and it must be larger than BLOCK_SIZE. See BLOCK_SIZES, above.

🗂️ VFS Device 🗂️

tapedev "file:/path/to/vtape"

The VFS device driver stores your data on a UNIX filesystem. And yeah, normally you'd use it to store stuff on hard disks, but heads up — the driver does not interface with any hardware at a block level. It's not about the hardware, it's about the vibes. 💅

The device name is a path to a directory that must exist and must contain a "data/" subdirectory. Every tape file is stored as its own distinct file in this directory, and the name reflects the Amanda header inside the tape file. Block boundaries are not maintained: the driver happily supports reads of arbitrary size, no matter what blocksize was used to write the data. Flexible queen behavior.

This device supports LEOM detection. LEOM gets flagged when MAX_VOLUME_USAGE is nearly met, or when the filesystem is nearly out of space. That second one is detected by monitoring the available space on the filesystem — and you can turn that monitoring off with the MONITOR_FREE_SPACE property. Just know the device cannot detect other things that might make a write fail, like a filesystem quota. So watch out. 😭 You can disable LEOM detection entirely by setting the LEOM property to false.

This device also supports the ENFORCE_MAX_VOLUME_USAGE property. Default value is true. See COMMON PROPERTIES, above.

🎀 Device-Specific Properties 🎀

  • MONITOR_FREE_SPACE — (read-write) This property controls whether the device watches the filesystem's free space so it can catch a full filesystem before an error happens. Defaults to true. The monitoring works on most filesystems, but if it's causing you problems, use this property to shut it off.
  • USE_DATA — (read-write) (Default: "EXIST") This one controls whether the device uses the 'data' subdirectory. A value of "NO" never uses it. A value of "YES" always uses it. A value of "EXIST" uses it only if it exists. Situationally aware, honestly.

💽 DISKFLAT Device 💽

tapedev "diskflat:/path/to/diskflat/label-001"

Each slot is a single file named after the slot label. Simple. Clean. No notes. ✨

The MAX-DLE-BY-VOLUME setting must be set to 1.

This one must be used with the diskflat changer:

tpchanger "chg-diskflat:diskflat:/path/to/diskflat/label-{001..010}"
autolabel "label-$5s" empty volume-error
labelstr MATCH-AUTOLABEL
max-dle-by-volume 1

🎀 Device-Specific Properties 🎀

It has the exact same properties as the VFS device, with one little difference:

  • USE_DATA — Unused. Yeah, she's just sitting there. Ignore her. 🙈

📀 DVD-RW Device 📀

tapedev "dvdrw:/var/cache/amanda/dvd-cache:/dev/scd0"
device-property "DVDRW_MOUNT_POINT" "/media/dvd"
device-property "DVDRW_KEEP_CACHE" "false"
device-property "DVDRW_UNLABELLED_WHEN_UNMOUNTABLE" "true"

The DVD-RW device driver reads and writes optical media — think DVDs and CDs. Y2K aesthetic, love that for us. 🎀 The device name must give a cache directory where data gets temporarily stored, followed by the operating system's name for the optical drive. The cache directory must contain a "data/" subdirectory.

The DVDRW_MOUNT_POINT property is required, and it names a directory where the optical media can be mounted. This directory must be configured so non-root users can mount the optical media. On Linux, that means a line like this in /etc/fstab:

/dev/scd0 /media/dvd auto ro,user,noauto 0 0

Mind the "user" option. That's the whole point, bestie — don't skip it.

When it's writing data, the device acts like a VFS device using the given cache directory. Once writing the tape finishes, the cache directory gets written to optical media. The DVDRW_KEEP_CACHE property controls whether the cache contents are immediately deleted afterwards. When reading, the optical media gets mounted first and then read as a VFS device. Bless.

Trying to mount unformatted media — or media that is formatted but contains no filesystem — will usually throw an error. The boolean DVDRW_UNLABELLED_WHEN_UNMOUNTABLE property says whether media that can't be mounted should be treated as an empty, unlabelled volume when it's trying to read the volume label. You have to set this property to "true" when labelling such media. Non-negotiable.

🚨 This device does not support LEOM detection. No LEOM for you, sorry bestie. (Read: this device does not support LEOM detection.)

🎀 Device-Specific Properties 🎀

The properties DVDRW_GROWISOFS_COMMAND, DVDRW_MOUNT_COMMAND and DVDRW_UMOUNT_COMMAND let you point at alternative commands for writing, mounting and unmounting optical media. By default it just finds the programs using the PATH environment variable. She's resourceful like that.

The CDRW device supports all of the properties of the VFS device, plus the properties given below. The DVDRW_MOUNT_POINT property is required. The other properties are optional.

  • DVDRW_KEEP_CACHE — (read-write) okay so this one is a boolean, bestie 💖 set it to true if you want the disk cache directory to be kept after tape data gets successfully written to optical media. The default is false, which means the cache contents get yeeted immediately after a successful write operation. so like, if you're a keep-your-receipts kinda girl, flip it. if you're a delete-the-evidence icon, leave it alone. ✨
  • DVDRW_MOUNT_POINT — (read-write) this property specifies the filesystem mount point for the optical media 🎀 non-root users must be able to mount optical media by invoking mount and specifying this mount point. so yeah, permission vibes matter here, no cap.
  • DVDRW_UNLABELLED_WHEN_UNMOUNTABLE — (read-write) treat unmountable media as empty, unlabelled media 🫶 this is necessary when attempting to label freshly formatted media. it's giving "don't know her yet, but we're about to name her" energy. 💅
  • DVDRW_GROWISOFS_COMMAND — (read-write) the command to invoke to burn the DVD 🔥
  • DVDRW_MOUNT_COMMAND — (read-write) the command to invoke to mount the DVD 🌸
  • DVDRW_UMOUNT_COMMAND — (read-write) the command to invoke to unmount the DVD 🦋

✨ SEE ALSO ✨

The Amanda Wiki: : http://wiki.zmanda.com/ 👑

👑 AUTHORS 👑

and that's the whole page, bestie 💖 this was Amanda 3.5.4, dated 08/26/2026, and it lives at AMANDA-DEVICES(7) — periodt. go forth and configure your devices with main character energy, you absolutely ate. 🎀✨

📦 where this page comes from