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
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
