On Sat, 16 Feb 2013 11:23:52 +0000 Wayne Stallwood ALUGlist@digimatic.co.uk allegedly wrote:
I'm not sure why you didn't use rsync to copy them back rather than cp ?
Because I'm stupid and didn't think of that. :-)
I automatically equate rsync (along with rcp) with remote copying and cp with local copying. So my reflex action was to use cp between the two local internal disks and then to later run my rsync backup when some of the local files had changed (mainly email). I then saw that rsync was apparently re-copying /all/ my local files to the NAS so killed it.
Anyway the answer to your original question is that the default behaviour for rsync is to only compute file differences via the checksums if the modification dates between source and destination indicate the file has changed (source is newer than the destination) So it's not actually recopying everything (though if things like permissions have changed on the source files they will now overwrite those on the target and naturally the timestamps will be updated) Previously when you ran your backup it would have just skipped anything that had the same or older timestamp than the target.
That is what puzzled me and prompted my question. The rsync certainly /looked/ as if it was recopying everything. The process was taking a long time.
The other thing you could do is use rsync to copy over the top resetting the timestamps back. This would be quicker than using cp as it won't have to copy the whole file over, however you'd need to set some options to tell to ignore the newer timestamps on the target.
Thanks for the advice.
Mick
---------------------------------------------------------------------
blog: baldric.net gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312
---------------------------------------------------------------------