Disk offline: Difference between revisions
m (Amdump: disk offline moved to Disk offline: error message) |
(→Explanation: man links) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Troubleshooting | {{Troubleshooting Header}} | ||
=Problem= | |||
{{man|8|amdump}} reports, | |||
disk offline | disk offline | ||
=Explanation= | |||
This may be caused by a permission problem, although | This may be caused by a permission problem, although {{man|8|amcheck}} 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 | 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. | 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. | 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. | ||
Latest revision as of 23:26, 30 June 2008
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].