On Fri 22 Jun 2007, Eric Wilhelm wrote:
> # from Bernd Haug
> # on Friday 22 June 2007 02:12 am:
>
> >But if you move files in the backed up directory around, I don't
> >think that rsync goes and checks whether this new name has the same
> >inode as a file currently in backup had when it was on the original
> >FS (where should it get that data in the first place?).
>
> Yep. The dirvish scheme is just:
>
> 1. copy old backup tree to new backup tree, hardlinking everything
> 2. rsync into that
Actually, dirvish does not copy the old backup tree to the new backup
tree, it lets rsync do the heavy lifting there via the --link-dest
option (rsync links unchanged files when it encounters them, it's not a
2-part action).
> Step 2 only looks at filenames, not inodes. This breaks the links
> whenever a file has changed and deletes any files that are missing. An
> mv on the source (from rsync's pov) equates to delete+create.
rsync now has a --fuzzy option that might help:
The current algorithm looks in the same directory as the destination
file for either a file that has an identical size and
modified-time, or a similarly-named file. If found, rsync uses the
fuzzy basis file to try to speed up the transfer.
So renaming a file "foo" to "foo.1" might preserve the link (I've never
tested how well the --fuzzy option finds renamed files).
Preserving hardlinks in all cases isn't really an option.
If you're doing a renaming on the source that will have a large impact
on the backup, it's probably advisable to do the same in the latest
backup tree. In other cases, just accept that you lose hardlinks...
Paul Slootman
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
