problem with extraction of .tgz file on Redhat AS 3.0

[Girish N]

Hi Linus,

Thanks again for the reply. As said earlier, wil reschedule the .tgz 
dump to a local mount point & will check the same.

Thanks & Regards
Girish

C. Linus Hicks wrote:

>On Mon, 2004-12-20 at 11:07 +0530, Girish N wrote:
>  
>
>>Hi Linus,
>>
>>Thanks for the reply,
>>
>>1. The datafile in question if only 1Gb
>>2. This is a low end server with 2Gb memory & the backup is scheduled to 
>>run at 4 AM when there is no memory resource crunch.
>>
>>The corruption seems to be very inconsistent, 1 day the .tgz is fine, 
>>while the 2nd day, the .tgz file gets corrupted. Am planning to 
>>reschedule the .tgz backup to one of the local Mount points instead of 
>>the SAN Harddisk & then check the same.
>>
>>You hv commented that "Not with the symptoms you have", does that mean 
>>that this may be one-of-the reasons for file corruption.
>>    
>>
>
>Having an inconsistent datafile will not cause the kind of corruption
>you are getting in the tgz file. If you backup (by whatever means) a
>datafile that is in an inconsistent state, then the result of restoring
>that file will be a datafile in an inconsistent state, not a problem
>with the restore. The reason tar complained was because of the gzip
>error. When gzip took the error, it was unable to continue ungzipping
>the file and sent EOF to tar.
>
>This means the error will be with corruption either during gzip, or
>writing to disk. This suggests a hardware problem, perhaps in memory, or
>with writing to the SAN. Trying a local disk rather than the SAN is a
>good idea. You might also try running memtest on this machine. Having no
>memory resource crunch at the time of the backup doesn't really mean
>much, but I would expect other files to show the same symptom if memory
>is the problem.
>
>http://www.memtest86.com/
>
>  
>