UNIX System Administration Handbook - Evi Nemeth [123]
The tapecycle parameter tells how many tapes you plan to use in regular rotation. A minimal value is the number of runs per dump cycle times the number of tapes per run, plus a few extra to handle edge conditions and tape problems. If you allocate at least twice the minimal number of tapes, you are always guaranteed to have on hand at least two level 0 dumps of each filesystem.
The “bump” parameters let you exercise some control over how large an incremental dump must become before Amanda shifts up to the next level of dump. The parameters are specified in a rather mathematical and nonintuitive way. Fortunately, you can use the bumpsize option of amadmin to make sure that you’ve really implemented the strategy you intended.
For example, with the parameters shown above and assuming the configuration files are stored in a directory called podunk, amadmin would report:
# amadmin podunk bumpsize
Current bump parameters:
bumpsize 20480 KB - minimum savings (threshold) to bump level 1 -> 2
bumpdays 2 - minimum days at each level
bumpmult 2 - threshold = bumpsize * (level-1)**bumpmult
Bump -> To Threshold
1 -> 2 20480 KB
2 -> 3 40960 KB
3 -> 4 81920 KB
4 -> 5 163840 KB
5 -> 6 327680 KB
6 -> 7 655360 KB
7 -> 8 1310720 KB
8 -> 9 2621440 KB
After an initial level 0, Amanda will start by doing level 1 dumps. Once the level 1 dumps become larger than 20MB, Amanda will shift to level 2 dumps. Once the level 2 dumps get larger than 40MB, Amanda will move up to level 3, and so on.
You should carefully tune these parameters to balance your desire for redundancy against the cost of tapes. Too much redundancy will result in high operating costs, and too little redundancy may result in lost data.
The rest of amanda.conf is devoted to parameters that specify how much network bandwidth, CPU, and disk space (on the server) to use; the type of tape drive to back up to; and the types of client partitions to be backed up.
##########################################################
# Resource parameters
##########################################################
tapetype EXB-8500 # what kind of tape it is (see tapetypes below)
inparallel 4 # maximum client dumpers that will run in parallel
netusage 600 Kbps # maximum net bandwidth for Amanda, in KB per sec
etimeout 300 # number of seconds to wait for estimate per filesystem
holdingdisk hd1 {
comment "main holding disk"
directory "/dumps/amanda" # mount point of holding disk
use 8196 Mb # how much space we can use on it
}
define tapetype EXB-8500 {
comment "Exabyte EXB-8500 drive on decent machine"
length 4200 mbytes
filemark 48 kbytes
speed 474 kbytes
}
This example shows the configuration for an Exabyte 8500 tape drive. The tape type parameters are extremely important and should never be guessed. If your tape drive isn’t listed in the sample amanda.conf file that comes with the distribution, you can probably find it in the docs/TAPETYPES file or at
http://www.cs.columbia.edu/~sdossick/amanda
You might also try asking for an appropriate configuration on one of the amanda mailing lists. If all else fails, you can use the tapetype program that comes with Amanda. It determines the correct parameters for your tape drive by filling a tape with 32KB blocks. However, regard this procedure as a last resort—it can take a very long time (1 or 2 days!) on some tape drives.
The final resource parameters are the dump types, which represent the different types of data (e.g., volatile, important, static, etc.) that filesystems might contain. Each filesystem on a client must be assigned a particular dump type. The dump type also specifies what kind of compression (if any) should be applied when the data is archived. Here are some examples:
##########################################################
# Dump type definitions
##########################################################
define dumptype comp-user {
comment "partitions on reasonably fast machines"
compress client fast
priority medium
}
define dumptype comp-root