2

I've discovered tonight that some rsync backups aren't quite working as intended. For info, we're using rsync version 3.1.2, with options -rulv.

In short, on one of our server's HDDs we have directories full of files; some of those files are occasionally symlinked to another location for a while (an SSD cache, in fact) and then some of them are reverted to being plain files again later. (FWIW, we use absolute symlinks to point to the cache. I have retrieved a sample from our remote backup box and verified that the absolute symlinks are preserved.)

I've now realised that the remote copy of the data contains symlinks which have since been reverted to plain files on the local server. This means that the regular rsync process is somehow NOT overwriting the remote symlinks with plain files. It's also clear that it must have overwritten the remote plain files with symlinks at some point, so it's odd that it's unwilling to reverse this process.

I've read the rsync man page and am unable to (a) understand this behaviour or (b) work out if a combination of options exists which will do the "right" thing in this context. By "right" thing, I mean overwrite a remote plain file when the local side has a symlink [already happening successfully], and overwrite a remote symlink when the local side reverts to a plain file [not happening at present]...

Guidance gratefully received!

4
  • It could be the -u. Check if the local symlink is replaced by an older real file.
    – meuh
    Commented Oct 18, 2021 at 10:00
  • Ooooh, good point, thanks @meuh - will double-check that!
    – Neilski
    Commented Oct 18, 2021 at 22:26
  • OK... That's embarrassing. That does indeed appear to have been the problem. Cough and double-cough. I guess I should probably just delete the question now? (In my defence, I guess I was imagining that the ctime would be used rather than the mtime, but in hindsight that wouldn't make much sense.)
    – Neilski
    Commented Oct 18, 2021 at 22:46
  • Done, thanks :-)
    – Neilski
    Commented Oct 21, 2021 at 19:25

1 Answer 1

3

For the benefit of folk who hit this snag in the future...

OK, thanks to the comment above from @meuh, I was able to confirm that the -u option was basically the problem (combined with me not thinking it through!).

When I reverted the symlinks to plain files, there was no copying involved; instead I was simply mv-ing the original plain file back to its original name, overwriting the symlink. Since this only updates the ctime and not the mtime in the inode, and since rsync with -u apparently (and not unreasonably) looks at the mtime when deciding if a file is newer on the receiver, it was comparing an old local plain file to a newer remote symlink and correctly deciding to leave it alone.

2
  • Add -t to your flags. Otherwisersync can't shortcut with timestamps Commented Oct 21, 2021 at 19:32
  • @roaima: thanks, that may be generally a useful thing to do, but it wouldn't help in the case I'm describing because the plain file is genuinely older than the symlink
    – Neilski
    Commented Oct 22, 2021 at 21:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .