Imported Upstream version 2.4.5

[debian/amanda] / docs / topten.txt

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