5

I wish to backup data mounted on an NTFS partition of a linux machine to the NTFS partition of another linux machine. The local NTFS drive is mounted with all files owned by root.root, but the remote NTFS drive is mounted using plugdev (so file ownership is root.plugdev).

rsync can apparently not copy owner/group and permission info in this situation, so I have been trying to run

sudo rsync -rltDvO --delete /ntfs/src/ user@remote.example.com:/ntfs/dest/

However, every time I run this command, it re-copies ALL the files, rather than just transferring the changed files. I have tried using the --modify-window flag, but that hasn't helped either.

Update: it is not recopying all the files, rather it is recalculating the checksums (or doing some other processing, causing the filename to be printed) for each file. This is opposed to what happens between to e2fs drives, where no filenames are printed if no changes have been made to the source and destination since the last rsync. I am guessing this processing is because the timestamps are not available on NTFS(?)

Next update: Permissions certainly seem to be a part of it: first, also using -u as an rsync flag stopped the processing of all the files on the destination, but this is not what I want. Secondly, if I use an account with root access (and rsync flags -avz) on the remote machine, I can actually change the timestamps on files and directories. However, some files continue to be recopied, and the --modify-window seems to help for that somewhat (but not completely, it seems - I'm still experimenting to find out why.)

  • 1
    Is there a reason you are omitting directory times (-O) ? – Paul Jul 22 '11 at 13:07
  • When using -t, rsync generates errors like rsync: failed to set times on "/windows/backups/media/Folder_name": Operation not permitted (1) for each folder. The -O flag prevents rsync trying to set these times. – Steve Kroon Aug 30 '11 at 10:01
7

As per my second update, the permissions of my user did not allow me to set times. Running the rsync using the root account on the destination machine, along with --modify-window=5 gave me suitable behaviour. (If you don't have root access on the destination, the -u flag could help, but only if you're sure no-one will change the files on the remote system.)

4

Ideally you always want to use robocopy as it handles variations in timestamps (upto 2 seconds for FAT). You can run in inside Wine but connecting to the remote host might be inconvenient.

http://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx

edit: per Steve's comment, this feature appears to now be in rsync 3.0:

--modify-window

When comparing two timestamps, rsync treats the timestamps as being equal if they differ by no more than the modify-window value. This is normally 0 (for an exact match), but you may find it useful to set this to a larger value in some situations. In particular, when transferring to or from an MS Windows FAT filesystem (which represents times with a 2-second resolution), --modify-window=1 is useful (allowing times to differ by up to 1 second).

  • 2
    rsync does support timestamp variations using the --modify-window flag. – Steve Kroon Aug 30 '11 at 10:16
0

An additional tidbit I've found in cases like this: Standard vs. Daylight time. I had a bunch of files in an rsync start syncing right after time zone change one year. I used --modify-window=3605 and it fixed the problem. The downside is that it would ignore files with a modification date within an hour of each other. In my case the files weren't expected to change except every few days or weeks, so that was fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.