This can make things worse because the remote has resolution to the second, whereas NTFS has 100 nanosecond resolution (other filesystems have other resolutions). So first backup may do lots of reads, attempting to make sure that the false-alarm timestamp changes (not visible in log due to its resolution) are truly nothing to worry about, and that file contents are as expected… What’s odd though is this part:
Above link shows where to look in the DB for time records if you like, e.g. using DB Browser for SQLite.
If you can cut this down into reproducible test steps for repeatable time mismatches, it’s worth an issue. Support requests in this forum are not tracked, and the developers tend to work from the GitHub issues.
When coming up with steps, it would also be worth testing whether USN use has an effect on this issue, however I’m not seeing this on backups of files from Windows 10 NTFS with –snapshot-policy=required.