+In addition to options, another
+\fBinterface\fR
+name may be supplied as an identifier, which makes this
+\fBinterface\fR
+inherit options from another
+\fBinterface\fR\&. At the moment, this is of little use\&.
+.SH "APPLICATION SECTION"
+.PP
+The
+\fBamanda\&.conf\fR
+file may define multiple types of application\&. The information is entered in a
+\fBapplication\fR
+section, which looks like this:
+.nf
+define application "\fIname\fR" {
+ \fIapplication\-option\fR \fIapplication\-value\fR
+ \&.\&.\&.
+}
+.fi
+.PP
+The { must appear at the end of a line, and the } on its own line\&.
+.PP
+\fIname\fR
+is the name of this type of application\&. It is referenced from the
+\fIdumptype\fR
+.PP
+The application options and values are:
+.PP
+\fBcomment\fR \fIstring\fR
+.RS 4
+Default: not set\&. A comment string describing this application\&.
+.RE
+.PP
+\fBplugin\fR \fIstring\fR
+.RS 4
+No default\&. Must be set to the name of the program\&. This program must be in the
+\fI$libexecdir/amanda/application\fR
+directory on the client\&.
+.RE
+.PP
+\fBproperty\fR [\fBappend\fR] [\fBpriority\fR] \fIstring\fR \fIstring\fR+
+.RS 4
+No default\&. You can set property for the application, each application have a different set of property\&. Both strings are quoted; the first string contains the name of the property to set, and the others contains its values\&.
+\fBappend\fR
+keyword append the values to the list of values for that property\&.
+\fBpriority\fR
+keyword disallow the setting of that property on the client\&.
+.RE
+.SH "SCRIPT SECTION"
+.PP
+The
+\fBamanda\&.conf\fR
+file may define multiple types of script\&. The information is entered in a
+\fBscript\fR
+section, which looks like this:
+.nf
+define script "\fIname\fR" {
+ \fIscript\-option\fR \fIscript\-value\fR
+ \&.\&.\&.
+}
+.fi
+.PP
+The { must appear at the end of a line, and the } on its own line\&.
+.PP
+\fIname\fR
+is the name of this type of script\&. It is referenced from the
+\fIdumptype\fR
+.PP
+The script options and values are:
+.PP
+\fBcomment\fR \fIstring\fR
+.RS 4
+Default: not set\&. A comment string describing this script\&.
+.RE
+.PP
+\fBplugin\fR \fIstring\fR
+.RS 4
+No default\&. Must be set to the name of the program\&. This program must be in the
+\fI$libexecdir/amanda/application\fR
+directory on the client and/or server\&.
+.RE
+.PP
+\fBorder\fR \fIint\fR
+.RS 4
+Default:
+\fI5000\fR\&. Scripts are executed in that order, it is useful if you have many scripts and they must be executed in a spefific order\&.
+.RE
+.PP
+\fBexecute\-where\fR [ \fBclient\fR | \fBserver\fR ]
+.RS 4
+Default:
+\fBclient\fR\&. Where the script must be executed, on the client or server\&.
+.RE
+.PP
+\fBexecute\-on\fR \fIexecute_on\fR [,\fIexecute_on\fR]*
+.RS 4
+No default\&. When the script must be executed, you can specify many of them:
+.PP
+\fBpre\-dle\-amcheck\fR
+.RS 4
+Execute before the amcheck command for the dle\&.
+.RE
+.PP
+\fBpre\-host\-amcheck\fR
+.RS 4
+Execute before the amcheck command for all dle for the client\&.
+.RE
+.PP
+\fBpost\-dle\-amcheck\fR
+.RS 4
+Execute after the amcheck command for the dle\&.
+.RE
+.PP
+\fBpost\-host\-amcheck\fR
+.RS 4
+Execute after the amcheck command for all dle for the client\&.
+.RE
+.PP
+\fBpre\-dle\-estimate\fR
+.RS 4
+Execute before the estimate command for the dle\&.
+.RE
+.PP
+\fBpre\-host\-estimate\fR
+.RS 4
+Execute before the estimate command for all dle for the client\&.
+.RE
+.PP
+\fBpost\-dle\-estimate\fR
+.RS 4
+Execute after the estimate command for the dle\&.
+.RE
+.PP
+\fBpost\-host\-estimate\fR
+.RS 4
+Execute after the estimate command for all dle for the client\&.
+.RE
+.PP
+\fBpre\-dle\-backup\fR
+.RS 4
+Execute before the backup command for the dle\&.
+.RE
+.PP
+\fBpre\-host\-backup\fR
+.RS 4
+Execute before the backup command for all dle for the client\&. It can\'t be run on client, it must be run on server
+.RE
+.PP
+\fBpost\-dle\-backup\fR
+.RS 4
+Execute after the backup command for the dle\&.
+.RE
+.PP
+\fBpost\-host\-backup\fR
+.RS 4
+Execute after the backup command for all dle for the client\&. It can\'t be run on client, it must be run on server
+.RE
+.PP
+\fBpre\-recover\fR
+.RS 4
+Execute before any level is recovered\&.
+.RE
+.PP
+\fBpost\-recover\fR
+.RS 4
+Execute after all levels are recovered\&.
+.RE
+.PP
+\fBpre\-level\-recover\fR
+.RS 4
+Execute before each level recovery\&.
+.RE
+.PP
+\fBpost\-level\-recover\fR
+.RS 4
+Execute after each level recovery\&.
+.RE
+.PP
+\fBinter\-level\-recover\fR
+.RS 4
+Execute between two levels of recovery\&.
+.RE
+.sp
+If you recover level 0 and 2 of the disk /usr with amrecover, it will execute:
+.nf
+script \-\-pre\-recover
+script \-\-pre\-level\-recover \-\-level 0
+#recovering level 0
+script \-\-post\-level\-recover \-\-level 0
+script \-\-inter\-level\-recover \-\-level 0 \-\-level 2
+script \-\-pre\-level\-recover \-\-level 2
+#recovering level 2
+script \-\-post\-level\-recover \-\-level 2
+script \-\-post\-recover
+.fi
+.RE
+.PP
+\fBproperty\fR [\fBappend\fR] [\fBpriority\fR] \fIstring\fR \fIstring\fR+
+.RS 4
+No default\&. You can set property for the script, each script have a different set of property\&. Both strings are quoted; the first string contains the name of the property to set, and the others contains its values\&.
+\fBappend\fR
+keyword append the values to the list of values for that property\&.
+\fBpriority\fR
+keyword disallow the setting of that property on the client\&.
+.RE
+.SH "DEVICE SECTION"
+.PP
+Backend storage devices are specified in
+\fBamanda\&.conf\fR
+in the form of "device" sections, which look like this:
+.nf
+define device \fIname\fR {
+ commend "\fIcomment (optional)\fR"
+ tapedev "\fIdevice\-specifier\fR"
+ device\-property "\fIprop\-name\fR" "\fIprop\-value\fR"
+ \&.\&.\&.
+}
+.fi
+.PP
+The { must appear at the end of a line, and the } on its own line\&.
+.PP
+\fIname\fR
+is the user\-specified name of this device\&. It is referenced from the global
+\fItapedev\fR
+parameter\&. The
+\fIdevice\-specifier\fR
+specifies the device name to use; see
+\fBamanda-devices\fR(7)\&. As with most sections, the
+\fIcomment\fR
+parmeter is optional and only for the user\'s convenience\&.
+.PP
+An arbitrary number of
+\fIdevice\-property\fR
+parameters can be specified\&. Again, see
+\fBamanda-devices\fR(7)
+for information on device properties\&.
+.SH "CHANGER SECTION"
+.PP
+Changers are described in
+\fBamanda\&.conf\fR
+in the form of "changer" sections, which look like this:
+.nf
+define changer \fIname\fR {
+ comment "\fIcomment (optional)\fR"
+ tpchanger "\fIchanger\-spec\fR"
+ changerdev "\fIdevice\-name\fR"
+ changerfile "\fIstate\-file\fR"
+ \&.\&.\&.
+}
+.fi
+.PP
+The { must appear at the end of a line, and the } on its own line\&.
+.PP
+\fIname\fR
+is the user\-specified name of this device\&. The remaining parameters are specific to the changer type selected\&.
+.PP
+See
+\fBamanda-changers\fR(7)
+for more information on configuring changers\&.
+.SH "DUMP SPLITTING CONFIGURATION"
+.PP
+Amanda can "split" dumps into parts while writing them to storage media\&. This allows Amanda to recover gracefully from a failure while writing a part to a volume, by simply selecting a new volume and re\-writing the dump from the beginning of the failed part\&. Parts also allow Amanda to seek directly to the required data, although this functionality is not yet used\&.
+.PP
+In order to support re\-writing from the beginning of a failed part, Amanda must have access to the contents of the part after it has been partially written\&. If the dump is being read from holding disk, then the part contents are availble there\&. Otherwise, the part must be cached, and this can be done memory or on disk\&. In either of the latter cases, the cache must have enough space to hold an entire part\&.
+.PP
+Because it is common for a single Amanda configuration to use both holding\-disk (FILE\-WRITE) and direct (known as PORT\-WRITE) dumps, Amanda allows the configuration of different split sizes for the two cases\&. This allows, for example, for a part size appropriate to large tapes when performing FILE\-WRITE dumps, with a part size limited by available disk or memory when performing PORT\-WRITE dumps\&.
+.PP
+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\&.
+.PP
+In versions of Amanda through 3\&.1\&.*, splitting was controlled by the dumptype parameters
+\fBtape\-splitsize\fR,
+\fBsplit\-diskbuffer\fR, and
+\fBfallback\-splitsize\fR\&. These keywords had confusing and non\-intuitive interactions, and have since been deprecated\&.
+.PP
+If the deprecated keywords are not present, subsequent versions of Amanda use the dumptype parameter
+\fBallow\-split\fR
+to control whether a DLE can be split, and the
+\fItapetype\fR
+parameters
+\fBpart\-size\fR,
+\fBpart\-cache\-type\fR,
+\fBpart\-cache\-dir\fR, and
+\fBpart\-cache\-max\-size\fR\&. The
+\fBpart\-size\fR
+specifies the "normal" part size, while the
+\fBpart\-cache\-*\fR
+parameters describe how to behave when caching is required (on PORT\-WRITE)\&. Full details on these parameters are given above\&.