UNIX System Administration Handbook - Evi Nemeth [122]
#########################################################
# Local parameters
##########################################################br/>
org "Podunk Univ." # your organization name for reports
mailto "amanda" # space-separated list of operators at your site
dumpuser "amanda" # the user to run dumps as
runtapes 1 # number of tapes to use in a single run of amdump
tpchanger "chg-manual" # tape changer glue script (provided with Amanda)
tapedev "/dev/rmt/0bn" # the no-rewind tape device to be used
labelstr "^Podunk-[0-9][0-9]*$" # label constraint regex: all tapes must match
infofile "/usr/adm/amanda/podunk/curinfo" # database directory
logdir "/usr/adm/amanda/podunk" # log directory
indexdir "/usr/adm/amanda/podunk/index" # index directory
Amanda reads the label from each piece of media and will not use a tape unless its label matches the regular expression specified in labelstr. Therefore, all tapes must be labeled by amlabel before they can be used to store backups. Labels cannot contain whitespace characters.
It is up to the system administrator to define a meaningful naming scheme. For example, you might want to have the * in the regex match as a hint to the compression used or the type of machine backed up. In the example above, tapes would have labels Podunk-01, Podunk-02, and so on.
If you try to reuse a tape before the normal rotation cycle has been completed, the server will reject it. This feature prevents you from accidentally overwriting a tape that is still of historical importance in the backup scheme you have defined.
The parameters of that scheme (how often a particular tape can be used, how often each filesystem should get a level 0 dump, when to increase the dump level, etc.) are defined in the second section of amanda.conf.
##########################################################
# Strategy parameters
##########################################################
dumpcycle 4 weeks # the number of days in the normal dump cycle
bumpdays 2 # minimum days at each level
bumpsize 20 Mb # minimum savings (threshold) to bump level 1 -> 2
bumpmult 2 # threshold = bumpsize * bumpmult^(level-1)
runspercycle 20 # the number of amdump runs in dumpcycle days
# 4 weeks * 5 amdump runs per week (weekdays)
tapecycle 25 tapes # the number of tapes in rotation
# 4 weeks (dumpcycle) * 5 tapes per week (weekdays)
# plus a few to handle errors that need amflush and
# so we do not overwrite the full backups performed
# at the beginning of the previous cycle
In the Amanda system, dumps are not rigidly scheduled by calendar date. Instead, you give Amanda general information about how much redundancy you want it to maintain. Amanda then tries to spread the work out across the entire dump cycle so that tapes are used efficiently and protection is maximized. Amanda recalculates its daily schedule each night, using real-time information about each client filesystem. It’s really not possible to predict the exact dump agenda in advance.
A “dump cycle” is a period in which level 0 dumps will be done at least once on every client filesystem. Long cycles increase Amanda’s scheduling flexibility, but they may also increase the average number of tapes that must be read to complete a restore. Amanda might perform level 0 dumps more frequently than the cycle time requires if tape is available.
The Amanda model assumes that dumps will be done every day. If this isn’t true, you should set the runspercycle parameter to the actual number of dump days in a cycle. This example configuration does dumps only on weekdays, which is reasonable if someone must be physically present to change tapes.
Another assumption that’s made by default is that one dump tape will be written per day (or per “run,” in Amanda terminology). If you’re using a stacker or jukebox, you can write multiple tapes per run. Additional