Disk offline: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
 
(→‎Explanation: man links)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
--- This text was originally contributed to the AMANDA-FAQ-O-Matic by gyles19@visi.com. ---
{{Troubleshooting Header}}
=Problem=
{{man|8|amdump}} reports,
disk offline
=Explanation=
This may be caused by a permission problem, although {{man|8|amcheck}} would report that.  


Well, assuming the disk is not really off line :-), it may be a permission problem, but then, `amcheck' would have reported it.  
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.  


Another possible reason for this failure is a filesystem error, that causes DUMP to crash before it estimates the backup size; 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. 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.
=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 AMANDA-user on the problematic client (Is that client running with the correct user?)


Does that user exist on that machine?
Does that user exist on that machine?
Line 15: Line 19:
If the DLE is a SMB-share, check for proper permissions by accessing the share via smbclient:
If the DLE is a SMB-share, check for proper permissions by accessing the share via smbclient:


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

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