On Sat, 2009-11-28 at 05:30 +0100, Stefan Nowak wrote:> Manpage of rsync 3.0.6 about option --update: [...] This forces rsync
> to skip any files which exist on the destination and have a modified
> time that is newer than the source file. [...]
>
> Here the manpage is very clear to me!
> But if I don't use that option: Would rsync overwrite newer files at
> the destination with older files from the source?
Yes.
> How does --archive behave when a newer file is at the destination?
Rsync's default behavior is to propagate all source files to the
destination regardless of mtimes, using them only as part of the "quick
check" to decide whether file data needs to be transferred. The
--archive option has nothing to do with this aspect of rsync's behavior.
> I am thinking about this, because I am thinking about the restore
> process. If I keep a certain filtered subset of my original as a
> backup, and then my original partially brakes (example: incidental
> file deletion) I would use:
>
> rsync -au backup/ original/
>
> In order to put everything back, except where content at the original
> is newer, or identical (=did not get missing through the incidental
> file deletion in our example). What I want to avoid is that a newer
> file is at the destination, and nevertheless it gets replaced by the
> old version from the backup!!!
Also consider --ignore-existing.
> What of course cannot be avoided,
> because rsync can simply not know it, is that intentionally deleted
> files since the last backup at the destinations get restored from the
> backup. But with this I could live, and just do a manual "disk spring
> cleaning".
Right. "rsync -u" is a blunt measure that reverses some kinds of
mistakes but not others and can reverse intentional actions too. When I
lose data (fortunately pretty rarely), I tend to manually compare the
main filesystem and the backup to determine what to restore.
--
Matt