TimeWarn
From RdiffBackupWiki
On the hints page, it notes that the elapsed time listed in the logs will be off if the system clocks of the client and server are not synced. It might be nice to print a warning about this, if the machines are more than a certain degree of skew away from each other.
I have no idea how nasty this would get in a windows port.
Backing up a space probe could well involve link latencies in the vicinity of fifteen minutes; the tcp and ntp folks have looked at this problem, so maybe they have code that can be lifted/invoked, but if all that was happening was printing of a warning, setting a skew limit of a minute or so might be reasonable.
I suppose if one wished to get really fancy, one could specify a clock source to use for timestamping purposes, telling rdiff-backup to trust either the client, the server, or some other time source (ntp, rdate, etc) for the purposes of log entries and time stamps on mirror files and such.
Certainly there should be a way to recover if one of the machines involved in a backup has a badly mis-set clock such that the mirror timestamp is way off in the future and needs to be moved back; would a simple rename of the file make everything better? If so, that should be documented.
Only the clock of the system where rdiff-backup is run from is used; the other systems get the time from that machine. So it doesn't matter what is happpening with the clock of the other systems. If for some other reason you want to keep them in sync, you could use a different script to do that.
About the mis-set clock that is far in the future: the times would be stored in increments throughout the archive, so it wouldn't be just one renaming. Easiest way would be to touch the current_mirror file and regress to the earlier date, although you'd lose that misdated backup.
-- BenEscoto
