Re: cross-platform backup tool Same files from different source dir causes spurious diff files
Eric Lavarde <[email protected]>
| Newsgroups | gmane.comp.sysutils.backup.rdiff-backup.general |
|---|---|
| Message-ID | <[email protected]> |
Hi, even if it's not the inodes, it might be any kind of metadata (ownership, time, access rights, etc). I could for example imagine that the LVM snapshot is readonly, which would make rdiff-backup consider that there is a change, as Leland already stated. This said, if you consequently use the LVM snapshot, I would assume that it'll remain a one time effect. KR, Eric On 08/02/2022 05:25, Robert Nichols wrote: > On 2/7/22 7:23 PM, Leland Best wrote: >> Hi Cliff, >> >> On Mon, 2022-02-07 at 11:45 -0800, Mr. Clif wrote: >>> Hey Eric, >>> >>> any ideas on this? How do these diff files normally work? >> [...] >> >> I'm not an 'rdiff-backup' developer or anything so all you experts >> out there >> correct me if I'm wrong but ... >> >> IIRC 'rdiff-backup' keeps inode info as part of the metadata for each >> file. >> When you mount a filesystem Linux assigns "fake" inode numbers to avoid >> collisions between filesystems on different devices/partitions/etc.. >> So if you >> change the mount point, every file could potentially get a new inode >> number and, >> consequently, have changed metadata. That results in 'rdiff-backup' >> creating a >> '*.diff*' file for every source file. > > Device and inode metadata is kept only for files with multiple hard > links. That's > to keep track of which links reference the same file. That information > is not > needed for files with just a single hard link, and unless something > has changed > in the latest release that metadata is not kept. You can look in the > mirror_metadata file (it's compressed ASCII) and see what fields are > present > for each file. > >> In addition, since 'rdiff-backup' now thinks the files may have >> changed it >> spends a lot of time checking if anything other than metadata has >> changed which >> _might_ account for the apparently low throughput. > > That would definitely be true, and the presence of all those "zero > diff" files > show that it is, in fact, happening. >