rsync增量备份异常：传输150GB远超10GB变更量，求排查命令问题

Let's troubleshoot why your rsync is sending 150GB instead of just the 10GB of changed data—here's a breakdown of potential issues and fixes, starting with your command:

1. Path Trailing Slash Mismatch (Common Culprit!) #

Your source path is /volume1/Backups (no trailing slash). Rsync treats this differently than a path with a trailing slash:

• Without /: Rsync will create a Backups directory in your target path and sync all contents into it.
• With /: Rsync syncs the contents of /volume1/Backups directly into your target directory.

If your previous backups used a trailing slash on the source, rsync now sees a new directory (Backups) on the target and will re-sync everything. Check if your target path already has a Backups subdirectory with old data—if so, adjust your source path to /volume1/Backups/ to match the original structure.

2. Verify Your Exclude Rule is Working #

You’re excluding #recycle, but:

• Is #recycle a directory? If so, add a trailing slash to the exclude rule: --exclude '#recycle/' to ensure the entire directory (and its contents) are skipped.
• Check your rsync.log for entries mentioning #recycle—if you see files from this directory being synced, the exclude rule isn’t taking effect. The # character is safe here since you’ve quoted it, but double-check that the path matches exactly (case-sensitive if your filesystem is case-sensitive).

3. Rsync’s Incremental Checks Are Failing #

Rsync relies on comparing file attributes (size, modification time, inode) between source and target to detect changes. If any of these are off, it’ll re-sync the entire file:

• Clock drift: Ensure the source and backup server clocks are synchronized (use ntp or similar tools). Even a small time difference can make rsync think all files are modified.
• File attribute changes: If the target server had a filesystem repair, permission batch update, or data migration, file attributes might have been altered. Add the -i (itemize changes) flag to your command to see why files are being synced:

  rsync -avhi --exclude '#recycle' -e 'ssh -p 1432' /volume1/Backups remote@remoteIP:/home/...
  

  Look for entries starting with > (file content changed) vs f+++++++++ (new file) or T (modification time changed). If most are T or > without actual content changes, attribute mismatch is the issue.

4. Command Parameter Order & Redundancies #

Your -e 'ssh -p 1432' is placed after the source path, which rsync will accept, but it’s better practice to put all options before the source/target to avoid confusion. Adjust it like this:

rsync -avh -e 'ssh -p 1432' --exclude '#recycle' --log-file="/var/tmp/rsync.log" /volume1/Backups remote@remoteIP:/home/...

The --rsync-path="rsync" is redundant (rsync uses rsync by default) unless your remote server has rsync in a non-standard path—you can remove it unless you need it.

5. Test with a Small Subdirectory #

To narrow down the issue, sync a small, known subdirectory of /volume1/Backups (e.g., /volume1/Backups/test-subdir) with the -v and -i flags. This will let you quickly see if rsync is behaving as expected for a subset of your data, helping you rule out global issues vs specific files/directories.

内容的提问来源于stack exchange，提问作者Pulsar