--- /dev/null
+
+Chapter 17. Collection of the top ten AMANDA questions. And answers.
+Prev Part IV. Various Information Next
+
+-------------------------------------------------------------------------------
+
+Chapter 17. Collection of the top ten AMANDA questions. And answers.
+
+
+Stefan G. Weichinger
+
+Original text; Conversion to Docbook/XML
+AMANDA Core Team
+<sgw@amanda.org>
+Table of Contents
+
+
+ Reason_for_starting_this_list.
+
+ the_DLE-question
+
+ the_localhost-question
+
+ the_friday-tape-question
+
+ the_multiple-dumps-question
+
+ the_mailing-list-question
+
+ the_distro-question
+
+ the_index-question
+
+ the_tapetype-questions
+
+ the_size-question
+
+ the_GUI-question
+
+ the_holding-disk_question
+
+ ...
+
+
+Note
+
+Refer to http://www.amanda.org/docs/topten.html for the current version of this
+document.
+
+ Reason for starting this list.
+
+Jon LaBadie once wrote to me:
+" I think a good "what is AMANDA", "how is it different", "can I use it in my
+setup", "why is it so different" kinda document is needed to stop the constant
+"how do I put 10 dumps on one tape", or "how do I make AMANDA do full backups
+on saturday and incrementals ..." queries off the list :)) "
+Stefan G. Weichinger
+
+ the DLE-question
+
+A posting from the amanda-users mailing-list (mailto://amanda-users@amanda.org)
+asked:
+"What, please, is a "DLE"? May it mean: Down Loadable Entity ??? Stupid. Do
+Less Errors ??? Stupid again. Hmmmm ..."
+People consulting the amanda-users-mailinglist for the first time often get
+confused by the use of the abbreviation DLE.
+It has become very common for regular mailinglist-participants to use the
+abbreviation DLE, which means in its long form
+DiskList Entry
+A DLE refers to one entry in the disklist of an AMANDA-configuration. General
+usage was to describe them as partitions, or file systems. But in fact they do
+not have to be either. They can be directory trees, or multiple trees, or trees
+with some branches cut off. So the more generic term DLE was coined.
+
+ the localhost-question
+
+People get something like:
+
+ >Amanda Backup Client Hosts Check
+ >--------------------------------
+ >ERROR: localhost: [access as amanda not allowed from
+ >amanda@localhost.localdomain] amandahostsauth failed
+
+and ask "Why?"
+SHORT ANSWER:
+DO NOT USE "localhost" as host entry in your disklist entries (aka DLEs). Use
+the FQDN (Fully Qualified Domain Name) instead.
+In AMANDA-releases newer than 2004-03-22 there is a WARNING issued when you use
+something like "localhost" or localhost.localdomain.net in your disklist.
+Example (applies to Linux, syntax may be different on other systems):
+
+ $ hostname --fqdn
+ oops1.oops.co.at
+
+ $ cat disklist
+ oops1.oops.co.at /root root-tar # do it like this
+ localhost /root root-tar # DON'T DO IT LIKE THIS
+
+GOOD ANSWER (provided by John R. Jackson):
+There are (at least) two things going on here and they should have their own
+question/answer.
+Completely independent of the "localhost" vs. FQDN issue are the people who get
+this message because of any number of problems. Let me reword the error and
+then give some typical goofs:
+
+ ERROR: some.amanda.client: access as amanda not allowed from
+ amanda@some.amanda.server
+ amandahostsauth failed
+
+(error message reformatted here ...)
+The first thing to understand is how to read this message. When it says "access
+as amanda ..." it is telling you the client side ( amandad) is running as user
+"amanda". The "... from amanda@some.amanda.server" part tells you the server
+trying to connect is "some.amanda.server" and the AMANDA command (e.g. amcheck
+or amdump) is running as user "amanda".
+The user names are typically the same on both client and server, but some
+situations use different names and it is important to understand which is
+which. For instance, amrecover connects as root ("... from
+root@some.amanda.server") regardless of what the usual AMANDA user is.
+Potential problems:
+
+* "some.server" is not spelled exactly that way in ~amanda/.amandahosts. A
+ typical error is to not use a fully qualified name (although simple typos
+ happen as well). For instance, this line:
+
+
+ some amanda
+
+does not match "some.amanda.server" even though both names may be equivalent.
+When AMANDA looks up the host name in .amandahosts, it uses the exact name it
+lists in the message. It does not try to look up abbreviations.
+The only exception to this is that the lookup is case insensitive.
+
+* The user name listed in ~amanda/.amandahosts is not the one trying to connect
+ from the server. In particular, watch out for the "root" case listed above
+ for amrecover. The AMANDA server typically needs lines like this in its
+ .amandahosts file:
+
+
+ some.amanda.client root
+
+
+* There are permission problems on the client preventing user "amanda" from
+ reading its own .amandahosts file. Make sure the file itself is readable to
+ the user "amanda" and all the parent directories down to it can be traversed.
+ A simple test is:
+
+
+ su - amanda -c "cat ~amanda/.amandahosts"
+
+Now, back to the localhost issue. This:
+Do NOT USE "localhost" as host entry in your disklist entries (aka DLEs). Use
+the FQDN (Fully Qualified Domain Name) instead.
+is not really an answer, more of a command :-).
+There are a couple of reasons to NOT use "localhost". First is amrecover will
+not work as expected. When it connects to the server (even though they are the
+same machine), the server will look for the matching DLE's using the real host
+name, not "localhost". The sethost command inside amrecover can "fix" this, but
+why not just set it up right in the first place?
+Another reason to not use "localhost" is because it helps with future changes.
+As the AMANDA configuration grows, it's not at all unusual to take a server and
+make it a client of a new, larger, server. But now "localhost" does not point
+to the same machine it used to. If the FQDN of the machine had been used all
+along, this upgrade would have been much easier.
+There is also no performance reason (any more) to use "localhost" instead of
+the FQDN. Modern OS network stacks know to shortstop packets destined for the
+local machine and never let them hit the wire. Yes, I'm old enough to remember
+when they didn't :-).
+
+ the friday-tape-question
+
+"How do I make AMANDA do full backups on Saturday and incrementals ... ?"
+"My backup screwed up on tuesday and now it keeps asking for the tuesday tape
+even though it is wednesday!"
+ANSWER:
+The short answer is: You can't.
+The longer answer is: You can. But you should not.
+The reason: AMANDA is designed to schedule your backups. Let "her" do it.
+When you want to make the best use of AMANDA, you have to let go the classic
+schedule where one used to have one tape dedicated to each day of the week, and
+one for the friday.
+The main difference in concept is this:
+In the classic backup scheme you said:
+"I want to have incremental backups from Mo-Th and a full backup on Fr."
+Using AMANDA you say:
+"I want to have at least one full backup in 5 days."
+So you don't have to specify exactly WHEN the full backup should happen. You
+just tell AMANDA some goals it should reach and let it work out the details.
+There are several advantages in this:
+Imagine that you have your classic backup-schedule running fine. Everything is
+calculated and designed well, so your tape gets filled well each night.
+Now one user generates an unforeseen huge amount of data. For example, he
+duplicates one big data-directory by mistake.
+So the size of the directory raises within one day, maybe for multiple GBs.
+Would your classic backup-scheme catch that? Or would it run out of tape,
+simply because it was not calculated to have that filesystem with that size?
+AMANDA would try to catch it (and most of the time succeed ...).
+As there is the estimate-phase before actually dumping something, AMANDA can
+look at the DLEs and determine the actual size at the time. It also determines
+the size of an incremental backup so it can test for the Plan B to just run a
+level-1 if it does not work out to do a level-0 for that DLE.
+If the size of the DLE is much bigger than it has been the run before, AMANDA
+still tries to meet your goals. It just reschedules stuff, combining full and
+incremental backups to meet the goals as good as possible.
+So you can think of it as some algorithm which lets AMANDA adapt to your data.
+If you set the goals in a reasonable way, AMANDA will just do the rest.
+
+ the multiple-dumps-question
+
+"How do I put 10 dumps on one tape?"
+ANSWER (provided by Jon LaBadie):
+Use another backup scheduler.
+This question is most often asked by individual computer users as a cost
+consideration.
+AMANDA was developed at the University of Maryland Computing Center for use in
+moderately sized computer centers. That it can be used by users of small
+computers is a testament to its designers and maintainers.
+While it may seem cost effective to put as many dumps as possible on a single
+tape, in a computing center that would be considered a very risky decision. The
+loss of, or damage to, a single tape would be the loss of many days worth of
+dumps. That is too much to chance.
+Thus, AMANDA was designed to never overwrite a non-AMANDA tape, nor an AMANDA
+tape from a different configuration, nor an AMANDA tape from the current
+configuration that is still "active", i.e. has backups on the tape more recent
+than the dumpcycle length.
+If you still feel you want AMANDA to put multiple dumps on a single tape, there
+is a crude way to accomplish your goal.
+But first ask yourself, "If my data is worth so little that I can not afford a
+few more tapes, why am I backing it up?"
+
+Note
+
+Most of the time it won't be YOU paying for the tapes as you may be working for
+some company. If your boss tries to force you into doing this multiple-dumps-
+on-one-tape thing, be sure to point him at this risk. Business people tend to
+understand the price-difference between some tapes and a major data-loss.
+Stefan G. Weichinger
+A common way to put multiple dumps on a single tape is to let them accumulate
+on the holding disk and use the amflush command when you want to put them on
+tape. I.e. if you want a weeks' worth of backups on a single tape, leave the
+tape out for a week. Then stick it in and run amflush.
+(Better make sure you have sufficient disk space on your holding disk.)
+Note, a slight variant of this is to have the parameter autoflush in
+amanda.conf set to "yes". (Users of older AMANDA-releases should check out if
+their version already supports that parameter.)
+Then after several dumps have collected in the holding disk, put the tape in
+before that day's amdump is scheduled. amdump will both flush the holding disk
+to tape and add the regularly scheduled dump.
+
+ the mailing-list-question
+
+"How do i get off this damn mailing list?"
+ANSWER:
+Frequent users of the AMANDA-users-mailing-list get mails like containing
+"unsubscribe"
+as people are trying desperately to get off the list.
+Everyone that subscribes to AMANDA-users gets a mail in which the following is
+contained:
+>Welcome to the amanda-users mailing list!
+>Please save this message for future reference. Thank you.
+>If you ever want to remove yourself from this mailing list, >you can send mail
+to <Majordomo@amanda.org> with the following >command in the body of your email
+message:
+> unsubscribe amanda-users
+Did you see that? You have to send your mail to <Majordomo@amanda.org>, and NOT
+to <amanda-users@amanda.org> !
+
+ the distro-question
+
+"Where can i get binary distributions of AMANDA?"
+ANSWER:
+It is well known that various distributions of Linux contain precompiled
+packages of AMANDA-servers and -clients.
+Due to the design of the AMANDA source code, in which MANY features can be
+configured at compile-time, it is heavily and heartily recommended to take the
+effort and roll your own special flavour.
+Thinking about these things before actually doing backups with AMANDA will help
+you in many ways. And you get the benefits of compiling your own paths/devices/
+configurations right into your AMANDA-binaries. You also get the benefit of a
+much more improved understanding of the way AMANDA does backups.
+
+ the index-question
+
+"Why does amrecover say there are no index files?"
+ANSWER:
+It is very likely that AMANDA is right about that. Check your dumptypes and
+make sure they include the line:
+
+ index yes
+
+If this is the case and you still get that message, recheck the installation of
+your amindexd-binary.
+Is the line in your (x)inetd-configuration pointing to the proper binary? Is
+this line active (= uncommented)? Did (x)inetd reread that configuration since
+that line was edited?
+
+ the tapetype-questions
+
+" amtapetype has been running for 9 days, is this normal?"
+"Will AMANDA work with my frozboz tape drive/library?"
+"Which device is my changer?"
+" amtapetype is broken, it says my 200GB tape only holds 65GB."
+"My file marks are HUGE, 1.3MB (on a 200GB tape, i.e. about 0.05% of the total
+capacity, or expressed another way, maybe 2 mm of a 125000 mm tape ...)"
+ANSWER:
+It is crucial to tell AMANDA the truth about the tape-device(s) you want to
+use. Given the wrong values, AMANDA can't calculate proper dumpsizes, free
+tape-space or make valuable use of compression.
+Before you consider running amtapetype, think twice. Twice.
+As tapedrives tend to be produced by not-so-small companies and as those not-
+so-small companies tend to produce more than one unit to maximize profits, it
+is very likely that someone else has the same device you have or at least one
+that uses the same technology.
+Many people have already run amtapetype to determine the proper values to fill
+in their amanda.conf-files. Browse the example amanda.conf in your AMANDA-
+tarball for various tapetypes. Browse the AMANDA-FAQ on http://www.amanda.org.
+Chances are high that you find just your device described.
+As in every other topic discussed in internet mailing lists, please try finding
+an answer there before asking on the AMANDA-users list.
+If your device is so exotic that even the AMANDA-users can't help you, you
+still have your copy of amtapetype.
+Before you start running it, note this:
+
+* DISABLE hardware compression on your drive.
+
+A common mistake is to have hw-compression enabled. amtapetype uses random data
+to test for the size and speed of your drive. Random data is pretty bad at
+getting compressed. In fact it gets even bigger so the results given back are
+useless. Disable it even if you are planning to use your drive with enabled hw-
+compression.
+
+* Expect it running long.
+
+As you can read in the man page, amtapetype writes the full tape twice, which
+can be a lot of data for modern drives (approaching a TByte). It also writes
+tape marks every 10 MBytes (by default) which forces the drive to flush its
+internal buffers and slows the process down. You can shorten this by giving
+amtapetype a better estimate of the expected capacity:
+$ amtapetype -e 100g -f /dev/nst0
+This "prepares" amtapetype to expect a tape with 100 GB capacity.
+If amtapetype really runs for 9 days, you can be pretty sure there is something
+wrong with your approach.
+And for the filemark-size: Just read the question again.
+
+ the size-question
+
+"How do I back up a partition that won't fit on a tape?"
+aka
+"Can AMANDA span one file over multiple tapes?"
+ANSWER:
+There are two basic rules when it comes to these things:
+
+* AMANDA supports using more than one tape in a single run of amdump
+* AMANDA does not support splitting a dump image across tapes
+
+The first rule lets you make use of two or more tapes for a single amdump when
+using a tapechanger-robot or a tape-library. You could even use multiple tapes
+with the chg-manual-script, waiting patiently for one tape to be filled, then
+change tapes manually.
+No matter how many tapes you can put in your robot or how long you can stay
+awake to change tapes you can NOT split the backup image of one of your
+disklist entries (aka DLEs) across multiple tapes. No way.
+So you may ask the first question listed above. As the size of harddisk- drives
+grows steadily it is not uncommon to have multiple hundreds of gigabytes of
+harddrive capacity in one system. Compared to the size of your maybe not-so-
+shiny-anymore tapedrive this seems (and maybe is) huge.
+What to do?
+Don't split your dump image (it can't be done), split your DLEs.
+You have to use GNU-tar in your dumptypes for this.
+Try to redefine your disklist as in the following example:
+
+ fatboy /bigmama_BIGDIR /bigmama { # a big subdirectory
+ comp-user-tar
+ include "./bigdir"
+ }
+ fatboy /bigmama_FILES01 /bigmama { # all files beginning with...
+ nocomp-user-tar
+ include "./file[01]*"
+ }
+ fatboy /bigmama_FILES23 /bigmama {
+ nocomp-user-tar
+ include "./file[23]*"
+ }
+ ...
+ fatboy /bigmama_REST /bigmama { # Catch-all
+ nocomp-user-tar
+ exclude "./file[0-9]*"
+ exclude append "./bigdir"
+ }
+
+(example taken from a mail by Paul Bijnens on the AMANDA-users-list)
+The trick is to form several chunks of data of which each fits on tape. In the
+example above the chunks are formed by regular expressions matching files named
+like file00, file123 and file9999. You have to look at your DLEs to find the
+patterns describing your chunks.
+As this technique forms data-chunks that fit on your tape it also helps AMANDA
+to schedule your backups more flexible. Having more and smaller DLEs, the
+planner has more variations to possibly schedule your backups, so this will
+help getting nice output from amadmin <conf> balance, too.
+
+Note
+
+DLE-spanning might be supported by AMANDA in a future release.
+
+ the GUI-question
+
+"Is anyone working on a GUI for AMANDA?"
+ANSWER:
+Actually there are people working on GUIs for AMANDA. Aside from that the
+question really is: "Does anyone need a GUI for AMANDA?"
+Given the fact that backups tend to be run at night while people tend to sleep,
+who would need a fancy GUI showing 3D-backup-diagrams via X11? The only part of
+backups where GUIs maybe could add some comfort is recovery for unexperienced
+users.
+
+ the holding-disk question
+
+"Why does it say "Some dumps may have been left in the holding disk." and there
+is nothing in the holding disk?"
+ANSWER:
+The third word in the message. Some dumps MAY have been left.
+
+ ...
+
+Please feel free to suggest additions and corrections. Write to the amanda-
+users-mailinglist at mailto://amanda-users@amanda.org.
+-------------------------------------------------------------------------------
+
+Prev Up Next
+Chapter 16. AMANDA FAQ Home Chapter 18. AMANDA WISHLIST
+
projects / debian / amanda / blobdiff