+
+<refsect1><title>DEVICE SECTION</title>
+<para>Backend storage devices are specified in
+<emphasis remap='B'>amanda.conf</emphasis>
+in the form of "device" sections, which look like this:</para>
+
+<programlisting>
+define device <emphasis remap='I'>name</emphasis> {
+ commend "<emphasis remap='I'>comment (optional)</emphasis>"
+ tapedev "<emphasis remap='I'>device-specifier</emphasis>"
+ device-property "<emphasis remap='I'>prop-name</emphasis>" "<emphasis remap='I'>prop-value</emphasis>"
+ <literal>...</literal>
+}
+</programlisting>
+
+<para>The { must appear at the end of a line, and the } on its own line.</para>
+<para><emphasis remap='I'>name</emphasis> is the user-specified name of
+this device. It is referenced from the global <emphasis
+remap='I'>tapedev</emphasis> parameter. The <emphasis
+remap='I'>device-specifier</emphasis> specifies the device name to use;
+see <manref name="amanda-devices" vol="7"/>.
+As with most sections, the <emphasis remap='I'>comment</emphasis>
+parmeter is optional and only for the user's convenience.</para>
+
+<para>An arbitrary number of <emphasis
+remap='I'>device-property</emphasis> parameters can be specified.
+Again, see
+<manref name="amanda-devices" vol="7"/>
+for information on device properties.</para>
+
+</refsect1>
+
+<refsect1><title>CHANGER SECTION</title>
+<para>Changers are described in
+<emphasis remap='B'>amanda.conf</emphasis>
+in the form of "changer" sections, which look like this:</para>
+
+<programlisting>
+define changer <emphasis remap='I'>name</emphasis> {
+ comment "<emphasis remap='I'>comment (optional)</emphasis>"
+ tpchanger "<emphasis remap='I'>changer-spec</emphasis>"
+ changerdev "<emphasis remap='I'>device-name</emphasis>"
+ changerfile "<emphasis remap='I'>state-file</emphasis>"
+ <literal>...</literal>
+}
+</programlisting>
+
+<para>The { must appear at the end of a line, and the } on its own line.</para>
+<para><emphasis remap='I'>name</emphasis> is the user-specified name of this
+device. The remaining parameters are specific to the changer type selected.
+</para>
+
+<para>See <manref name="amanda-changers" vol="7" /> for more information on configuring changers.</para>
+
+</refsect1>
+
+<refsect1><title>Dump Splitting Configuration</title>
+
+ <para>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.</para>
+
+ <para>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.</para>
+
+ <para>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.</para>
+
+ <para>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.</para>
+
+ <para>In versions of Amanda through 3.1.*, splitting was controlled by the
+ dumptype parameters <amkeyword>tape-splitsize</amkeyword>,
+ <amkeyword>split-diskbuffer</amkeyword>, and
+ <amkeyword>fallback-splitsize</amkeyword>. These keywords had
+ confusing and non-intuitive interactions, and have since been
+ deprecated.</para>
+
+ <para>If the deprecated keywords are not present, subsequent versions
+ of Amanda use the dumptype parameter
+ <amkeyword>allow-split</amkeyword> to control whether a DLE can be
+ split, and the <emphasis>tapetype</emphasis> parameters
+ <amkeyword>part-size</amkeyword>,
+ <amkeyword>part-cache-type</amkeyword>,
+ <amkeyword>part-cache-dir</amkeyword>, and
+ <amkeyword>part-cache-max-size</amkeyword>. The
+ <amkeyword>part-size</amkeyword> specifies the "normal" part size,
+ while the <amkeyword>part-cache-*</amkeyword> parameters describe
+ how to behave when caching is required (on PORT-WRITE). Full
+ details on these parameters are given above.</para>
+
+</refsect1>
+
+<seealso>
+<manref name="amanda-client.conf" vol="5"/>,
+<manref name="amanda-applications" vol="7"/>,
+<manref name="amanda-auth" vol="7"/>,
+<manref name="amanda-changers" vol="7"/>,
+<manref name="amanda-devices" vol="7"/>,
+<manref name="amanda-scripts" vol="7"/>
+</seealso>
+
+