Sat 13 Jun 2009 08:23:55 PM UTC, original submission:
When I attempted to back up a CentOS-4 system to a CentOS-5 system using rdiff-backup v. 1.2.8, all of the hard-linked files were omitted from the backup with errors saying "Updated mirror temp file does not match source".
A couple specific examples of the errors:
| UpdateError bin/gzip Updated mirror temp file /var/lib/safekeep/lan3/bin/rdiff-backup.tmp.40 does not match source
| UpdateError bin/zcat Updated mirror temp file /var/lib/safekeep/lan3/bin/rdiff-backup.tmp.101 does not match source
Looking at the source system (CentOS-4), I see that gunzip, gzip, and zcat are hardlinked:
On the destination system (CentOS-5), the only file backed up (of these 3) was /bin/gunzip. The other 2 were omitted because of the errors above. In all, there were 17,706 of these errors during the backup, all resulting from hardlinked files (as best I can tell -- I didn't do an exhaustive review of them). The backup was made using LVM snapshot devices, so it wasn't a case of errors caused by files being changed during the backup.
Upon further investigation, I found that this bug is triggered by a difference in the way selinux attributes are saved under CentOS-4 vs. CentOS-5 (and yes, the backup included extended attributes and both systems use selinux). Here's an example of the attributes on each system:
On CentOS-4:
| [root@lan3 ~]# getfattr -d -m '' /bin/gunzip
| getfattr: Removing leading '/' from absolute path names
| # file: bin/gunzip
| security.selinux="system_u:object_r:bin_t\000"
On CentOS-5:
| [root@lan3b ~]# getfattr -d -m '' /bin/gunzip
| getfattr: Removing leading '/' from absolute path names
| # file: bin/gunzip
| security.selinux="system_u:object_r:bin_t:s0\000"
As shown, CentOS-5 adds ":s0" to all of its selinux attributes. This was triggering a bug in rdiff-backup, making it conclude that the source and destination hardlinks didn't match (which technically is true, but shouldn't matter since the attributes and other metadata are saved separately by rdiff-backup).
I am attaching a patch for backup.py (v. 1.2.8) that seemed to fix this bug for me. With it, I could back up hardlinked files without error, and I could restore them with their original attributes intact. I am not expert in the ways of rdiff-backup (or python in general), so this patch should be scrutinized by others with more expertise than me. I have not, for example, investigated whether regressions of failed backups work properly.
This bug is triggered regardless of which direction the backup is made, and regardless of which system is the initiator of the backup. I have also triggered the bug by putting phony security.selinux attributes on a couple hardlinked files on a non-selinux system (e.g., a sysrecuecd live CD), and then backed up the files to a selinux system (e.g., CentOS-4 or CentOS-5).
|