0

Got a strange problem. We have a directory with hundreds of huge log files, and I have to transfer them to a new server.

First I did : rsync -zavh /foo/bar/logs 10.10.10.10:/

Worked well, took an eternity. Now 2 days after, I'm trying to update. I know there's only 20 new files. So I do rsync --dry-run -zavh /foo/bar/logs 10.10.10.10:/ first. It says it's sending incremental file list, but then try to recopied the WHOLE directory again with the new 20 files.

I've checked and the older files have the same date stamp and size.

Why rsync is not just transfering the 20 or so files that are newer ?

Improve this question
4
  • What filesystem is 10.10.10.10:/ Commented Sep 12, 2020 at 15:37
  • Source is ext4 (RHEL 6.10) and destination is xfs (RHEL 7.8). That said, this is the only directory that gives me that kind of behavior. The other directories (same source/destination) are sync incrementaly without problem. Commented Sep 12, 2020 at 15:41
  • Please add the -i flag to your run and add some of the output to your question. It will show the reason that a file is selected for copying. Commented Sep 13, 2020 at 3:26
  • Thanks for the suggestion. Came after cutover though, but I'll keep in mind if I stumbled over that problem again. Commented Sep 13, 2020 at 13:13

1 Answer 1

Reset to default
1

You're missing a trailing slash on the source directory.

The first time you ran this I expect it created /logs on the destination, just as expected. The next time you run it, though, it will have (started to) put the source logs directory into the existing /logs directory, creating /logs/logs.

The solution here is to put a trailing slash on the source directory and specify the target fully

rsync -zavh /foo/bar/logs/ 10.10.10.10:/logs/
Improve this answer
6
  • Thanks for your answer, but with, or without trailing slashes, it gives me the same list (dry-run) including the old unmodified files. Commented Sep 12, 2020 at 19:20
  • Correct destination path? Owner/group? Does stat show exactly the same time in source and destination? Commented Sep 12, 2020 at 19:44
  • Thanks again. Same size, some blocks small differences (202280 instead of 202288). Mostly same modify time (Modify: 2018-06-20 20:30:20.000000000 -0400 instead of Modify: 2018-06-20 20:30:20.672219155 -0400). I mean there are differences at the fraction of seconds...would that be enough ? Those were created by rsync at first run right ? Commented Sep 12, 2020 at 20:11
  • According to the man page, rsync only uses whole seconds for comparison (by default), so that should be fine. Can you explain what you mean about differences in the blocks please Commented Sep 12, 2020 at 20:50
  • Well stat reports : "Size: 103565566 Blocks: 202288 IO Block: 4096 regular file" on the source and : "Size: 103565566 Blocks: 202280 IO Block: 4096 regular file" on the destination. Which is odd, but maybe the different filesystem type and the size of the file maybe ? Commented Sep 12, 2020 at 22:37

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.