1 This file contains answers to some questions that are frequently asked
2 in the Amanda mailing lists, specially by new users. Please take a
3 look at this file before posting, this can save us time that could be
4 spent improving Amanda and its documentation.
6 New entries and modifications are welcome; send them to
7 amanda-users@amanda.org or amanda-hackers@amanda.org.
9 You may also want to take a look at the Amanda FAQ-O-Matic
10 http://www.amanda.org/fom-serve/cache/1.html
13 Q: Why does Amanda fail to build on my system?
15 A: One of the most common reasons for compile-time errors is stale
16 information in `config.cache', after a build on a different platform
17 using the same build tree. In order to avoid this problem, make sure
18 you don't ever reuse build trees across platforms, or at least run
19 `make distclean' before running `configure' on another platform.
21 Another common reason for failure, that causes link-time errors, is
22 a problem in libtool that causes it to search for symbols in
23 already-installed amanda libraries, instead of in the just-built ones.
24 This problem is known to affect SunOS 4.1.3 and FreeBSD. You can
25 usually work around it by specifying a different prefix when you
26 configure the new version of Amanda. However, it may not work if the
27 previous version of Amanda was installed in /usr/local and gcc
28 searches this directory by default; in this case, you must either
29 remove the old libraries (which you don't want to do, right? :-) or
30 call configure with the flag --disable-libtool. In this case, Amanda
31 won't create shared libraries, so binaries will be larger, but you may
32 worry about that later.
34 You may also want to take a look at docs/SYSTEM.NOTES, as well as
35 to the Amanda Patches Page (check www.amanda.org) for other known
36 problems. If everything fails, you should read the manual, but since
37 we don't have one yet, just post a help request to the amanda-users
38 mailing list, showing the last few lines of the failed build.
41 Q: Why does `amdump' report that all disks failed?
43 A: Probably because the Amanda clients are not properly configured.
44 Before you ever run `amdump', make sure `amcheck' succeeds. When it
45 does, so should `amdump'.
47 Make sure you run `amcheck' as the same user that is supposed to
48 start `amdump', otherwise you may get incorrect results.
51 Q: Why does `amcheck' say `port NNN is not secure'?
53 A: Because `amcheck', as some other Amanda programs, must be installed
54 as setuid-root. Run `make install' as `root', or `chown' all Amanda
55 setuid programs to `root', then `chmod u+s' them again, if `chown'
59 Q: Why does `amcheck' claim that the tape is `not an amanda tape'?
61 A: Because Amanda requires you to label tapes before it uses them.
62 Run `amlabel' in order to label a tape.
64 If, even after labeling a tape, `amcheck' still complains about it,
65 make sure the regular expression specified in amanda.conf matches the
66 label you have specified, and check whether you have configured
67 non-rewinding tape devices for Amanda to use. For example, use
68 /dev/nrst0 instead of /dev/rst0, /dev/rmt/0bn instead of /dev/rmt/0b,
69 or some other system-dependent device name that contains an `n',
70 instead of one that does not. The `n' stands for non-rewinding.
72 If you have labeled any tapes using the rewiding device
73 configuration, you'll have to label them again.
76 Q: Why does `amcheck' report `selfcheck request timed out'?
78 A: This can occur under several different situations. First, make
79 sure this problem is repeatable; if Amanda programs are
80 NFS-auto-mounted, some clients may fail to mount the Amanda binaries
83 If the error is repeatable, log into the client, and check whether
84 the directory /tmp/amanda exists, and a file named amandad.debug
85 exists in there: amandad will create this file whenever it starts. If
86 this file does not exist, amandad is not starting properly, or it
87 lacks permission to create /tmp/amanda/amandad.debug.
89 In the latter case, wipe out /tmp/amanda, and amandad should create
90 it next time it runs. In the former case, check your inetd
91 configuration. Make sure you have added the Amanda services to
92 /etc/services (or the NIS services map), that /etc/inetd.conf was
93 properly configured, and that you have signalled inetd to reread this
94 file (some systems may need rebooting). Check section 2.2 from the
95 INSTALL file for details. Check the inetd man-page for possible
96 differences between the standard inetd.conf format and the one in your
99 Pay special attention to typos in inetd.conf; error messages will
100 probably appear in /var/adm/messages or /var/log/messages if you have
101 typed the amandad program name incorrectly. Make sure the same user
102 that you have specified at configure-time (--with-user=<USERNAME>) is
103 listed in inetd.conf. Check whether this user has permission to run
104 amandad, as well as any shared libraries amandad depends upon, by
105 running the specified amandad command by hand, as the Amanda user. It
106 should just time-out after 30 seconds waiting for a UDP packet. If
107 you type anything, it will abort immediately, because it can't read a
108 UDP packet from the keyboard.
110 As soon as you have properly configured inetd.conf so as to run
111 amandad, you should no longer get the `selfcheck request timed out'
112 message. A nice tool to help make sure inetd is really listening on
113 the amandad port is lsof, available at
114 ftp://vic.cc.purdue.edu/pub/tools/unix/lsof.
117 Q: Why does `amandad.debug' contain `error receiving message'?
119 A: One possibility is that you have run `amandad' from the command
120 line prompt and typed anything instead of waiting for it to time-out:
121 in this case, it will try to read a UDP packet from the keyboard, and
122 this was reported not to work on most keyboards :-). However, if you
123 have run `amandad' as any user other than the one listed in
124 `inetd.conf', it may have created a /tmp/amanda directory that the
125 Amanda user cannot write to, so you should wipe it out.
127 Another possibility is that the Amanda service was not properly
128 configured as a UDP service; check /etc/services and /etc/inetd.conf.
131 Q: Why does `amcheck' say `access as <username> not allowed...'
133 A: There must be something wrong with .amandahosts configuration (or
134 .rhosts, if you have configured --without-amandahosts).
136 First, if the <username> is not what you expect (i.e., not what you
137 have specified in the --with-user flag, at configure time), check the
138 inetd configuration file: you must have specified the wrong username
141 Make sure you specify the names exactly as they appear in the error
142 message after the `@' sign in .amandahosts/.rhosts. You'll need a
143 fully-qualified domain name or not, depending on how your client
144 resolves IP addresses to host names.
147 Q: Why does `amcheck' report `ip address #.#.#.# is not in the ip list
148 list for <hostname>'?
150 A: Check your DNS configuration tables. In order to avoid
151 DNS-spoofing, Amanda double-checks hostname<->IP address mapping. If
152 the IP address the request comes from maps to a hostname, but this
153 hostname does not map back to the incoming IP address, the request is
157 Q: Why does `amcheck' say `cannot overwrite active tape'?
159 A: Because, if you configure Amanda to use N tapes, by setting
160 tapecycle to N in `amanda.conf', before Amanda overwrites a tape, it
161 must write to at least other N-1 tapes. Of course, Amanda will always
162 refuse to overwrite a tape marked for `noreuse' with `amadmin'.
163 Furthermore, such tapes are not counted when Amanda computes `N-1'
166 If, for some reason, you want to tell Amanda to overwrite a
167 particular tape, regardless of its position in the cycle, use
168 `amrmtape'. This command will remove this tape from the `tapelist'
169 file, that is used to manage the tape cycle, and will delete
170 information about backups stored in that tape from the Amanda
174 Q: Why does `amcheck' tell me `DUMP program not available'?
176 A: Because the `configure' could not find DUMP when it was first run.
177 This is a common problem on Linux hosts, because most Linux
178 distributions do not install DUMP by default.
180 If you don't have a DUMP program installed, install it, remove
181 `config.cache', run `configure' again and rebuild Amanda. While
182 `configure' is running, make sure it can find the installed DUMP
183 program. If it cannot, you may have to set the environment variables
184 DUMP and RESTORE by hand, before running configure.
186 If you can't or don't want to install DUMP, you may use GNU tar,
187 but make sure it as release 1.12 or newer; release 1.11.8 may work,
188 but estimates will be slow as hell.
191 Q: Which tape changer configuration should I use in amanda.conf?
193 A: If you only have one tape unit, you have two choices: (i) don't use
194 a tape changer at all, i.e., set runtapes to 1, set tapedev to the
195 non-rewinding device corresponding to the tape unit, and comment out
196 tpchanger, changerfile and changerdev; or (ii) set up chg-manual, so
197 that you can change tapes manually. If you select chg-manual, you
198 will not be able to start `amdump' as a cron job, and you should
199 always run `amflush -f', because chg-manual will ask you to press
200 return in the terminal where you started the controlling program.
202 If you have several tape units, which you want to use to emulate a
203 tape changer, you want chg-multi. Even if you do own a real tape
204 changer, that operates based on ejecting a tape or such, chg-multi may
207 Actual tape changers usually require specialized changer programs,
208 such as `mtx', `chio' or specific system calls. The availability of
209 these programs is much more dependent on the operating system you're
210 running than on the particular tape changer hardware you have.
212 `mtx', for example, is available for several platforms. However,
213 even if you find it for your platform, beware that there exist several
214 different programs named `mtx', that require different command line
215 arguments, and print different output, and Amanda's chg-mtx does not
216 support them all. You may have to edit the script, which shouldn't be
219 In section BUILT-IN TAPE CHANGERS of docs/TAPE.CHANGERS, you will
220 find details about the tape changer interfacing programs provided with
221 Amanda, that can interact with common tape changer programs and with
222 tape changer-related system calls provided by some operating system.
223 If none of them matches your needs, you may have to develop your own
224 tape changer interface script.
226 Before posting a question to the Amanda mailing lists, *please*
227 search the archives, and try to obtain as much information about
228 driving your tape changer hardware from the vendor of the changer
229 hardware and of the operating system, rather than from the Amanda
230 mailing lists. We usually don't have much to say about tape changer
231 units, and several questions about them remain unanswered. :-(
233 Anyway, if you decide to post a question, make sure you specify
234 both the tape changer hardware *and* the OS/platform that is going to
235 interface with it. Good luck! :-)
238 Q: Should I use software or hardware compression?
240 A: When you enable software compression, you drastically reduce the
241 compression that might be achieved by hardware. In fact, tape drives
242 will usually use *more* tape if you tell them to try to further
243 compress already compressed data.
245 Thus, you must choose whether you're going to use software or
246 hardware compression; don't ever enable both unless you want to waste
249 Since Amanda prefers to have complete information about tape sizes
250 and compression rates, it can do a better job if you use software
251 compression. However, if you can't afford the extra CPU usage, Amanda
252 can live with the unpredictability of hardware compression, but you'll
253 have to be very conservative about the specified tape size, specially
254 if there are filesystems that contain mostly uncompressible data.
257 Q: How can I configure Amanda so that it performs full backups on the
258 week-end and incrementals on weekdays?
260 A: You can't. Amanda doesn't work this way. You just have to tell
261 Amanda how many tapes you have (tapecycle), and how often you want it
262 to perform full backups of each filesystem (dumpcycle). If you don't
263 run it once a daily (including Saturdays and Sundays :-), you'll also
264 want to tell Amanda how many times you'll run it per dumpcycle
265 (runspercycle). It will spread full backups along the dumpcycle, so
266 you won't have any full-only or incremental-only runs.
269 Q: What if my tape unit uses expensive tapes, and I don't want to use
270 one tape per day? Can't Amanda append to tapes?
272 A: It can't, and this is good. Tape drives and OS drivers are
273 (in)famous for rewinding tapes at unexpected times, without telling
274 the program that's writing to them. If you have a month's worth of
275 backups in that tape, you really don't want them to be overwritten, so
276 Amanda has taken the safe approach of requiring tapes to be written
277 from the beginning on every run.
279 This can be wasteful, specially if you have a small amount of data
280 to back up, but expensive large-capacity tapes. One possible approach
281 is to run amdump with tapes only, say once a week, to perform full
282 backups, and run it without tape on the other days, so that it
283 performs incremental backups and stores them in the holding disk.
284 Once or twice a week, you flush all backups in the holding disk to a
287 If you don't trust your holding disk, and you'd rather have all
288 your data on tapes daily, you can create an alternate configuration,
289 with two tapes, that backs up the holding disk only, always as a full
290 backup. You'd run this configuration always after your regular
291 backup, so you always have a complete image of the holding disk on
292 tape, just in case it fails.
295 Q: How can I configure Amanda for long-term archiving?
297 A: The best approach is to create a separate configuration for your
298 archive backups. It should use a separate set of tapes, and have all
299 dumptypes configured with `record no', so it doesn't interfere with
303 Q: Can I backup separate disks of the same host in different
306 A: Yes, but you have to be careful. Amanda uses UDP to issue estimate
307 and backup requests and, although replies to backup requests are
308 immediate (so that TCP connections for the actual backup can be
309 established), replies to estimate requests are not and, while one
310 request is being processed, any other request is ignored. The effect
311 is two-fold: (i) if another configuration requests for estimates, the
312 request will be ignored, and the requester will end up timing out;
313 (ii) if another configuration has already finished the estimates, and
314 is now requesting for backups, the backup requests will time-out.
316 So, there are two easy ways out: (i) ensure that the configurations
317 never run concurrently, or (ii) set up two different installations of
318 the Amanda server, using different services names to contact the
319 clients, i.e., different port numbers. This can be attained with the
320 configure flag --with-testing=<service-suffix>. Yes, the flag name is
321 not appropriate, but so what?
323 If you don't want to set up two installations of Amanda (I agree,
324 it's overkill), but you still want to back up disks of the same host
325 in separate configurations, you can set up Amanda so that one
326 configuration only starts after the first one has already finished its
327 One possible way to work-around this limitation is to start one
328 configuration only after you know the estimates for the first one have
329 already finished (modifying the crontab entries, according to history
330 data). You'll also have to delay the starttime (a dumptype option) of
331 the disks in the first configuration, so that they don't start backing
332 up before the estimates of the second configuration finish.
335 Q: Can Amanda span large filesystems across multiple tapes?
339 This is an open project, looking for developers. If you'd like to
340 help, please take a look at the Amanda Ongoing Projects Page, where
341 more up-to-date information is likely to be found about this project.
343 The current work-around is to use GNU tar to back up subdirectories
344 of the huge filesystem separately. But be aware of the problems
345 listed in the question about `results missing'.
348 Q: What's the difference between option `skip-full' and `strategy nofull'?
350 A: `strategy nofull' is supposed to handle the following situation:
351 you run a full dump off-line once a millenium :-), because that disk
352 isn't supposed to change at all and, if it does, changes are minimal.
353 Amanda will run only level 1 backups of that filesystem, to avoid the
354 risk of overwriting a level 1 backup needed to do a restore.
355 Remember, you run full dumps once a millenium, and your tape cycle
356 probably won't last that long :-)
358 `skip-full', OTOH, is supposed to let the user run full dumps
359 off-line regularly (i.e., as often as specified in the dumpcycle),
360 while Amanda takes care of the incrementals. Currently, Amanda will
361 tell you when you're supposed to run the level 0 backups but, if you
362 fail to do so, Amanda will not only skip a full day's worth of
363 valuable backups of the filesystem, on the day it told you to the full
364 backup manually, but it will also run a level 1 backup on the next
365 day, even if you have not performed the full backup yet. Worse yet:
366 it might perform a level 2 on the next day, just after you have run
367 the level 0, so, if the disk should crash, you'd have to restore a
368 level 0 then a level 2, but not the level 1! Not a real problem, but
369 definitely strange, eh?
372 Q: Why does `amdump' report `results missing'?
374 A: One of the possible reasons is that you have requested too many
375 backups of the host. In this case, the estimate request or the reply
376 may not fit in a UDP packet. This will cause Amanda not to perform
377 some of the backups. Fixing this problem involves modifying the way
378 estimate requests are issued, so that no packet exceeds the maximum
379 packet size, and issuing additional requests that did not fit in a UDP
380 packet after a reply for the previous set is obtained. The
381 probability of getting this problem has been considerably reduced
382 since we increased the maximum UDP packet size from 1Kb to 64Kb, but
383 some operating systems may not support such large packets.
385 One possible work-around is to try to shorten the pathnames of the
386 directories and the exclude file names, so that more requests fit in
387 the UDP packet. You may create short-named links in some directory
388 closer to the root (/) so as to reduce the length of names. I.e.,
389 instead of backing up /usr/home/foo and /usr/home/bar, create the
391 /.foo -> /usr/home/foo
392 /.bar -> /usr/home/bar
393 then list /.foo and /.bar in the disklist.
395 Another approach is to group sub-directories in backup sets,
396 instead of backing up them all separately. For example, create
397 /usr/home/.bkp1 and move `foo' and `bar' into it, then create links so
398 that the original pathnames remain functional. Then, list
399 /usr/home/.bkp1 in the disklist. You may create as many `.bkp<N>'
400 directories as you need.
402 A simpler approach, that may work for you, is to backup only a
403 subset of the subdirectories of a filesystem separately. The others
404 can be backed up together with the root of the filesystem, using an
405 exclude list that prevents duplicate backups.
408 Q: Why does `amdump' report `disk offline'?
410 A: Well, assuming the disk is not really off line :-), it may be a
411 permission problem, but then, `amcheck' would have reported it.
413 Another possible reason for this failure is a filesystem error,
414 that causes DUMP to crash before it estimates the backup size; a
417 Yet another possibility is that the filesystem is so large that the
418 backup program is incorrectly reporting the estimated size, for
419 example, by printing a negative value that Amanda will not accept as a
420 valid estimate. If you are using DUMP, contact your vendor and
421 request a patch for dump that fixes this bug. If you are using GNU
422 tar, make sure it is release 1.12 or newer; 1.11.8 won't do! Even
423 release 1.12 may require a patch to correctly report estimates and
424 dump sizes, as well as to handle sparse files correctly and quickly
425 instead of printing error messages like `Read error at byte 0, reading
426 512 bytes, in file ./var/log/lastlog: Bad file number' in
427 sendsize.debug and being very slow. Check the patches directory of
428 the Amanda distribution.
431 Q: What if `amdump' reports `dumps way too big, must skip incremental
434 A: It means Amanda couldn't back up some disk because it wouldn't fit
435 in the tape(s) you have configured Amanda to use. It considered
436 performing some incrementals instead of full dumps, so that all disks
437 would fit, but this wouldn't be enough, so the disk really had to be
440 In general, you can just ignore this message if it happens only
441 once in a while. Low-priority disks are discarded first, so you'll
442 hardly miss really important data.
444 One real work-around is to configure Amanda to use more tapes:
445 increase `runtapes' in `amanda.conf'. Even if you don't have a real
446 tape changer, you can act yourself as a changer (`chg-manual'; more
447 details in the question about tape changer configuration), or use
448 `chg-multi' with a single tape unit, and lie to Amanda that it will
449 have two tapes to use. If you have a holding disk as large as a tape,
450 and configure Amanda (2.4.1b1 or newer) not to reserve any space for
451 degraded dumps, dumps that would be stored in the second tape of a run
452 will be performed to the holding disk, so you can flush them to tape
456 Q: `amdump' reported `infofile update failed'. What should I do?
458 A: Make sure all directories and files are readable and writable by
459 the Amanda user, within the directory you specified as `infofile' in
460 `amanda.conf'. From then on, only run amanda server commands
461 (amadmin, amdump, amflush, amcleanup) as the Amanda user, not as root.
464 Q: Why does Amanda sometimes promote full dumps?
466 A: To spread the full dumps along the dumpcycle, so that daily runs
467 take roughtly the same amount of tape and time. As soon as you start
468 using Amanda, it will run full dumps of all filesystems. Then, on the
469 following runs, it will promote some backups, so as to adjust the
470 balance. After one or two dumpcycles, it should stop promoting dumps.
471 You can see how well it is doing with `amadmin <conf> balance'. If
472 you find the results surprising, you may want to adjust dumpcycle or
476 Q: Why does `amrecover' report `no index records' or `disk not found'?
478 A: The most common cause of this problem is not having enabled index
479 generation in amanda.conf. The `index yes' option must be present in
480 every dumptype for whose disks indexes should be generated.
482 Another possibility is that `amrecover' is not selecting the
483 configuration name that contains the backups for the selected disk.
484 You may specify a configuration name with the `-c' switch, when you
485 invoke `amrecover'. The default configuration name can only be
486 specified at Amanda configure time (--with-config=<name>).
488 Indexes are currently generated at backup-time only, so, if a
489 backup was performed without creating an index, you won't be able to
490 use `amrecover' to restore it, you'll have to use `amrestore'.
493 Q: Ok, I'm done with testing Amanda, now I want to put it in
494 production. How can I reset its databases so as to start from
497 A: First, remove the `curinfo' database. By default, it is a
498 directory, but, if you have selected any other database format (don't,
499 they're deprecated), they may be files with extensions such as .dir
502 Then, remove any log files from the log directory:
503 log.<TIMESTAMP>.<count> and amdump.<count>. Finally, remove the
504 tapelist file, stored in the directory that contains amanda.conf,
505 unless amanda.conf specifies otherwise. Depending on the tape changer
506 you have selected, you may also want to reset its state file.
509 Q: The man-page of DUMP says that active filesystems may be backed up
510 inconsistently. What does Amanda do to prevent inconsistent backups?
512 A: Nothing. When you back up an active filesystem, there are two
515 1) dump may print strange error messages about invalid blocks, then
516 fail; in this case, Amanda will retry the backup on the next run
518 2) files that are modified while dump runs may be backed up
519 inconsistently. But then, they will be included in the next
520 incremental backup, which should usually be enough
522 Large, critical files such as databases should be locked somehow,
523 to avoid inconsistent backups, but there's no direct support for that
524 in Amanda. The best bet is to configure Amanda to use a wrapper to
525 DUMP, that locks and unlocks the database when appropriate.
projects / debian / amanda / blob