+++ /dev/null
-This file contains answers to some questions that are frequently asked
-in the Amanda mailing lists, specially by new users. Please take a
-look at this file before posting, this can save us time that could be
-spent improving Amanda and its documentation.
-
-New entries and modifications are welcome; send them to
-amanda-users@amanda.org or amanda-hackers@amanda.org.
-
-You may also want to take a look at the Amanda FAQ-O-Matic
-http://www.amanda.org/fom-serve/cache/1.html
-
-
-Q: Why does Amanda fail to build on my system?
-
-A: One of the most common reasons for compile-time errors is stale
-information in `config.cache', after a build on a different platform
-using the same build tree. In order to avoid this problem, make sure
-you don't ever reuse build trees across platforms, or at least run
-`make distclean' before running `configure' on another platform.
-
- Another common reason for failure, that causes link-time errors, is
-a problem in libtool that causes it to search for symbols in
-already-installed amanda libraries, instead of in the just-built ones.
-This problem is known to affect SunOS 4.1.3 and FreeBSD. You can
-usually work around it by specifying a different prefix when you
-configure the new version of Amanda. However, it may not work if the
-previous version of Amanda was installed in /usr/local and gcc
-searches this directory by default; in this case, you must either
-remove the old libraries (which you don't want to do, right? :-) or
-call configure with the flag --disable-libtool. In this case, Amanda
-won't create shared libraries, so binaries will be larger, but you may
-worry about that later.
-
- You may also want to take a look at docs/SYSTEM.NOTES, as well as
-to the Amanda Patches Page (check www.amanda.org) for other known
-problems. If everything fails, you should read the manual, but since
-we don't have one yet, just post a help request to the amanda-users
-mailing list, showing the last few lines of the failed build.
-
-
-Q: Why does `amdump' report that all disks failed?
-
-A: Probably because the Amanda clients are not properly configured.
-Before you ever run `amdump', make sure `amcheck' succeeds. When it
-does, so should `amdump'.
-
- Make sure you run `amcheck' as the same user that is supposed to
-start `amdump', otherwise you may get incorrect results.
-
-
-Q: Why does `amcheck' say `port NNN is not secure'?
-
-A: Because `amcheck', as some other Amanda programs, must be installed
-as setuid-root. Run `make install' as `root', or `chown' all Amanda
-setuid programs to `root', then `chmod u+s' them again, if `chown'
-drops the setuid bit.
-
-
-Q: Why does `amcheck' claim that the tape is `not an amanda tape'?
-
-A: Because Amanda requires you to label tapes before it uses them.
-Run `amlabel' in order to label a tape.
-
- If, even after labeling a tape, `amcheck' still complains about it,
-make sure the regular expression specified in amanda.conf matches the
-label you have specified, and check whether you have configured
-non-rewinding tape devices for Amanda to use. For example, use
-/dev/nrst0 instead of /dev/rst0, /dev/rmt/0bn instead of /dev/rmt/0b,
-or some other system-dependent device name that contains an `n',
-instead of one that does not. The `n' stands for non-rewinding.
-
- If you have labeled any tapes using the rewiding device
-configuration, you'll have to label them again.
-
-
-Q: Why does `amcheck' report `selfcheck request timed out'?
-
-A: This can occur under several different situations. First, make
-sure this problem is repeatable; if Amanda programs are
-NFS-auto-mounted, some clients may fail to mount the Amanda binaries
-in time.
-
- If the error is repeatable, log into the client, and check whether
-the directory /tmp/amanda exists, and a file named amandad.debug
-exists in there: amandad will create this file whenever it starts. If
-this file does not exist, amandad is not starting properly, or it
-lacks permission to create /tmp/amanda/amandad.debug.
-
- In the latter case, wipe out /tmp/amanda, and amandad should create
-it next time it runs. In the former case, check your inetd
-configuration. Make sure you have added the Amanda services to
-/etc/services (or the NIS services map), that /etc/inetd.conf was
-properly configured, and that you have signalled inetd to reread this
-file (some systems may need rebooting). Check section 2.2 from the
-INSTALL file for details. Check the inetd man-page for possible
-differences between the standard inetd.conf format and the one in your
-system.
-
- Pay special attention to typos in inetd.conf; error messages will
-probably appear in /var/adm/messages or /var/log/messages if you have
-typed the amandad program name incorrectly. Make sure the same user
-that you have specified at configure-time (--with-user=<USERNAME>) is
-listed in inetd.conf. Check whether this user has permission to run
-amandad, as well as any shared libraries amandad depends upon, by
-running the specified amandad command by hand, as the Amanda user. It
-should just time-out after 30 seconds waiting for a UDP packet. If
-you type anything, it will abort immediately, because it can't read a
-UDP packet from the keyboard.
-
- As soon as you have properly configured inetd.conf so as to run
-amandad, you should no longer get the `selfcheck request timed out'
-message. A nice tool to help make sure inetd is really listening on
-the amandad port is lsof, available at
-ftp://vic.cc.purdue.edu/pub/tools/unix/lsof.
-
-
-Q: Why does `amandad.debug' contain `error receiving message'?
-
-A: One possibility is that you have run `amandad' from the command
-line prompt and typed anything instead of waiting for it to time-out:
-in this case, it will try to read a UDP packet from the keyboard, and
-this was reported not to work on most keyboards :-). However, if you
-have run `amandad' as any user other than the one listed in
-`inetd.conf', it may have created a /tmp/amanda directory that the
-Amanda user cannot write to, so you should wipe it out.
-
- Another possibility is that the Amanda service was not properly
-configured as a UDP service; check /etc/services and /etc/inetd.conf.
-
-
-Q: Why does `amcheck' say `access as <username> not allowed...'
-
-A: There must be something wrong with .amandahosts configuration (or
-.rhosts, if you have configured --without-amandahosts).
-
- First, if the <username> is not what you expect (i.e., not what you
-have specified in the --with-user flag, at configure time), check the
-inetd configuration file: you must have specified the wrong username
-there.
-
- Make sure you specify the names exactly as they appear in the error
-message after the `@' sign in .amandahosts/.rhosts. You'll need a
-fully-qualified domain name or not, depending on how your client
-resolves IP addresses to host names.
-
-
-Q: Why does `amcheck' report `ip address #.#.#.# is not in the ip list
-list for <hostname>'?
-
-A: Check your DNS configuration tables. In order to avoid
-DNS-spoofing, Amanda double-checks hostname<->IP address mapping. If
-the IP address the request comes from maps to a hostname, but this
-hostname does not map back to the incoming IP address, the request is
-denied.
-
-
-Q: Why does `amcheck' say `cannot overwrite active tape'?
-
-A: Because, if you configure Amanda to use N tapes, by setting
-tapecycle to N in `amanda.conf', before Amanda overwrites a tape, it
-must write to at least other N-1 tapes. Of course, Amanda will always
-refuse to overwrite a tape marked for `noreuse' with `amadmin'.
-Furthermore, such tapes are not counted when Amanda computes `N-1'
-tapes.
-
- If, for some reason, you want to tell Amanda to overwrite a
-particular tape, regardless of its position in the cycle, use
-`amrmtape'. This command will remove this tape from the `tapelist'
-file, that is used to manage the tape cycle, and will delete
-information about backups stored in that tape from the Amanda
-database.
-
-
-Q: Why does `amcheck' tell me `DUMP program not available'?
-
-A: Because the `configure' could not find DUMP when it was first run.
-This is a common problem on Linux hosts, because most Linux
-distributions do not install DUMP by default.
-
- If you don't have a DUMP program installed, install it, remove
-`config.cache', run `configure' again and rebuild Amanda. While
-`configure' is running, make sure it can find the installed DUMP
-program. If it cannot, you may have to set the environment variables
-DUMP and RESTORE by hand, before running configure.
-
- If you can't or don't want to install DUMP, you may use GNU tar,
-but make sure it as release 1.12 or newer; release 1.11.8 may work,
-but estimates will be slow as hell.
-
-
-Q: Which tape changer configuration should I use in amanda.conf?
-
-A: If you only have one tape unit, you have two choices: (i) don't use
-a tape changer at all, i.e., set runtapes to 1, set tapedev to the
-non-rewinding device corresponding to the tape unit, and comment out
-tpchanger, changerfile and changerdev; or (ii) set up chg-manual, so
-that you can change tapes manually. If you select chg-manual, you
-will not be able to start `amdump' as a cron job, and you should
-always run `amflush -f', because chg-manual will ask you to press
-return in the terminal where you started the controlling program.
-
- If you have several tape units, which you want to use to emulate a
-tape changer, you want chg-multi. Even if you do own a real tape
-changer, that operates based on ejecting a tape or such, chg-multi may
-be useful.
-
- Actual tape changers usually require specialized changer programs,
-such as `mtx', `chio' or specific system calls. The availability of
-these programs is much more dependent on the operating system you're
-running than on the particular tape changer hardware you have.
-
- `mtx', for example, is available for several platforms. However,
-even if you find it for your platform, beware that there exist several
-different programs named `mtx', that require different command line
-arguments, and print different output, and Amanda's chg-mtx does not
-support them all. You may have to edit the script, which shouldn't be
-hard to do.
-
- In section BUILT-IN TAPE CHANGERS of docs/TAPE.CHANGERS, you will
-find details about the tape changer interfacing programs provided with
-Amanda, that can interact with common tape changer programs and with
-tape changer-related system calls provided by some operating system.
-If none of them matches your needs, you may have to develop your own
-tape changer interface script.
-
- Before posting a question to the Amanda mailing lists, *please*
-search the archives, and try to obtain as much information about
-driving your tape changer hardware from the vendor of the changer
-hardware and of the operating system, rather than from the Amanda
-mailing lists. We usually don't have much to say about tape changer
-units, and several questions about them remain unanswered. :-(
-
- Anyway, if you decide to post a question, make sure you specify
-both the tape changer hardware *and* the OS/platform that is going to
-interface with it. Good luck! :-)
-
-
-Q: Should I use software or hardware compression?
-
-A: When you enable software compression, you drastically reduce the
-compression that might be achieved by hardware. In fact, tape drives
-will usually use *more* tape if you tell them to try to further
-compress already compressed data.
-
- Thus, you must choose whether you're going to use software or
-hardware compression; don't ever enable both unless you want to waste
-tape space.
-
- Since Amanda prefers to have complete information about tape sizes
-and compression rates, it can do a better job if you use software
-compression. However, if you can't afford the extra CPU usage, Amanda
-can live with the unpredictability of hardware compression, but you'll
-have to be very conservative about the specified tape size, specially
-if there are filesystems that contain mostly uncompressible data.
-
-
-Q: How can I configure Amanda so that it performs full backups on the
-week-end and incrementals on weekdays?
-
-A: You can't. Amanda doesn't work this way. You just have to tell
-Amanda how many tapes you have (tapecycle), and how often you want it
-to perform full backups of each filesystem (dumpcycle). If you don't
-run it once a daily (including Saturdays and Sundays :-), you'll also
-want to tell Amanda how many times you'll run it per dumpcycle
-(runspercycle). It will spread full backups along the dumpcycle, so
-you won't have any full-only or incremental-only runs.
-
-
-Q: What if my tape unit uses expensive tapes, and I don't want to use
-one tape per day? Can't Amanda append to tapes?
-
-A: It can't, and this is good. Tape drives and OS drivers are
-(in)famous for rewinding tapes at unexpected times, without telling
-the program that's writing to them. If you have a month's worth of
-backups in that tape, you really don't want them to be overwritten, so
-Amanda has taken the safe approach of requiring tapes to be written
-from the beginning on every run.
-
- This can be wasteful, specially if you have a small amount of data
-to back up, but expensive large-capacity tapes. One possible approach
-is to run amdump with tapes only, say once a week, to perform full
-backups, and run it without tape on the other days, so that it
-performs incremental backups and stores them in the holding disk.
-Once or twice a week, you flush all backups in the holding disk to a
-single tape.
-
- If you don't trust your holding disk, and you'd rather have all
-your data on tapes daily, you can create an alternate configuration,
-with two tapes, that backs up the holding disk only, always as a full
-backup. You'd run this configuration always after your regular
-backup, so you always have a complete image of the holding disk on
-tape, just in case it fails.
-
-
-Q: How can I configure Amanda for long-term archiving?
-
-A: The best approach is to create a separate configuration for your
-archive backups. It should use a separate set of tapes, and have all
-dumptypes configured with `record no', so it doesn't interfere with
-regular backups.
-
-
-Q: Can I backup separate disks of the same host in different
-configurations?
-
-A: Yes, but you have to be careful. Amanda uses UDP to issue estimate
-and backup requests and, although replies to backup requests are
-immediate (so that TCP connections for the actual backup can be
-established), replies to estimate requests are not and, while one
-request is being processed, any other request is ignored. The effect
-is two-fold: (i) if another configuration requests for estimates, the
-request will be ignored, and the requester will end up timing out;
-(ii) if another configuration has already finished the estimates, and
-is now requesting for backups, the backup requests will time-out.
-
- So, there are two easy ways out: (i) ensure that the configurations
-never run concurrently, or (ii) set up two different installations of
-the Amanda server, using different services names to contact the
-clients, i.e., different port numbers. This can be attained with the
-configure flag --with-testing=<service-suffix>. Yes, the flag name is
-not appropriate, but so what?
-
- If you don't want to set up two installations of Amanda (I agree,
-it's overkill), but you still want to back up disks of the same host
-in separate configurations, you can set up Amanda so that one
-configuration only starts after the first one has already finished its
-One possible way to work-around this limitation is to start one
-configuration only after you know the estimates for the first one have
-already finished (modifying the crontab entries, according to history
-data). You'll also have to delay the starttime (a dumptype option) of
-the disks in the first configuration, so that they don't start backing
-up before the estimates of the second configuration finish.
-
-
-Q: Can Amanda span large filesystems across multiple tapes?
-
-A: Not yet :-(
-
- This is an open project, looking for developers. If you'd like to
-help, please take a look at the Amanda Ongoing Projects Page, where
-more up-to-date information is likely to be found about this project.
-
- The current work-around is to use GNU tar to back up subdirectories
-of the huge filesystem separately. But be aware of the problems
-listed in the question about `results missing'.
-
-
-Q: What's the difference between option `skip-full' and `strategy nofull'?
-
-A: `strategy nofull' is supposed to handle the following situation:
-you run a full dump off-line once a millenium :-), because that disk
-isn't supposed to change at all and, if it does, changes are minimal.
-Amanda will run only level 1 backups of that filesystem, to avoid the
-risk of overwriting a level 1 backup needed to do a restore.
-Remember, you run full dumps once a millenium, and your tape cycle
-probably won't last that long :-)
-
- `skip-full', OTOH, is supposed to let the user run full dumps
-off-line regularly (i.e., as often as specified in the dumpcycle),
-while Amanda takes care of the incrementals. Currently, Amanda will
-tell you when you're supposed to run the level 0 backups but, if you
-fail to do so, Amanda will not only skip a full day's worth of
-valuable backups of the filesystem, on the day it told you to the full
-backup manually, but it will also run a level 1 backup on the next
-day, even if you have not performed the full backup yet. Worse yet:
-it might perform a level 2 on the next day, just after you have run
-the level 0, so, if the disk should crash, you'd have to restore a
-level 0 then a level 2, but not the level 1! Not a real problem, but
-definitely strange, eh?
-
-
-Q: Why does `amdump' report `results missing'?
-
-A: One of the possible reasons is that you have requested too many
-backups of the host. In this case, the estimate request or the reply
-may not fit in a UDP packet. This will cause Amanda not to perform
-some of the backups. Fixing this problem involves modifying the way
-estimate requests are issued, so that no packet exceeds the maximum
-packet size, and issuing additional requests that did not fit in a UDP
-packet after a reply for the previous set is obtained. The
-probability of getting this problem has been considerably reduced
-since we increased the maximum UDP packet size from 1Kb to 64Kb, but
-some operating systems may not support such large packets.
-
- One possible work-around is to try to shorten the pathnames of the
-directories and the exclude file names, so that more requests fit in
-the UDP packet. You may create short-named links in some directory
-closer to the root (/) so as to reduce the length of names. I.e.,
-instead of backing up /usr/home/foo and /usr/home/bar, create the
-following links:
- /.foo -> /usr/home/foo
- /.bar -> /usr/home/bar
-then list /.foo and /.bar in the disklist.
-
- Another approach is to group sub-directories in backup sets,
-instead of backing up them all separately. For example, create
-/usr/home/.bkp1 and move `foo' and `bar' into it, then create links so
-that the original pathnames remain functional. Then, list
-/usr/home/.bkp1 in the disklist. You may create as many `.bkp<N>'
-directories as you need.
-
- A simpler approach, that may work for you, is to backup only a
-subset of the subdirectories of a filesystem separately. The others
-can be backed up together with the root of the filesystem, using an
-exclude list that prevents duplicate backups.
-
-
-Q: Why does `amdump' report `disk offline'?
-
-A: Well, assuming the disk is not really off line :-), it may be a
-permission problem, but then, `amcheck' would have reported it.
-
- Another possible reason for this failure is a filesystem error,
-that causes DUMP to crash before it estimates the backup size; a
-`fsck' may help.
-
- Yet another possibility is that the filesystem is so large that the
-backup program is incorrectly reporting the estimated size, for
-example, by printing a negative value that Amanda will not accept as a
-valid estimate. If you are using DUMP, contact your vendor and
-request a patch for dump that fixes this bug. If you are using GNU
-tar, make sure it is release 1.12 or newer; 1.11.8 won't do! Even
-release 1.12 may require a patch to correctly report estimates and
-dump sizes, as well as to handle sparse files correctly and quickly
-instead of printing error messages like `Read error at byte 0, reading
-512 bytes, in file ./var/log/lastlog: Bad file number' in
-sendsize.debug and being very slow. Check the patches directory of
-the Amanda distribution.
-
-
-Q: What if `amdump' reports `dumps way too big, must skip incremental
-dumps'?
-
-A: It means Amanda couldn't back up some disk because it wouldn't fit
-in the tape(s) you have configured Amanda to use. It considered
-performing some incrementals instead of full dumps, so that all disks
-would fit, but this wouldn't be enough, so the disk really had to be
-dropped in this run.
-
- In general, you can just ignore this message if it happens only
-once in a while. Low-priority disks are discarded first, so you'll
-hardly miss really important data.
-
- One real work-around is to configure Amanda to use more tapes:
-increase `runtapes' in `amanda.conf'. Even if you don't have a real
-tape changer, you can act yourself as a changer (`chg-manual'; more
-details in the question about tape changer configuration), or use
-`chg-multi' with a single tape unit, and lie to Amanda that it will
-have two tapes to use. If you have a holding disk as large as a tape,
-and configure Amanda (2.4.1b1 or newer) not to reserve any space for
-degraded dumps, dumps that would be stored in the second tape of a run
-will be performed to the holding disk, so you can flush them to tape
-in the morning.
-
-
-Q: `amdump' reported `infofile update failed'. What should I do?
-
-A: Make sure all directories and files are readable and writable by
-the Amanda user, within the directory you specified as `infofile' in
-`amanda.conf'. From then on, only run amanda server commands
-(amadmin, amdump, amflush, amcleanup) as the Amanda user, not as root.
-
-
-Q: Why does Amanda sometimes promote full dumps?
-
-A: To spread the full dumps along the dumpcycle, so that daily runs
-take roughtly the same amount of tape and time. As soon as you start
-using Amanda, it will run full dumps of all filesystems. Then, on the
-following runs, it will promote some backups, so as to adjust the
-balance. After one or two dumpcycles, it should stop promoting dumps.
-You can see how well it is doing with `amadmin <conf> balance'. If
-you find the results surprising, you may want to adjust dumpcycle or
-runspercycle.
-
-
-Q: Why does `amrecover' report `no index records' or `disk not found'?
-
-A: The most common cause of this problem is not having enabled index
-generation in amanda.conf. The `index yes' option must be present in
-every dumptype for whose disks indexes should be generated.
-
- Another possibility is that `amrecover' is not selecting the
-configuration name that contains the backups for the selected disk.
-You may specify a configuration name with the `-c' switch, when you
-invoke `amrecover'. The default configuration name can only be
-specified at Amanda configure time (--with-config=<name>).
-
- Indexes are currently generated at backup-time only, so, if a
-backup was performed without creating an index, you won't be able to
-use `amrecover' to restore it, you'll have to use `amrestore'.
-
-
-Q: Ok, I'm done with testing Amanda, now I want to put it in
-production. How can I reset its databases so as to start from
-scratch?
-
-A: First, remove the `curinfo' database. By default, it is a
-directory, but, if you have selected any other database format (don't,
-they're deprecated), they may be files with extensions such as .dir
-and .pag.
-
- Then, remove any log files from the log directory:
-log.<TIMESTAMP>.<count> and amdump.<count>. Finally, remove the
-tapelist file, stored in the directory that contains amanda.conf,
-unless amanda.conf specifies otherwise. Depending on the tape changer
-you have selected, you may also want to reset its state file.
-
-
-Q: The man-page of DUMP says that active filesystems may be backed up
-inconsistently. What does Amanda do to prevent inconsistent backups?
-
-A: Nothing. When you back up an active filesystem, there are two
-possibilities:
-
-1) dump may print strange error messages about invalid blocks, then
-fail; in this case, Amanda will retry the backup on the next run
-
-2) files that are modified while dump runs may be backed up
-inconsistently. But then, they will be included in the next
-incremental backup, which should usually be enough
-
- Large, critical files such as databases should be locked somehow,
-to avoid inconsistent backups, but there's no direct support for that
-in Amanda. The best bet is to configure Amanda to use a wrapper to
-DUMP, that locks and unlocks the database when appropriate.
projects / debian / amanda / blobdiff