Re: [rdiff-backup-users] Regression Fails: "IOError: Not a gzipped file"

[Andrew Ferguson]

On Oct 10, 2008, at 2:38 AM, Brad Guillory wrote:
>  File "/usr/lib/python2.4/gzip.py", line 162, in _read_gzip_header
>    raise IOError, 'Not a gzipped file'
> IOError: Not a gzipped file
>
> # gzip --test /mnt/lacie/servers/prod-no-mumms-2/data/home/cpc/rdiff- 
> backup-data/increments/var/data/http/xml/hcmid/hcmid/patient/8093/ 
> patient.xml.2008-10-03T20:03:47-05:00.diff.gz
>
> gzip: /mnt/lacie/servers/prod-no-mumms-2/data/home/cpc/rdiff-backup- 
> data/increments/var/data/http/xml/hcmid/hcmid/patient/8093/ 
> patient.xml.2008-10-03T20:03:47-05:00.diff.gz: not in gzip format
>
> #rdiff-backup --version
> rdiff-backup 1.0.5


Hi Brad,

In the current versions of rdiff-backup, this error is handled cleanly  
and automatically. (1.0.5 is almost two years old)

You should be able to delete the offending "gzip" file without  
trouble. That works in the current versions, but I can't say for  
certain whether 1.0.5 can handle that.

What has happened is that rdiff-backup crashed while writing the  
gzip'd reverse-increment, which is before it updates the metadata file  
containing information about "patient.xml", but after it has updated  
"patient.xml" to the latest version.

So, when it performs the regress operation, it detects that the  
metadata record and the mirrored version are out of sync. It then  
decides to apply the reverse-increment file to bring the mirrored  
version back to the version which was correct at the time the metadata  
was written (in other words, regress the whole backup mirror to the  
last complete backup).

However, since the reverse-increment is corrupt, that process fails.  
By deleting the bad reverse increment, you are simply allowing the  
mirrored version and the metadata record to silently stay out of sync.  
When the next backup completes, the two will be back in sync.



Andrew