Disk offline

From wiki.zmanda.com
Revision as of 23:26, 30 June 2008 by Dustin (talk | contribs) (→‎Explanation: man links)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This article is a part of the Troubleshooting collection.

Problem

amdump(8) reports,

disk offline

Explanation

This may be caused by a permission problem, although amcheck(8) would report that.

Another possible reason for this failure is a filesystem error, that causes DUMP to crash before it estimates the backup size. In this case, 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.

Solution

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.

Check for the correct Amanda-user on the problematic client (Is that client running with the correct user?)

Does that user exist on that machine?

If the DLE is a SMB-share, check for proper permissions by accessing the share via smbclient:

  smbclient //SMBserver/SMBshare -U SMBuser

Check if you have the dump-binary installed(!)

Credits

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