1 This document contains notes on new features in Amanda 2.3 that may
2 not yet be fully documented elsewhere.
4 * INDEXING BACKUPS FOR EASIER RESTORE
6 Read more about this in the file named INDEXING.
10 Read more about this in the file named SAMBA.
14 Amanda now supports dumps made via Gnu TAR. To use this, set your
15 dumptypes set the program name to "GNUTAR":
22 Since Gnu TAR does not maintain a dumpdates file itself, nor give an
23 estimate of backup size, those need to be done within Amanda. Amanda
24 maintains an /etc/amandates file to track the backup dates analogously to
27 NOTE: if your /etc directory is not writable by your dumpuser, you'll have
28 to create the empty file initially by hand, and make it writable by your
29 dumpuser ala /etc/dumpdates.
31 NOTE: Since tar traverses the directory heirarchy and reads files as a
32 regular user would, it must run as root. The two new amanda programs
33 "calcsize" and "runtar" therefore must be installed setuid root. I've made
34 them as simple as possible to to avoid potential security holes.
37 * MULTIPLE BACKUPS IN PARALLEL FROM ONE CLIENT HOST
39 A new "maxdumps" parameter for the conf file gives the default value for
40 the amount of parallelism per client:
42 maxdumps 2 # default max num. dumps to do in parallel per client
44 If this default parameter is not specified, the default for the default :-0
45 is 1. Then, you can override the parameter per client through the
48 dumptype fast-client {
53 If the "maxdumps" parameter isn't given in the dumptypes, the default is
54 used. The idea is that maxdumps is set roughly proportional to the speed
55 of the client host. You probably wont get much benefit from setting it
56 very high, but all but the slowest hosts should be able to handle a
57 maxdumps of at least 2.
59 Amanda doesn't really have any per-host parameters, just per-disk, so the
60 per-client-host maxdumps is taken from the last disk listed for that host.
62 Just to make things more complicated, I've added the ability to specify a
63 "spindle number" for each filesystem in the disklist file. For example:
65 wiggum / fast-comp-user 0
66 wiggum /usr fast-comp-user 0
67 wiggum /larry fast-comp-user 1
68 wiggum /curly fast-comp-user 1
69 wiggum /moe fast-comp-user 1
70 wiggum /itchy fast-comp-user 2
71 wiggum /scratchy fast-comp-user 3
73 The spindle number represents the disk number, eg every filesystem on sd0
74 can get a spindle number of 0, everything on sd1 gets spindle 1, etc (but
75 there's no enforced requirement that there be a match with the underlying
76 hardware situation). Now, even with a high maxdumps, amanda will refrain
77 from scheduling two disks on the same spindle at the same time, which would
78 just slow them both down by adding a lot of seeks.
80 The default spindle if you don't specify one is -1, which is defined to be
81 a spindle that doesn't interfere with itself. That is if you don't specify
82 any spindle numbers, any and all filesystems on the host can be scheduled
83 concurrently up to the maxdumps.
85 Just to be clear, there's no relation between spindle numbers and maxdumps:
86 number the spindles by the disks that you have, even if that's more than
89 Also, I'm not sure that putting spindle numbers everywhere is of much
90 value: their purpose is to prevent multiple big dumps from being run at the
91 same time on two partitions on the same disk, on the theory that the extra
92 seeking between the partitions would cause the dumps to run slower than
93 they would if they ran sequentially. But, given the client-side
94 compression and network output that must occur between blocks read from the
95 disk, there may be enough slack time at the disk to support the seeks and
96 have a little parallelism left over to do some good.
99 * MULTIPLE TAPES IN ONE RUN
101 I've rewritten the taper - it now supports one run spanning multiple tapes
102 if you have a tape-changer. The necessary changes in support of this have
103 also been made to driver and reporter - planner already had support. There
104 are a couple other places that should probably be updated, like amcheck.
105 Dumps are not split across tapes - when taper runs into the end of a tape,
106 it loads the next tape and tells driver to try sending the dump again.
108 If you are feeling brave, set "runtapes" to something other than 1.
110 The new taper also keeps the tape open the entire time it is writing the
111 files out - no more having amchecks or other accesses/rewinds in the middle
112 of the run screw you royally if they hit when the tape is closed for
116 * BOTTLENECK DETERMINATION
118 I've made some experimental changes to Driver to determine what the
119 bottleneck is at any time. Since Amanda tries to do many things at once,
120 it's hard to pinpoint a single bottleneck, but I _think_ I've got it down
121 well enough to say something useful. For now it just outputs the current
122 bottleneck as part of its "driver: state" line in the debug output, but
123 once I'm comfortable with its conclusions, I'll output it to the log file
124 and have the reporter generate a nice table. The current choices are:
125 not-idle - if there were dumps to do, they got done
126 no-dumpers - there were dumps to do but no dumpers free
127 no-hold - there were dumps to do and dumpers free but the dumps
128 couldn't go to the holding disks (no-hold conf flag)
129 no-diskspace - no diskspace on holding disks
130 no-bandwidth - ran out of bandwidth
131 client-constrained - couldn't start any dumps because the clients
137 I've fixed the 2-gig limits by representing sizes in Kbytes instead of
138 bytes everywhere. This gives us a new 2 TB dump-file size limit (on 32bit
139 machines), which should last us a couple more years. This seemed
140 preferable to me than going to long-long or some other non-portable type
144 * AMADMIN IMPORT/EXPORT
146 Amadmin now has "import" and "export" commands, to convert the curinfo
147 database to/from text format, for: moving an amanda server to a different
148 arch, compressing the database after deleting lots of hosts, or editing one
149 or all entries in batch form or via a script.
152 ---------------------------------------------------------------------------
153 Here's the old 2.2.x stuff from this file. I'm pretty sure most of this
154 is in the mainline documentation already.
155 ---------------------------------------------------------------------------
157 This document contains notes on new features in Amanda 2.2 that may
158 not yet be fully documented elsewhere.
160 * CLIENT SIDE SETUP HAS CHANGED
162 The new /etc/services lines are:
163 amanda 10080/udp # bsd security amanda daemon
164 kamanda 10081/udp # krb4 security amanda daemon
166 The new /etc/inetd.conf lines are:
167 amanda dgram udp wait /usr/local/libexec/amanda/amandad amandad
168 kamanda dgram udp wait /usr/local/libexec/amanda/amandad amandad -krb4
170 (you don't need the vanilla amanda lines if you are using kerberos for
171 everything, and vice-versa)
174 * VERSION SUFFIXES ON EXECUTABLES
176 The new USE_VERSION_SUFFIXES define in options.h controls whether to
177 install the Amanda executables with the version number attached to the
178 name, eg "amdump-2.2.1". I recommend that you leave this defined, since
179 the this allows multiple versions to co-exist - particularly important
180 while amanda 2.2 is under development. You can always symlink the names
181 without the version suffix to the version you want to be your "production"
187 Read the comments in file docs/KERBEROS for how to configure the kerberos
188 version. With KRB4_SECURITY defined, there are two new dumptype options:
190 krb4-auth use krb4 auth for this host
191 (you can mingle krb hosts & bsd .rhosts in one conf)
192 kencrypt encrypt this filesystem over the net using the krb4
193 session key. About 2x slower. Good for those root
194 partitions containing your keyfiles. Don't want to
195 give away the keys to an ethernet sniffer!
198 * MULTIPLE HOLDING DISKS
200 You can have more than one holding disk for those really big installations.
201 Just add extra diskdir and disksize lines to your amanda.conf:
203 diskdir "/amanda2/amanda/work" # where the holding disk is
204 disksize 880 MB # how much space can we use on it
206 diskdir "/dumps/amanda/work" # a second holding disk!
209 Amanda will load-balance between the two disks as long as there is space.
210 Amanda now also actually stats files to get a more accurate view of
211 available and used disk space while running.
215 Amcheck will now cause self-checks to run on the client hosts, quickly
216 detecting which hosts are up and communicating, which have permissions
217 problems, etc. This is amazingly fast for what it does: here it checks
218 more than 130 hosts in less than a minute. My favorite gee-whiz new
219 feature! The new -s and -c options control whether server-only or
220 client-only checks are done.
224 System V shared memory primitives are no longer required on the server
225 side, if your system has a version of mmap() that will allocate
226 anonymous memory. BSD 4.4 systems (and OSF/1) have an explicitly
227 anonymous mmap() type, but others (like SunOS) support the trick of
228 mmap'ing /dev/zero for the same effect. Amanda should work with both
231 Defined HAVE_SYSVSHM or HAVE_MMAP (or both) in config.h. If you have
232 both, SYSVSHM is selected (simply because this code in Amanda is more
233 mature, not because the sysv stuff is better).
238 This was most requested feature #1; I've finally slipped it in. Define
239 HAVE_GZIP in options.h. See options.h-vanilla for details. There are two
240 new amanda.conf dumptype options "compress-fast" and "compress-best". The
241 default is "compress-fast". With gzip, compress-fast seems to always do
242 better than the old lzw compress (in particular it will never expand the
243 file), and runs faster too. Gzip's compress-best does very good
244 compression, but is about twice as slow as the old lzw compress, so you
245 don't want to use it for filesystems that take a long time to full-dump
249 * MOUNT POINT NAMES IN DISKLIST
251 Most requested feature #2: You can specify mount names in the disklist
252 instead of dev names. The rule is, if the filesystem name starts with a
253 slash, it is a mount point name, if it doesn't, it is a dev name, and has
254 DEVDIR prepended. For example:
256 obelix sd0a # dev-name: /dev/sd0a
257 obelix /obelix # mount name: /obelix, aka /dev/sd0g
260 * INITIAL TAPE CHANGER SUPPORT INCLUDED
262 A new amanda.conf parameter, tpchanger, controls whether Amanda
263 communicates with a tape changer program to load tapes rather than
264 just opening the tapedev itself. The tpchanger parameter is a string
265 which specifies the name of a program that follows the API specified
266 in docs/TAPE.CHANGERS. Read that doc for more information.
268 * GENERIC TAPE CHANGER WRAPPER SCRIPT
270 An initial tape-changer glue script, chg-generic.sh, implements the
271 Amanda changer API using an array of tape devices to simulate a tape
272 changer, with the device names specified via a conf file. This script
273 can be quickly customized by inserting calls tape-changer-specific
274 programs at appropriate places, making support for new changers
275 painless. If you know what command to execute to get your changer to
276 put a particular tape in the drive, you can get Amanda to support your
279 The generic script works as-is for sites that want to cascade between
280 two or more tape drives hooked directly up to the tape server host.
281 It also should work as-is with tape-changer drivers that use separate
282 device names to specify the slot to be loaded, wheres simply opening
283 the slot device causes the tape from that slot to be loaded.
285 chg-generic has its own small conf file. See example/chg-generic.conf
286 for a documented sample.
288 * NEW "amtape" COMMAND
290 The amtape is the user front-end to the amanda tape changer support
291 facilities. The operators can use amtape to load tapes for restores,
292 position the changer, see what amanda tapes are loaded in the tape
293 rack, and see which tape would be picked by taper for the next amdump
296 No man page yet, but running amtape with no arguments gives a detailed
297 usage statement. See docs/TAPE.CHANGERS for more info.
299 * CHANGER SUPPORT ADDED TO "amlabel" COMMAND
301 The amlabel command now takes an optional slot argument for labeling
302 particular tapes in the tape rack. See docs/TAPE.CHANGERS for more
306 * TAPE CHANGER SUPPORT IMPROVED
308 The specs in docs/TAPE.CHANGERS has been updated, and the code changed to
309 match. The major difference is that Amanda no longer assumes slots in the
310 tape rack are numbered from 0 to N-1. They can be numbered or labeled in
311 any manner that suits your tape-changer, amanda doesn't care what the
312 actual slot names are. Also added "first" and "last" slot specifiers, and
315 The chg-generic.sh tape changer script now has new "firstslot", "lastslot",
316 and "needeject" parameters for the chg-generic.conf file. It now keeps
317 track of whether the current slot is loaded into the drive, so that it can
318 issue an explicit eject command for those tape changers that need one. See
319 example/chg-generic.conf for more info.
322 * A FEW WORDS ABOUT MULTI-TAPE RUNS
324 I'm still holding back on support for multiple tapes in one run. I'm
325 not yet completely happy with how Amanda should handle splitting dumps
326 across tapes (eg when end-of-tape is encountered in the middle of a long
327 dump). For example, this creates issues for amrestore, which currently
328 doesn't know about configurations or tape changers --- on purpose, so
329 that you can do restores on any machine with a tape drive, not just the
330 server, and so that you can recover with no online databases present.
332 However, because the current snapshot DOES support tape changers, and
333 multiple runs in one day, some of the benefit of multi-tape runs can be
334 had by simply running amanda several times in a row. Eg, to fill three
335 tapes per night, you can put
336 amdump <conf>; amdump <conf>; amdump <conf>
337 in you crontab. On the down side, this will generate three reports
338 instead of one, will do more incremental dumps than necessary, and will
339 run slower. Not very satisfying, but if you *need* to fill more than
340 one tape per day NOW, it should work.
343 * BIG PLANNER CHANGES
345 The support for writing to multiple tapes in one run is almost finished
346 now. See docs/MULTITAPE for an outline of the design. The planner support
347 for this is included in this snapshot, but the taper part is not.
349 There is a new amanda.conf variable "runtapes" which specifies the number
350 of tapes to use on each amdump run. For now this should stay at 1, the
351 default. Also, the old "mincycle" and "maxcycle" amanda.conf variables are
352 deprecated, but still work for now. "maxcycle" was never used, and
353 "mincycle" is now called "dumpcycle".
355 There are two visible differences in the new planner: First, Planner now
356 thinks in real-time, rather than by the number of tapes as before. That
357 is, a filesystem is due for a full backup once every <dumpcycle> days,
358 regardless of how many times amanda is run in that interval. As a
359 consequence, you need to make sure the dumpcycle variable marks real time
360 instead of the number of days. For example, previously "mincycle 10"
361 worked for a two week cycle if you ran amdump only on weekdays (for 10 runs
362 in a cycle). Now a two week cycle must be specified as "dumpcycle 14" or
363 "dumpcycle 2 weeks". The "2 weeks" specifier works with both the old and
364 new versions of planner, because previously "weeks" multiplied by 5, and
365 now it multiplies by 7.
367 Second, planner now warns about impending overwrites of full backups. If a
368 filesystem's last full backup is on a tape that is due to be overwritten in
369 the next 5 runs, planner will give you a heads-up about it, so that you can
370 restore the filesystem somewhere, or switch that tape out of rotation
371 (substitute a new tape with the same label). This situation often occurs
372 after a hardware failure brings a machine or disk down for some days.
374 * LEVEL-0 DUMPS ALLOWED WITH NO TAPE
376 If there is no tape present (or the tape drive fails during dumping),
377 Amanda switches to degraded mode. In degraded mode, level-0 dumps
378 are not allowed. This can be a pain for unattended sites over the
379 weekend (especially when there is a large holding disk that can hold
380 any necessary dumps). Amanda now supports a new configuration file
381 directive, "reserve". This tells Amanda to reserve that percentage
382 of total holding disk space for degraded mode dumps. Example: your
383 total holding disk space adds up to 8.4GB. If you specify a reserve
384 of 50, 4.2GB (50%) of the holding disk space will be allowed to be
385 used for regular dumps, but if that limit is hit, Amanda will switch
386 to degraded dumps. For backward compatibility, if no 'reserve' keyword
387 is present, 100 will be assumed (e.g. never do full dumps if degraded
388 mode is in effect). NOTE: this percentage applies from run to run, so,
389 as in the previous example, when Amanda runs the next day, if there is
390 3.8GB left on the holding disk, 1.9GB will be reserved for degraded
391 mode dumps (e.g. the percentage keeps sliding).