Imported Upstream version 3.2.0
[debian/amanda] / example / template.d / advanced.conf.in
1 dumpuser "@CLIENT_LOGIN@"       # the user to run dumps under
2 inparallel 4            # maximum dumpers that will run in parallel (max 63)
3                         # this maximum can be increased at compile-time,
4                         # modifying MAX_DUMPERS in server-src/driverio.h
5
6 dumporder "sssS"        # specify the priority order of each dumper
7                         #   s -> smallest size
8                         #   S -> biggest size
9                         #   t -> smallest time
10                         #   T -> biggest time
11                         #   b -> smallest bandwidth
12                         #   B -> biggest bandwitdh
13                         # try "BTBTBTBTBTBT" if you are not holding
14                         # disk constrained
15
16 taperalgo first         # The algorithm used to choose which dump image to send
17                         # to the taper.
18
19                         # Possible values: [first|firstfit|largest|largestfit|smallest|last]
20                         # Default: first. 
21
22                         # first         First in - first out.
23                         # firstfit      The first dump image that will fit on the current tape.
24                         # largest       The largest dump image.
25                         # largestfit    The largest dump image that will fit on the current tape.
26                         # smallest      The smallest dump image.
27                         # last          Last in - first out.
28 displayunit "g"         # Possible values: "k|m|g|t"
29                         # Default: k. 
30                         # The unit used to print many numbers.
31                         # k=kilo, m=mega, g=giga, t=tera
32 netusage  8000 Kbps     # maximum net bandwidth for Amanda, in KB per sec
33
34 bumpsize 20 Mb          # minimum savings (threshold) to bump level 1 -> 2
35 bumppercent 20          # minimum savings (threshold) to bump level 1 -> 2
36 bumpdays 1              # minimum days at each level
37
38 # By default, Amanda can only track at most one run per calendar day. When
39 # the usetimestamps option is enabled, however, Amanda can track as many
40 # runs as you care to make.
41 # WARNING: This option is not backward-compatible. Do not enable it if you
42 #          intend to downgrade your server installation to any version
43 #          earlier than Amanda 2.5.1
44 usetimestamps yes
45
46 device_output_buffer_size 1280k
47                         # amount of buffer space to use when writing to devices
48
49 # If you want Amanda to automatically label any non-Amanda tapes it
50 # encounters, uncomment the line below. Note that this will ERASE any
51 # non-Amanda tapes you may have, and may also ERASE any near-failing tapes.
52 # Use with caution.
53 ## autolabel "DailySet1-%%%" empty
54                         
55 maxdumpsize -1          # Maximum total size the planner will schedule
56                         # for a run (default: runtapes * tape_length) (kbytes).
57 bumpmult 4              # threshold = bumpsize * bumpmult^(level-1)
58
59
60
61 amrecover_changer "changer"     # amrecover will use the changer if you restore
62     # from this device. It could be a string like 'changer' and amrecover will use your
63     # changer if you set your tape to 'changer' with 'setdevice changer' or via 
64     # 'tapedev "changer"' in amanda-client.conf
65
66
67
68
69 # If amanda cannot find a tape on which to store backups, it will run
70 # as many backups as it can to the holding disks.  In order to save
71 # space for unattended backups, by default, amanda will only perform
72 # incremental backups in this case, i.e., it will reserve 100% of the
73 # holding disk space for the so-called degraded mode backups.
74 # However, if you specify a different value for the `reserve'
75 # parameter, amanda will not degrade backups if they will fit in the
76 # non-reserved portion of the holding disk.
77
78 # reserve 30 # percent
79 # This means save at least 30% of the holding disk space for degraded
80 # mode backups.  
81
82 autoflush no 
83 # if autoflush is set to yes, then amdump will schedule all dump on
84 # holding disks to be flush to tape during the run.
85
86 # Amanda needs a few Mb of diskspace for the log and debug files,
87 # as well as a database.  This stuff can grow large, so the conf directory
88 # isn't usually appropriate.  Some sites use /usr/local/var and some /usr/adm.
89 # Create an amanda directory under there.  You need a separate infofile and
90 # logdir for each configuration, so create subdirectories for each conf and
91 # put the files there.  Specify the locations below.
92
93 # Note that, although the keyword below is infofile, it is only so for
94 # historic reasons, since now it is supposed to be a directory (unless
95 # you have selected some database format other than the `text' default)
96 infofile "@CONFIG_DIR@/@DEFAULT_CONFIG@/curinfo"      # database DIRECTORY
97 logdir   "@CONFIG_DIR@/@DEFAULT_CONFIG@"              # log directory
98 indexdir "@CONFIG_DIR@/@DEFAULT_CONFIG@/index"        # index directory
99 #tapelist "@CONFIG_DIR/DailySet1/tapelist"      # list of used tapes
100 # tapelist is stored, by default, in the directory that contains amanda.conf
101
102 # Specify holding disks.  These are used as a temporary staging area for
103 # dumps before they are written to tape and are recommended for most sites.
104 # The advantages include: tape drive is more likely to operate in streaming
105 # mode (which reduces tape and drive wear, reduces total dump time); multiple
106 # dumps can be done in parallel (which can dramatically reduce total dump time.
107 # The main disadvantage is that dumps on the holding disk need to be flushed
108 # (with amflush) to tape after an operating system crash or a tape failure.
109 # If no holding disks are specified then all dumps will be written directly
110 # to tape.  If a dump is too big to fit on the holding disk than it will be
111 # written directly to tape.  If more than one holding disk is specified then
112 # they will all be used based on activity and available space.
113
114 #holdingdisk hd1 {
115 #    comment "main holding disk"
116 #    directory "/dumps/amanda"  # where the holding disk is
117 #    use -100 Mb                # how much space can we use on it
118 #                       # a non-positive value means:
119 #                       #        use all space but that value
120 #    chunksize 1Gb      # size of chunk if you want big dump to be
121 #                       # dumped on multiple files on holding disks
122 #                       #  N Kb/Mb/Gb split images in chunks of size N
123 #                       #             The maximum value should be
124 #                       #             (MAX_FILE_SIZE - 1Mb)
125 #                       #  0          same as INT_MAX bytes
126 #    }
127 #holdingdisk hd2 {
128 #    directory "/dumps2/amanda"
129 #    use 1000 Mb
130 #    }
131
132 # network interfaces
133 #
134 # These are referred to by the disklist file.  They define the attributes
135 # of the network interface that the remote machine is accessed through.
136 # Notes: - netusage above defines the attributes t
137 #          disklist entry doesn't specify otherwise.
138 #        - the values below are only samples.
139 #        - specifying an interface does not force the traffic to pass
140 #          through that interface.  Your OS routing tables do that.  This
141 #          is just a mechanism to stop Amanda trashing your network.
142 # Attributes are:
143 #       use             - bandwidth above which amanda won't start
144 #                         backups using this interface.  Note that if
145 #                         a single backup will take more than that,
146 #                         amanda won't try to make it run slower!
147
148 define interface local {
149     comment "a local disk"
150     use 8000 kbps
151 }
152
153 #define interface le0 {
154 #    comment "10 Mbps ethernet"
155 #    use 400 kbps
156 #}