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? -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
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? -- Jeremy Thompson Sports Warehouse Inc. jeremy at warehousesports.com> On May 1, 2015, at 10:10 AM, Frank Cox <theatre at melvilletheatre.com> wrote: > > 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? > > -- > MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.centos.org/pipermail/centos/attachments/20150501/064e7b5c/attachment.sig>
On Fri, 1 May 2015 10:21:18 -0700 Jeremy Thompson wrote:> 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?Good catch; unfortunately it's just a typo when I wrote that email and the actual diff command has only one misc/ in it. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com
On 05/01/2015 12:10 PM, Frank Cox wrote:> 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?Add the "-i" (--itemize-changes) option to the rsync command to see what rsync believes has changed. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
On Fri, 1 May 2015 11:10:26 -0600 Frank Cox wrote:> I have a daily cron job that runs the following command: > > rsync -av --delete /home/frankcox/ /mnt/fileserver/backupHi 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
On Fri, 1 May 2015 19:44:58 -0400 Carl E. Hartung wrote:> 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.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. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com