- Chapter 16. AMANDA FAQ
+ Chapter 17. AMANDA FAQ
Prev Part IV. Various Information Next
-------------------------------------------------------------------------------
-Chapter 16. AMANDA FAQ
+Chapter 17. AMANDA FAQ
AMANDA Core Team
XML-conversion;Updates
AMANDA Core Team
<sgw@amanda.org>
-Table of Contents
+Note
- QUESTION:_Why_does_AMANDA_fail_to_build_on_my_system?
-
- QUESTION:_Why_does_amdump_report_that_all_disks_failed?
-
- QUESTION:_Why_does_amcheck_say_"port_NNN_is_not_secure"?
+Refer to http://www.amanda.org/docs/faq.html for the current version of this
+document.
+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 mailto://amanda-
+users@amanda.org or mailto://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.
- QUESTION:_Why_does_amcheck_claim_that_the_tape_is_"not_an_amanda_tape"?
- QUESTION:_Why_does_amcheck_report_"selfcheck_request_timed_out"?
+ Why_does_AMANDA_fail_to_build_on_my_system?
- QUESTION:_Why_does_amandad.debug_contain_"error_receiving_message"?
+ Why_does_amdump_report_that_all_disks_failed?
- QUESTION:_Why_does_amcheck_say_"access_as_<username>_not_allowed..."?
+ Why_does_amcheck_say_"port_NNN_is_not_secure"?
- QUESTION:_Why_does_amcheck_report_"ip_address_#.#.#.#"_is_not_in_the_ip_list
- list_for_<hostname>'?
+ Why_does_amcheck_claim_that_the_tape_is_"not_an_AMANDA_tape"?
- QUESTION:_Why_does_amcheck_say_"cannot_overwrite_active_tape"?
+ Why_does_amcheck_report_"selfcheck_request_timed_out"?
- QUESTION:_Why_does_amcheck_tell_me_"DUMP_program_not_available"?
+ Why_does_amandad.debug_contain_"error_receiving_message"?
- QUESTION:_Which_tape_changer_configuration_should_I_use_in_amanda.conf?
+ Why_does_amcheck_say_"access_as_<username>_not_allowed..."?
- QUESTION:_Should_I_use_software_or_hardware_compression?
+ Why_does_amcheck_report_"ip_address_#.#.#.#"_is_not_in_the_ip_list_list_for
+ <hostname>'?
- QUESTION:_How_can_I_configure_AMANDA_so_that_it_performs_full_backups_on_the
- week-end_and_incrementals_on_weekdays?
+ Why_does_amcheck_say_"cannot_overwrite_active_tape"?
- QUESTION:_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?
+ Why_does_amcheck_tell_me_"DUMP_program_not_available"?
- QUESTION:_How_can_I_configure_AMANDA_for_long-term_archiving?
+ Which_tape_changer_configuration_should_I_use_in_amanda.conf?
- QUESTION:_Can_I_backup_separate_disks_of_the_same_host_in_different
- configurations?
+ Should_I_use_software_or_hardware_compression?
- QUESTION:_Can_AMANDA_span_large_filesystems_across_multiple_tapes?
+ How_can_I_configure_AMANDA_so_that_it_performs_full_backups_on_the_week-end
+ and_incrementals_on_weekdays?
- QUESTION:_What's_the_difference_between_option_"skip-full"_and_"strategy
- nofull"?
+ 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?
- QUESTION:_Why_does_amdump_report_"results_missing"?
+ How_can_I_configure_AMANDA_for_long-term_archiving?
- QUESTION:_Why_does_amdump_report_"disk_offline"?
+ Can_I_backup_separate_disks_of_the_same_host_in_different_configurations?
- QUESTION:_What_if_amdump_reports_"dumps_way_too_big,_must_skip_incremental
- dumps"?
+ Can_AMANDA_span_large_filesystems_across_multiple_tapes?
- QUESTION:_amdump_reported_"infofile_update_failed"._What_should_I_do?
+ What's_the_difference_between_option_"skip-full"_and_"strategy_nofull"?
- QUESTION:_Why_does_AMANDA_sometimes_promote_full_dumps?
+ Why_does_amdump_report_"results_missing"?
- QUESTION:_Why_does_amrecover_report_"no_index_records"_or_"disk_not_found"?
+ Why_does_amdump_report_"disk_offline"?
- QUESTION:_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?
+ What_if_amdump_reports_"dumps_way_too_big,_must_skip_incremental_dumps"?
- QUESTION:_The_man-page_of_dump_says_that_active_filesystems_may_be_backed_up
- inconsistently._What_does_AMANDA_do_to_prevent_inconsistent_backups?
+ amdump_reported_"infofile_update_failed"._What_should_I_do?
- QUESTION:_Which_version_of_GNU-tar_should_I_use?
+ Why_does_AMANDA_sometimes_promote_full_dumps?
+ Why_does_amrecover_report_"no_index_records"_or_"disk_not_found"?
-Note
+ 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?
-Refer to http://www.amanda.org/docs/faq.html for the current version of this
-document.
-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 mailto://amanda-
-users@amanda.org or mailto://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.
+ The_man-page_of_dump_says_that_active_filesystems_may_be_backed_up
+ inconsistently._What_does_AMANDA_do_to_prevent_inconsistent_backups?
- QUESTION: Why does AMANDA fail to build on my system?
-
-ANSWER: 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 AMANDA_2.4.x_-_System-Specific_Installation
-Notes, as well as to the AMANDA Patches Page (http://www.amanda.org/patches/
-) 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 (mailto://amanda-users@amanda.org), showing the last few lines of
-the failed build.
-
- QUESTION: Why does amdump report that all disks failed?
-
-ANSWER: 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.
-
- QUESTION: Why does amcheck say "port NNN is not secure"?
-
-ANSWER: 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 chown u+s them again, if chown drops the setuid bit.
-
- QUESTION: Why does amcheck claim that the tape is "not an amanda tape"?
-
-ANSWER: 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.
-
- QUESTION: Why does amcheck report "selfcheck request timed out"?
-
-ANSWER: 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 in
-the Amanda_Installation_Notes for details. Check the inetd man-page for
-possible differences between the standard format of /etc/inetd.conf and the one
-in your system.
-Pay special attention to typos in /etc/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 (configure --with-user=<USERNAME>) is listed in /etc/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 /etc/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.
-
- QUESTION: Why does amandad.debug contain "error receiving message"?
-
-ANSWER: 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 /etc/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.
-
- QUESTION: Why does amcheck say "access as <username> not allowed..."?
-
-ANSWER: 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.
-
- QUESTION: Why does amcheck report "ip address #.#.#.#" is not in the ip list
-list for <hostname>'?
-
-ANSWER: 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.
-
- QUESTION: Why does amcheck say "cannot overwrite active tape"?
-
-ANSWER: 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.
-
- QUESTION: Why does amcheck tell me "DUMP program not available"?
-
-ANSWER: Because 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.
-
- QUESTION: Which tape changer configuration should I use in amanda.conf?
-
-ANSWER: 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 AMANDA_Tape_Changer_Support 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! :-)
-
- QUESTION: Should I use software or hardware compression?
-
-ANSWER: 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.
-
- QUESTION: How can I configure AMANDA so that it performs full backups on the
-week-end and incrementals on weekdays?
-
-ANSWER: 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.
-Please also refer to "the friday-tape-question" in Collection_of_the_top_ten
-AMANDA_questions._And_answers..
-
- QUESTION: 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?
-
-ANSWER: 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.
-
- QUESTION: How can I configure AMANDA for long-term archiving?
-
-ANSWER: 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.
-
- QUESTION: Can I backup separate disks of the same host in different
-configurations?
-
-ANSWER: 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>i. 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.
-
- QUESTION: Can AMANDA span large filesystems across multiple tapes?
-
-ANSWER: 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 (http://www.amanda.org/
-ongoing.php), where more up-to-date information is likely to be found about
-this project.
-Update September 2004: Refer to the archive of the amanda-hackers mailinglist
-(http://marc.theaimsgroup.com/?l=amanda-hackers). A patch by John Stange is
-being discussed there, which allows splitting and spanning.
-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".
-
- QUESTION: What's the difference between option "skip-full" and "strategy
-nofull"?
-
-ANSWER: "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?
-
- QUESTION: Why does amdump report "results missing"?
-
-ANSWER: 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.
-
- QUESTION: Why does amdump report "disk offline"?
-
-ANSWER: 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.
-
- QUESTION: What if amdump reports "dumps way too big, must skip incremental
-dumps"?
-
-ANSWER: 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.
-
- QUESTION: amdump reported "infofile update failed". What should I do?
-
-ANSWER: 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.
-
- QUESTION: Why does AMANDA sometimes promote full dumps?
-
-ANSWER: To spread the full dumps along the dumpcycle, so that daily runs take
-roughly 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.
-
- QUESTION: Why does amrecover report "no index records" or "disk not found"?
-
-ANSWER: 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 (configure --
-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.
-
- QUESTION: 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?
-
-ANSWER: 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.
-
- QUESTION: The man-page of dump says that active filesystems may be backed up
-inconsistently. What does AMANDA do to prevent inconsistent backups?
-
-ANSWER: Nothing. When you back up an active filesystem, there are two
-possibilities:
-dump may print strange error messages about invalid blocks, then fail; in this
-case, AMANDA will retry the backup on the next run.
-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.
-
- QUESTION: Which version of GNU-tar should I use?
-
-ANSWER: (slightly adapted from a posting by Paul Bijnens
-<paul.bijnens@xplanation.com>, Mon, 11 Apr 2005):
-
-* 1.13.19 is good.
- However it still sets return code 2 for some infrequent conditions even with
- --ignore-failed-read option. This results in AMANDA thinking the total
- archive is bad, and drops the complete archive. Those conditions are very
- rare on a quiet filesystem.
-* 1.13.25 is good: no problems found (yet).
-* 1.13.9x is not good.
- It has changed the format of "tar -t", resulting in amrecover not able to use
- the indexes.
-* 1.14.x is not good.
- It writes good archives, but when restoring, it has trouble with sparse
- files; the sparse file itself, and *all* files after it cannot be read
- anymore. But you can read the archive with a good tar version (i.e. the tar
- images produced are fine).
-* 1.15.1 is good: no problems found (yet).
- Paul Bijnens: "I'm using this version on most of my clients since january
- this year (2005), and have already done successful restore too."
+ Which_version_of_GNU-tar_should_I_use?
+
+ What_does_"bumping"bumping_mean?
+
+ How_do_I_backup_a_Windows_server?
+
+
+ Why does AMANDA fail to build on my system?
+ 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 AMANDA_2.4.x_-_System-Specific
+ Installation_Notes, as well as to the AMANDA Patches Page (http://
+ www.amanda.org/patches/) 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 (mailto://amanda-users@amanda.org),
+ showing the last few lines of the failed build.
+ Why does amdump report that all disks failed?
+ 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.
+ Why does amcheck say "port NNN is not secure"?
+ 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 chown u+s them again, if chown drops the setuid bit.
+ Why does amcheck claim that the tape is "not an AMANDA tape"?
+ 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.
+ Why does amcheck report "selfcheck request timed out"?
+ 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 in the Amanda_Installation_Notes for details. Check the inetd man-page
+ for possible differences between the standard format of /etc/inetd.conf and
+ the one in your system.
+ Pay special attention to typos in /etc/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 (configure --with-user=<USERNAME>) is listed in /
+ etc/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 /etc/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.
+ Why does amandad.debug contain "error receiving message"?
+ 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 /etc/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.
+ Why does amcheck say "access as <username> not allowed..."?
+ 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.
+ Why does amcheck report "ip address #.#.#.#" is not in the ip list list for
+ <hostname>'?
+ 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.
+ Why does amcheck say "cannot overwrite active tape"?
+ 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.
+ Why does amcheck tell me "DUMP program not available"?
+ Because 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.
+ Which tape changer configuration should I use in amanda.conf?
+ 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
+ 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 AMANDA_Tape_Changer_Support 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! :-)
+ Should I use software or hardware compression?
+ 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.
+ How can I configure AMANDA so that it performs full backups on the week-end
+ and incrementals on weekdays?
+ 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.
+ Please also refer to "the friday-tape-question" in Collection_of_the_top_ten
+ AMANDA_questions._And_answers..
+ 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?
+ 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.
+ How can I configure AMANDA for long-term archiving?
+ 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.
+ Can I backup separate disks of the same host in different configurations?
+ 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>i.
+ 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.
+ Can AMANDA span large filesystems across multiple tapes?
+ 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 (http://www.amanda.org/
+ ongoing.php), where more up-to-date information is likely to be found about
+ this project.
+ Update September 2004: Refer to the archive of the amanda-hackers mailinglist
+ (http://marc.theaimsgroup.com/?l=amanda-hackers). A patch by John Stange is
+ being discussed there, which allows splitting and spanning.
+ 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".
+ What's the difference between option "skip-full" and "strategy nofull"?
+ "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?
+ Why does amdump report "results missing"?
+ 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.
+ Why does amdump report "disk offline"?
+ 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.
+ What if amdump reports "dumps way too big, must skip incremental dumps"?
+ 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.
+ amdump reported "infofile update failed". What should I do?
+ 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.
+ Why does AMANDA sometimes promote full dumps?
+ To spread the full dumps along the dumpcycle, so that daily runs take roughly
+ 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.
+ Why does amrecover report "no index records" or "disk not found"?
+ 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
+ (configure --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.
+ 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?
+ 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.
+ The man-page of dump says that active filesystems may be backed up
+ inconsistently. What does AMANDA do to prevent inconsistent backups?
+ Nothing. When you back up an active filesystem, there are two possibilities:
+ dump may print strange error messages about invalid blocks, then fail; in this
+ case, AMANDA will retry the backup on the next run.
+ 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.
+ Which version of GNU-tar should I use?
+ (This answer was slightly adapted from a posting by Paul Bijnens
+ <paul.bijnens@xplanation.com>, Mon, 11 Apr 2005):
+
+ * 1.13.19 is good.
+ However it still sets return code 2 for some infrequent conditions even with
+ --ignore-failed-read option. This results in AMANDA thinking the total
+ archive is bad, and drops the complete archive. Those conditions are very
+ rare on a quiet filesystem.
+ * 1.13.25 is good: no problems found (yet).
+ * 1.13.9x is not good.
+ It has changed the format of "tar -t", resulting in amrecover not able to
+ use the indexes.
+ * 1.14.x is not good.
+ It writes good archives, but when restoring, it has trouble with sparse
+ files; the sparse file itself, and *all* files after it cannot be read
+ anymore. But you can read the archive with a good tar version (i.e. the tar
+ images produced are fine).
+ * 1.15.1 is good: no problems found (yet).
+ Paul Bijnens: "I'm using this version on most of my clients since january
+ this year (2005), and have already done successful restore too."
+
+ What does "bumping" mean?
+ The term "bumping" is used to describe the change from one backup-level to the
+ next higher level. If AMANDA changes from Level 0 to Level 1 for a specific
+ DLE, it "bumps".
+ The basic goal of "bumping" is to save precious space on the backup media as
+ higher level incremental backups are smaller in size than lower level
+ incremental backups.
+ The disadvantage of increasing backup levels is the fact that restoring from
+ higher level incremental backups needs more tapes. This increases the amount
+ of work time that are needed to fully restore a DLE as well as the possibility
+ of tape-errors and similar problems during the process of restore. So in
+ general it is recommended to keep the levels as low as possible with the given
+ hardware and data.
+ There are various amanda.conf parameters to control and fine-tune AMANDA's
+ behavior when it comes to "bumping":
+ Please refer to the amanda-manpage and the example amanda.conf for details on
+ the parameters bumppercent, bumpsize, bumpdays and bumpmult.
+ How do I backup a Windows server?
+ AMANDA is able to use smbclient to dump SMB/CIFS-shares. Refer to the Backup
+ PC_hosts_using_Samba for details.
-------------------------------------------------------------------------------
Prev Up Next
-Chapter 15. Using AMANDA Home Chapter 17. Collection of the top ten AMANDA
+Chapter 16. Using AMANDA Home Chapter 18. Collection of the top ten AMANDA
questions. And answers.
projects / debian / amanda / blobdiff