Provided by: amanda-common_3.3.0-1ubuntu1_amd64 bug

NAME

       amvault - Copy Amanda dumps from one volume to another

SYNOPSIS

       amvault [-o configoption...] [-q] [--quiet] [-n] [--dry-run] [--fulls-only] [--export]
               [--src-timestamp src-timestamp]
               --label-template label-template --dst-changer dst-changer
               [--autolabel autolabel-arg...]
               config [hostname [ disk [ date [ level [ hostname [...] ] ] ] ]]

WARNING

       This application is not yet in its final form, and is subject to major revision in
       subsequent versions of Amanda. Backward compatibility is not guaranteed.

       Note that Amanda restore/recover operations will request tertiary media by label when
       dumpfiles are not found on secondary media, but there is no provision to automatically
       fetch such media from a different changer

       Feedback on and patches to this application are invited and encouraged!

DESCRIPTION

       Amvault is conceptually equivalent to "amfetchdump | taper". That is, it reads specified
       dumps from secondary media and re-writes them on tertiary media.

       Amvault Copies data from the run with timestamp src-timestamp onto volumes using the
       changer dst-changer, and labeling new volumes with label-template. If src-timestamp is
       "latest", then the most recent amdump or amflush run will be used. If --fulls-only is
       given, then only full (level-0) dumps are copied.

       The --quiet (-q) option will eliminate non-error messages, and is useful when running
       amvault from cron. The --dry-run (-n) option will cause amvault to print the dumps it
       would vault, but not actually perform any vaulting operations.

   Secondary Media
       The dumps to be read from secondary media can be specified by any combination of dump
       specifications, --fulls-only, and --src-timestamp. At least one must be specified, lest
       amvault attempt to vault all dumps in the catalog. See amanda-match(7) for more
       information on dump specifications.

       Note that the datestamp given in the dumpspec is the dump datestamp - the run in which the
       backup was taken on the Amanda client. The --src-timestamp, on the other hand, is the
       write timestamp - the run in which the dump was written to secondary media. The latter
       option facilitates duplicating the results of an entire backup run, including any dumps
       that might have been flushed from holding disk.

   Tertiary Media
       The --dst-changer must be specified, and names the changer in which tertiary media are
       stored. In general, this should be different from the secondary changer, to eliminate the
       possibility of overwriting secondary media with tertiary data.

       The changer parameter should specify the name of a changer defined in amanda.conf(5). For
       example:

       define changer vaulting_tape {
           tapedev "/dev/rmt/1n"
           tpchanger "chg-zd-mtx"
           changerdev "/dev/sg0"
           changerfile "vaulting-changer.conf"
       }

       The --label-template option is required, and specifies a label template which is used to
       generate new labels for tertiary volumes. The --autolabel option works just like the
       autolabel parameter in amanda.conf(5), and can be specified multiple times if necessary.
       The default is ┬┤empty┬┤.

       If amanda.conf(5) contains the new part-size splitting parameters, then amvault will use
       them without any additional configuration. However, if the configuration still uses the
       old splitting parameters (tape_splitsize, split_diskbuffer, and fallback_splitsize), then
       amvault will need some additional configuration in order to properly split dumps to
       tertiary media. To do so, specify a new tapetype in amanda.conf(5), say "TERTIARY", and
       set the part-size and other appropriate parameters there. Then reference that tapetype in
       the amvault invocation:

           amvault -otapetype=TERTIARY ...

       The --export option will cause amvault to attempt to move completed tertiary volumes to
       import/export slots, where they can be more easily removed by an operator.

SEE ALSO

       amanda(8), amanda-changers(7), amfetchdump(8)

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

AUTHOR

       Dustin J. Mitchell <dustin@zmanda.com>
           Zmanda, Inc. (http://www.zmanda.com)