Rsync Backup To Fileserver – Mystery

Home » CentOS » Rsync Backup To Fileserver – Mystery
CentOS 5 Comments

I have an Intel SS4000E fileserver that I’ve been using for several years to backup my home directory to.

I have a daily cron job that runs the following command:

rsync -av –delete /home/frankcox/ /mnt/fileserver/backup

I have a directory named misc/sheet-music/classical. About a week ago I created a new subdirectory there, /home/frankcox/misc/sheet-music-classical/Russian\ and\ Eastern\ European/

Notice the spaces in the subdirectory name; I don’t know if that’s relevant or not.

I store a number of bzip-ed pdf files in that subdirectory, like this: BARTOKA.pdf.bz2, BARTOKB.pdf.bz2 and so on.

Now for the mystery.

The rsync command above gets me a report in my email from cron telling me what files were changed or deleted since the last backup run. And ever since I created that misc/sheet-music-classical/Russian\ and\ Eastern\ European subdirectory, it appears that the files in that subdirectory are getting copied to the fileserver again every day, since they are all listed in the email report that I receive.

diff -r –brief /home/frankcox/misc/sheet-music-classical/Russian\ and\ Eastern\ European/ /mnt/fileserver/backup/misc/misc/sheet-music-classical/Russian\ and\ Eastern\ European/

That command gives me no output, so the contents of that subdirectory appear to match on both machines.

So why is that subdirectory getting copied again every day when it hasn’t changed?

5 thoughts on - Rsync Backup To Fileserver – Mystery

  • that diff has /misc/misc/ in the second compare argument. Not sure if thats the exact command you have been entering or if you retyped it. If that is a good path or is rsync creating new “misc” folders inside your original misc folder?

  • Add the “-i” (–itemize-changes) option to the rsync command to see what rsync believes has changed.

  • Hi Frank,

    I’ve seen this when using the -a flag where it turns out there are discrepancies in ownerships (user:group, UID:GID) between the local source and a remote target. The -a flag intends to preserve user:group and timestamps, and despite the explicit ‘archive mode’ flag, it is possible between different implementations of rsync and differences between operating systems as well as differences between filesystems, that some of those attributes aren’t being fully respected and preserved as the files are actually being written at the target. This can happen silently, so the sender receives no indication that there’s a problem. In these cases, the next time rsync runs, it simply notes that there are differences and copies what it perceives to be the “changed” files again.

    Is there a specific rationale for using ‘-a’ as opposed to the less stringent ‘-r’ (recursive)?

    regards,

    Carl

  • You have put me on the right track here. I looked at those files and discovered that they are all dated Dec 27, 1903 on my computer, and Feb 7, 2040 on the fileserver.

    Interesting. I guess the source archive that I copied those pdf’s from must have had something funky going on with the file dates.

    I just used the touch command to set the dates to something sane, and I suspect that will solve the problem. It appears that rsync have been looking at 1903 vs 2040 and saw that the dates differ, but couldn’t set them to match for whatever reason.