-
- Chapter 16. AMANDA FAQ
-Prev Part IV. Various Information Next
-
--------------------------------------------------------------------------------
-
-Chapter 16. AMANDA FAQ
-
-
-AMANDA Core Team
-
-AMANDA Core Team
-
-Stefan G. Weichinger
-
-XML-conversion;Updates
-AMANDA Core Team
-<sgw@amanda.org>
-Table of Contents
-
-
- 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"?
-
- QUESTION:_Why_does_amcheck_claim_that_the_tape_is_"not_an_amanda_tape"?
-
- QUESTION:_Why_does_amcheck_report_"selfcheck_request_timed_out"?
-
- QUESTION:_Why_does_amandad.debug_contain_"error_receiving_message"?
-
- QUESTION:_Why_does_amcheck_say_"access_as_<username>_not_allowed..."?
-
- QUESTION:_Why_does_amcheck_report_"ip_address_#.#.#.#"_is_not_in_the_ip_list
- list_for_<hostname>'?
-
- QUESTION:_Why_does_amcheck_say_"cannot_overwrite_active_tape"?
-
- QUESTION:_Why_does_amcheck_tell_me_"DUMP_program_not_available"?
-
- QUESTION:_Which_tape_changer_configuration_should_I_use_in_amanda.conf?
-
- QUESTION:_Should_I_use_software_or_hardware_compression?
-
- QUESTION:_How_can_I_configure_AMANDA_so_that_it_performs_full_backups_on_the
- week-end_and_incrementals_on_weekdays?
-
- 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?
-
- QUESTION:_How_can_I_configure_AMANDA_for_long-term_archiving?
-
- QUESTION:_Can_I_backup_separate_disks_of_the_same_host_in_different
- configurations?
-
- QUESTION:_Can_AMANDA_span_large_filesystems_across_multiple_tapes?
-
- QUESTION:_What's_the_difference_between_option_"skip-full"_and_"strategy
- nofull"?
-
- QUESTION:_Why_does_amdump_report_"results_missing"?
-
- QUESTION:_Why_does_amdump_report_"disk_offline"?
-
- QUESTION:_What_if_amdump_reports_"dumps_way_too_big,_must_skip_incremental
- dumps"?
-
- QUESTION:_amdump_reported_"infofile_update_failed"._What_should_I_do?
-
- QUESTION:_Why_does_AMANDA_sometimes_promote_full_dumps?
-
- QUESTION:_Why_does_amrecover_report_"no_index_records"_or_"disk_not_found"?
-
- 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?
-
- QUESTION:_The_man-page_of_dump_says_that_active_filesystems_may_be_backed_up
- inconsistently._What_does_AMANDA_do_to_prevent_inconsistent_backups?
-
- QUESTION:_Which_version_of_GNU-tar_should_I_use?
-
-
-Note
-
-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 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."
-
--------------------------------------------------------------------------------
-
-Prev Up Next
-Chapter 15. Using AMANDA Home Chapter 17. Collection of the top ten AMANDA
- questions. And answers.
-
projects / debian / amanda / blobdiff