Results missing

From wiki.zmanda.com
Revision as of 11:45, 7 December 2005 by Paul.bijnens (talk | contribs) (Reworked)
Jump to navigation Jump to search

Amcheck passes all tests?

First test with amcheck and solve all issues it complaints about. (Messages marked with "NOTE" do not need to be handled.)

Timeout during estimate?

If the estimates take too long, the Amanda server may have already given up waiting for that client. Find out how long the estimate took on the client. Locate the debug file for sendsize on that client in the AMANDA_DBG directory. The last line of the file contains a timestamp. Also count how many disklist entries (DLE) there are for this host. 

$ tail -1 sendsize.20051206000412.debug
 sendsize: time 256.797: pid 16014 finish time Tue Dec  6 00:08:29 2005

$ grep 'estimate time'  sendsize.20051206000412.debug
sendsize[16017]: estimate time for /space level 0: 0.653
sendsize[16017]: estimate time for /space level 1: 0.007
sendsize[16016]: estimate time for / level 0: 217.741
sendsize[16016]: estimate time for / level 1: 25.902
sendsize[16038]: estimate time for /boot level 0: 0.044
sendsize[16038]: estimate time for /boot level 1: 0.007
sendsize[16041]: estimate time for /var level 0: 11.492
sendsize[16041]: estimate time for /var level 2: 1.037

The Amanda server waits etimeout seconds (default 300 s) muliplied by the number of disklist entries for that host. In the above example that would be 4 * 300 seconds. (The above estimate took 257 seconds, so that is good.)

You may need to adjust the etimeout value in amanda.conf. Take into account that Amanda can ask estimates for 3 dump levels (level 0, level N, and level N+1) for each disklist entry.

Investigate why some of the estimates take so long. PaUsing gnutar on a filesystem with many small files can take a very long time.

Since Amanda version 2.4.5 you can also use faster but less accurate methods for the estimates with the amanda.conf parameter for the dumptype.

estimate client|calcsize|server
client
Use the same program as the dumping program, this is the most accurate way to do estimates, but it can take a long time. This is the default.
calcsize
Use a faster program to do estimates, but the result is less accurate.
server
Use only statistics from the previous run to give an estimate, it takes only a few seconds but the result is not accurate if your disk usage changes from day to day.

Choose a faster method for a particular large and slow partition, e.g.:

disklist: 

 myhost.example.com   /cvsrep  {
         comp-user-tar
         estimate calcsize
       }


UDP packet too large?

--- This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. ---

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, or need to be tuned increase the limit.

You can see the UDP reply packet in the amandad.datetime.debug file in the AMANDA_DBG directory on the client: 

...
amandad: time 0.000: got packet:
--------
Amanda 2.4 REQ HANDLE 003-B88F0708 SEQ 1133823863
SECURITY USER amanda
SERVICE sendsize
OPTIONS features=fffffeff9ffe7f;maxdumps=2;hostname=myclient.example.com;
GNUTAR /space 0 1970:1:1:0:0:0 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR /space 1 2005:11:26:0:46:56 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR /var 0 1970:1:1:0:0:0 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR /var 1 2005:12:3:0:41:14 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR /boot 0 1970:1:1:0:0:0 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR /boot 1 2005:11:29:2:11:9 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR / 0 1970:1:1:0:0:0 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR / 1 2005:12:1:0:27:38 1 OPTIONS |;bsd-auth;compress-fast;index;
GNUTAR / 2 2005:12:3:0:26:8 1 OPTIONS |;bsd-auth;compress-fast;index;
--------
...

The UDP packet is the text between the lines with hyphens. Copy/paste the text in a file, and count the characters with "wc".

You can notice that amanda asks for 1, 2 or even 3 different dump levels of each disklist entry (the third value. A run on a different day, could result in more or less lines, bumping into the UDP packet size limit on some days only. (After a "amadmin config force myclient.example.com" would request a lot less estimates, making this it succeed maybe.)

If you use many include/exclude directives in the dumptypes, find out what takes less size bytes to communicate: a pathname on the client with "include list", or a few "include file append" directives in the dumptype itself.

One possible work-around is to try to shorten the pathnames of the directories, so that more requests fit in the UDP packet. You may create short-named links in some directory or exclude files 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 `.bkpN' 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.


--- This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. ---

If this error appears only with local dumps (backing up server itself) or with Samba shares, the reason might be that your client on the server is not working properly.

The first thing to check is whether the inetd is configured correctly to run the AMANDA client.

My inetd.conf on FreeBSD contains: 

  amanda dgram udp wait operator /usr/local/libexec/amanda/amandad amandad
  amandaidx stream tcp nowait operator /usr/local/libexec/amanda/amindexd amindexd
  amidxtape stream tcp nowait operator /usr/local/libexec/amanda/amidxtaped amidxtaped

But refer to manual and documentation for detailed information about inetd and amanda.

Note: The other FOM-entries (wrapper-stuff) are yet to be discussed. See FOM

Retrieved from ‘http://wiki.zmanda.com/index.php?title=Results_missing&oldid=1788’