0

The command I use for a basic backup, rsync -avr --delete working_directory/ backup/, would correctly create a mirror of my directories.

However, sometimes I move loads of files around in the source. For example, renaming a/ to A/, b/ to B/. In this case, the command would first delete the target a/ and then copy the whole A/.

This is annoying when a/ is huge. Is there a way of applying the more efficient solution of simply moving files in the target so they match the source?

It does not have to be rsync based. Any cli tool is fine.

Quora Feans
  • 3,806
  • 7
  • 29
  • 46
  • rsync just cannot rename. Well… manually fiddling with hardlinks and the --fuzzy option, you could probably manage to save some bandwidth as explained there : https://lincolnloop.com/blog/detecting-file-moves-renames-rsync/ – MC68020 Aug 25 '22 at 16:17
  • See if anything here helps https://rotadev.com/handling-renamed-files-or-directories-in-rsync-server-fault/ – GMaster Aug 25 '22 at 16:23
  • Related, if not a duplicate - [Rsync that handles moves sensibly](https://unix.stackexchange.com/q/102620/100397) – roaima Sep 26 '22 at 08:34

1 Answers1

0

There is no "smart" way for rsync to know that REPLICA/a is a "mutation" of MASTER/A.

The only way to minimize the extent of such copying is for you to keep track of the renaming actions taken (scan for mv instances in history) then replicate those commands (manually?) on the corresponding directories under REPLICA, before you perform the normal rsync operation, which will then only copy over the pure deltas.

The issue is that, assuming the same filesystem type at both ends, the REPLICA inode tables are not identical to the MASTER inode tables, so there is no way to match up inodes that may have been renamed on a different device. Unfortunate, but no way around it.

The only way what you are hoping for could be achieved directly is if rsync actually kept track of an inode-mapping table, on a per-file basis, for inode correspondence. However, with different devices having different inode table structures for different filesystems, the problem is far too complex, in my opinion, to contemplate or pursue.

Eric Marceau
  • 368
  • 1
  • 10