Disk offline: Difference between revisions
Paul.bijnens (talk | contribs) m (up link) |
No edit summary |
||
Line 1: | Line 1: | ||
{{Troubleshooting Category|Error Messages}}{{Troubleshooting Category|Amdump}} | |||
{{Troubleshooting Problem}} | |||
[[amdump]] reports, | |||
disk offline | |||
{{Troubleshooting Explanation}} | |||
This may be caused by a permission problem, although [[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 [[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. | |||
{{Troubleshooting 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?) | |||
Check for the correct | |||
Does that user exist on that machine? | Does that user exist on that machine? | ||
Line 17: | Line 21: | ||
smbclient //SMBserver/SMBshare -U SMBuser | smbclient //SMBserver/SMBshare -U SMBuser | ||
Check if you have the dump-binary installed | Check if you have the dump-binary installed(!) | ||
--- | =Credits= | ||
This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. |
Revision as of 04:34, 7 April 2007
Template:Troubleshooting CategoryTemplate:Troubleshooting Category Template:Troubleshooting Problem amdump reports,
disk offline
Template:Troubleshooting Explanation This may be caused by a permission problem, although 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 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.
Template:Troubleshooting 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].