2 Chapter 29. What once was new
3 Prev Part VI. Historical files Next
5 -------------------------------------------------------------------------------
7 Chapter 29. What once was new
17 XML-conversion, Updates
23 What's_new_in_AMANDA_2.3
26 Indexing_backups_for_easier_restore
32 Multiple_backups_in_parallel_from_one_client_host
34 Multiple_tapes_in_one_run
36 Bottleneck_determination
43 What's_new_in_AMANDA_2.2
46 Client_side_setup_has_changed
48 Version_suffixes_on_executables
52 Multiple_holding_disks
60 Mount_point_names_in_disklist
62 Initial_tape-changer_support_included
64 Generic_tape_changer_wrapper_script
68 Changer_support_added_to_command_amlabel
70 Tape_changer_support_improved
72 A_few_words_about_multi-tape_runs
76 Level-0_dumps_allowed_with_no_tape
82 Refer to http://www.amanda.org/docs/whatwasnew.html for the current version of
85 What's new in AMANDA 2.3
87 This document contains notes on new features in AMANDA 2.3 that may not yet be
88 fully documented elsewhere.
90 Indexing backups for easier restore
92 Read more about this in the file named Indexing_with_AMANDA.
96 Read more about this in the file named Backup_PC_hosts_using_Samba.
100 AMANDA now supports dumps made via GnuTAR. To use this, set your dumptypes set
101 the program name to "GNUTAR":
103 dumptype tar-client {
109 Since Gnu TAR does not maintain a dumpdates file itself, nor give an estimate
110 of backup size, those need to be done within AMANDA. AMANDA maintains an /etc/
111 amandates file to track the backup dates analogously to how dump does it.
112 NOTE: if your /etc directory is not writable by your dumpuser, you'll have to
113 create the empty file initially by hand, and make it writable by your dumpuser
115 NOTE: Since tar traverses the directory hierarchy and reads files as a regular
116 user would, it must run as root. The two new AMANDA programs calcsize and
117 runtar therefore must be installed setuid root. I've made them as simple as
118 possible to to avoid potential security holes.
120 Multiple backups in parallel from one client host
122 A new "maxdumps" parameter for the conf file gives the default value for the
123 amount of parallelism per client:
125 maxdumps 2 # default max num. dumps to do in parallel per client
128 If this default parameter is not specified, the default for the default :-0 is
129 1. Then, you can override the parameter per client through the dumptype, eg:
131 dumptype fast-client {
137 If the "maxdumps" parameter isn't given in the dumptypes, the default is used.
138 The idea is that maxdumps is set roughly proportional to the speed of the
139 client host. You probably wont get much benefit from setting it very high, but
140 all but the slowest hosts should be able to handle a maxdumps of at least 2.
141 AMANDA doesn't really have any per-host parameters, just per-disk, so the per-
142 client-host maxdumps is taken from the last disk listed for that host.
143 Just to make things more complicated, I've added the ability to specify a
144 "spindle number" for each filesystem in the disklist file. For example:
146 wiggum / fast-comp-user 0
147 wiggum /usr fast-comp-user 0
148 wiggum /larry fast-comp-user 1
149 wiggum /curly fast-comp-user 1
150 wiggum /moe fast-comp-user 1
151 wiggum /itchy fast-comp-user 2
152 wiggum /scratchy fast-comp-user 3
155 The spindle number represents the disk number, eg every filesystem on sd0 can
156 get a spindle number of 0, everything on sd1 gets spindle 1, etc (but there's
157 no enforced requirement that there be a match with the underlying hardware
158 situation). Now, even with a high maxdumps, AMANDA will refrain from scheduling
159 two disks on the same spindle at the same time, which would just slow them both
160 down by adding a lot of seeks.
161 The default spindle if you don't specify one is -1, which is defined to be a
162 spindle that doesn't interfere with itself. That is if you don't specify any
163 spindle numbers, any and all filesystems on the host can be scheduled
164 concurrently up to the maxdumps.
165 Just to be clear, there's no relation between spindle numbers and maxdumps:
166 number the spindles by the disks that you have, even if that's more than
168 Also, I'm not sure that putting spindle numbers everywhere is of much value:
169 their purpose is to prevent multiple big dumps from being run at the same time
170 on two partitions on the same disk, on the theory that the extra seeking
171 between the partitions would cause the dumps to run slower than they would if
172 they ran sequentially. But, given the client-side compression and network
173 output that must occur between blocks read from the disk, there may be enough
174 slack time at the disk to support the seeks and have a little parallelism left
175 over to do some good.
177 Multiple tapes in one run
179 I've rewritten the taper - it now supports one run spanning multiple tapes if
180 you have a tape-changer. The necessary changes in support of this have also
181 been made to driver and reporter - planner already had support. There are a
182 couple other places that should probably be updated, like amcheck. Dumps are
183 not split across tapes - when taper runs into the end of a tape, it loads the
184 next tape and tells driver to try sending the dump again.
185 If you are feeling brave, set "runtapes" to something other than 1.
186 The new taper also keeps the tape open the entire time it is writing the files
187 out - no more having amchecks or other accesses/rewinds in the middle of the
188 run screw you royally if they hit when the tape is closed for writing a
191 Bottleneck determination
193 I've made some experimental changes to driver to determine what the bottleneck
194 is at any time. Since AMANDA tries to do many things at once, it's hard to
195 pinpoint a single bottleneck, but I "think" I've got it down well enough to say
196 something useful. For now it just outputs the current bottleneck as part of its
197 "driver: state" line in the debug output, but once I'm comfortable with its
198 conclusions, I'll output it to the log file and have the reporter generate a
199 nice table. The current choices are:
201 * not-idle - if there were dumps to do, they got done
202 * no-dumpers - there were dumps to do but no dumpers free
203 * no-hold - there were dumps to do and dumpers free but the dumps
204 * couldn't go to the holding disks (no-hold conf flag)
205 * no-diskspace - no diskspace on holding disks
206 * no-bandwidth - ran out of bandwidth
207 * client-constrained - couldn't start any dumps because the clients were busy
212 I've fixed the 2-gig limits by representing sizes in Kbytes instead of bytes
213 everywhere. This gives us a new 2 TB dump-file size limit (on 32bit machines),
214 which should last us a couple more years. This seemed preferable to me than
215 going to long-long or some other non-portable type for the size.
217 amadmin import/export
219 amadmin now has "import" and "export" commands, to convert the curinfo database
220 to/from text format, for: moving an AMANDA server to a different arch,
221 compressing the database after deleting lots of hosts, or editing one or all
222 entries in batch form or via a script.
224 What's new in AMANDA 2.2
229 Here's the old 2.2.x stuff from this file. I'm pretty sure most of this is in
230 the mainline documentation already.
231 This document contains notes on new features in AMANDA 2.2 that may not yet be
232 fully documented elsewhere.
234 Client side setup has changed
236 The new /etc/services lines are:
238 amanda 10080/udp # bsd security AMANDA daemon
239 kamanda 10081/udp # krb4 security AMANDA daemon
241 The new /etc/inetd.conf lines are:
243 amanda dgram udp wait /usr/local/libexec/amanda/amandad amandad
244 kamanda dgram udp wait /usr/local/libexec/amanda/amandad amandad -krb4
246 (you don't need the vanilla AMANDA lines if you are using kerberos for
247 everything, and vice-versa)
249 Version suffixes on executables
251 The new USE_VERSION_SUFFIXES define in options.h controls whether to install
252 the AMANDA executables with the version number attached to the name, eg
253 "amdump-2.2.1". I recommend that you leave this defined, since this allows
254 multiple versions to co-exist - particularly important while AMANDA 2.2 is
255 under development. You can always symlink the names without the version suffix
256 to the version you want to be your "production" version.
260 Read the comments in Using_Kerberos_with_AMANDA for how to configure the
261 kerberos version. With KRB4_SECURITY defined, there are two new dumptype
265 krb4-auth # use krb4 auth for this host
266 # (you can mingle krb hosts & bsd .rhosts in one conf)
270 kencrypt # encrypt this filesystem over the net using the krb4
271 # session key. About 2x slower. Good for those root
272 # partitions containing your keyfiles. Don't want to
273 # give away the keys to an ethernet sniffer!
278 Multiple holding disks
280 You can have more than one holding disk for those really big installations.
281 Just add extra diskdir and disksize lines to your amanda.conf:
285 sgw: This is OLD syntax now ...
287 diskdir "/AMANDA2/AMANDA/work" # where the holding disk is
288 disksize 880 MB # how much space can we use on it
290 diskdir "/dumps/AMANDA/work" # a second holding disk!
294 AMANDA will load-balance between the two disks as long as there is space.
295 AMANDA now also actually stats files to get a more accurate view of available
296 and used disk space while running.
300 amcheck will now cause self-checks to run on the client hosts, quickly
301 detecting which hosts are up and communicating, which have permissions
302 problems, etc. This is amazingly fast for what it does: here it checks more
303 than 130 hosts in less than a minute. My favorite gee-whiz new feature! The new
304 -s and -c options control whether server-only or client-only checks are done.
308 System V shared memory primitives are no longer required on the server side, if
309 your system has a version of mmap() that will allocate anonymous memory. BSD
310 4.4 systems (and OSF/1) have an explicitly anonymous mmap() type, but others
311 (like SunOS) support the trick of mmap'ing /dev/zero for the same effect.
312 AMANDA should work with both varieties.
313 Defined HAVE_SYSVSHM or HAVE_MMAP (or both) in config.h. If you have both,
314 SYSVSHM is selected (simply because this code in AMANDA is more mature, not
315 because the sysv stuff is better).
319 This was most requested feature #1; I've finally slipped it in. Define
320 HAVE_GZIP in options.h. See options.h-vanilla for details. There are two new
321 amanda.conf dumptype options "compress-fast" and "compress-best". The default
322 is "compress-fast". With gzip, compress-fast seems to always do better than the
323 old lzw compress (in particular it will never expand the file), and runs faster
324 too. Gzip's compress-best does very good compression, but is about twice as
325 slow as the old lzw compress, so you don't want to use it for filesystems that
326 take a long time to full-dump anyway.
328 Mount point names in disklist
330 Most requested feature #2: You can specify mount names in the disklist instead
331 of dev names. The rule is, if the filesystem name starts with a slash, it is a
332 mount point name, if it doesn't, it is a dev name, and has DEVDIR prepended.
335 obelix sd0a # dev-name: /dev/sd0a
336 obelix /obelix # mount name: /obelix, aka /dev/sd0g
340 Initial tape-changer support included
342 A new amanda.conf parameter, tpchanger, controls whether AMANDA communicates
343 with a tape changer program to load tapes rather than just opening the tapedev
344 itself. The tpchanger parameter is a string which specifies the name of a
345 program that follows the API specified in AMANDA_Tape_Changer_Support. Read
346 that for more information.
348 Generic tape changer wrapper script
350 An initial tape-changer glue script, chg-generic.sh, implements the AMANDA
351 changer API using an array of tape devices to simulate a tape changer, with the
352 device names specified via a conf file. This script can be quickly customized
353 by inserting calls tape-changer-specific programs at appropriate places, making
354 support for new changers painless. If you know what command to execute to get
355 your changer to put a particular tape in the drive, you can get AMANDA to
356 support your changer.
357 The generic script works as-is for sites that want to cascade between two or
358 more tape drives hooked directly up to the tape server host. It also should
359 work as-is with tape-changer drivers that use separate device names to specify
360 the slot to be loaded, wheres simply opening the slot device causes the tape
361 from that slot to be loaded.
362 chg-generic has its own small conf file. See example/chg-generic.conf for a
367 amtape is the user front-end to the AMANDA tape changer support facilities. The
368 operators can use amtape to load tapes for restores, position the changer, see
369 what AMANDA tapes are loaded in the tape rack, and see which tape would be
370 picked by taper for the next amdump run.
371 No man page yet, but running amtape with no arguments gives a detailed usage
372 statement. See AMANDA_Tape_Changer_Support for more info.
376 sgw: The manpage exists now.
378 Changer support added to command amlabel
380 The amlabel command now takes an optional slot argument for labeling particular
381 tapes in the tape rack. See AMANDA_Tape_Changer_Support for more info.
383 Tape changer support improved
385 The specs in AMANDA_Tape_Changer_Support have been updated, and the code
386 changed to match. The major difference is that AMANDA no longer assumes slots
387 in the tape rack are numbered from 0 to N-1. They can be numbered or labeled in
388 any manner that suits your tape-changer, AMANDA doesn't care what the actual
389 slot names are. Also added "first" and "last" slot specifiers, and an -eject
391 The chg-generic.sh tape changer script now has new "firstslot", "lastslot", and
392 "needeject" parameters for the chg-generic.conf file. It now keeps track of
393 whether the current slot is loaded into the drive, so that it can issue an
394 explicit eject command for those tape changers that need one. See example/chg-
395 generic.conf for more info.
397 A few words about multi-tape runs
399 I'm still holding back on support for multiple tapes in one run. I'm not yet
400 completely happy with how AMANDA should handle splitting dumps across tapes (eg
401 when end-of-tape is encountered in the middle of a long dump). For example,
402 this creates issues for amrestore, which currently doesn't know about
403 configurations or tape changers --- on purpose, so that you can do restores on
404 any machine with a tape drive, not just the server, and so that you can recover
405 with no online databases present.
406 However, because the current snapshot DOES support tape changers, and multiple
407 runs in one day, some of the benefit of multi-tape runs can be had by simply
408 running AMANDA several times in a row. Eg, to fill three tapes per night, you
411 amdump <conf>; amdump <conf>; amdump <conf>
413 in you crontab. On the down side, this will generate three reports instead of
414 one, will do more incremental dumps than necessary, and will run slower. Not
415 very satisfying, but if you need to fill more than one tape per day NOW, it
420 The support for writing to multiple tapes in one run is almost finished now.
421 See Multitape_support_in_AMANDA_2.2 for an outline of the design. The planner
422 support for this is included in this snapshot, but the taper part is not.
423 There is a new amanda.conf variable "runtapes" which specifies the number of
424 tapes to use on each amdump run. For now this should stay at 1, the default.
425 Also, the old "mincycle" and "maxcycle" amanda.conf variables are deprecated,
426 but still work for now. "maxcycle" was never used, and "mincycle" is now called
428 There are two visible differences in the new planner: First, planner now thinks
429 in real-time, rather than by the number of tapes as before. That is, a
430 filesystem is due for a full backup once every <dumpcycle> days, regardless of
431 how many times AMANDA is run in that interval. As a consequence, you need to
432 make sure the dumpcycle variable marks real time instead of the number of days.
433 For example, previously "mincycle 10" worked for a two week cycle if you ran
434 amdump only on weekdays (for 10 runs in a cycle). Now a two week cycle must be
435 specified as "dumpcycle 14" or "dumpcycle 2 weeks". The "2 weeks" specifier
436 works with both the old and new versions of planner, because previously "weeks"
437 multiplied by 5, and now it multiplies by 7.
438 Second, planner now warns about impending overwrites of full backups. If a
439 filesystem's last full backup is on a tape that is due to be overwritten in the
440 next 5 runs, planner will give you a heads-up about it, so that you can restore
441 the filesystem somewhere, or switch that tape out of rotation (substitute a new
442 tape with the same label). This situation often occurs after a hardware failure
443 brings a machine or disk down for some days.
445 Level-0 dumps allowed with no tape
447 If there is no tape present (or the tape drive fails during dumping), AMANDA
448 switches to degraded mode. In degraded mode, level-0 dumps are not allowed.
449 This can be a pain for unattended sites over the weekend (especially when there
450 is a large holding disk that can hold any necessary dumps). AMANDA now supports
451 a new configuration file directive, "reserve". This tells AMANDA to reserve
452 that percentage of total holding disk space for degraded mode dumps. Example:
453 your total holding disk space adds up to 8.4GB. If you specify a reserve of 50,
454 4.2GB (50%) of the holding disk space will be allowed to be used for regular
455 dumps, but if that limit is hit, AMANDA will switch to degraded dumps. For
456 backward compatibility, if no 'reserve' keyword is present, 100 will be assumed
457 (e.g. never do full dumps if degraded mode is in effect).
461 This percentage applies from run to run, so, as in the previous example, when
462 AMANDA runs the next day, if there is 3.8GB left on the holding disk, 1.9GB
463 will be reserved for degraded mode dumps (e.g. the percentage keeps sliding).
464 -------------------------------------------------------------------------------
467 Chapter 28. Upgrade Issues Home Chapter 30. Multitape support in AMANDA 2.2