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

A posting from the amanda-users mailing-list (mailto://[email protected]) 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.

People get something like:

>Amanda Backup Client Hosts Check
>--------------------------------
>ERROR: localhost: [access as amanda not allowed from 
>[email protected]] 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 [email protected]
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 [email protected]" 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 [email protected]") regardless of what the usual Amanda user is.

Potential problems:

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.

some.amanda.client	root

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 :-).

"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:

Using Amanda you say:

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.

"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?"

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".

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.

"How do i get off this damn mailing list?"

ANSWER:

Frequent users of the Amanda-users-mailing-list get mails like containing

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 <[email protected]> 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 <[email protected]>, and NOT to <[email protected]> !

"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.

"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?

" 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:

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.

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:

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.

"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:

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.

"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.

"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://[email protected].