登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux rsync 复制后文件时间不对:--times、时区显示与验收命令

来源:17golang原创

时间:2026-08-25 13:59:35 446浏览 收藏

rsync 复制完成后,如果目标机上的文件时间和源机看起来不一样,先不要急着重新传一遍。最常见的原因是命令没有带 --times,或者两台机器用不同的时区显示同一个修改时间;如果文件系统只保留到秒,纳秒差异也会让验收结果出现偏差。

先用 stat 同时查看 Unix 时间戳和格式化时间,再确认 rsync 是否使用 --times。只有时间戳也不同,才需要修正复制参数;仅显示时区不同,不代表文件真的被改过。

实践要点

  • -t--times 的缩写,用于保留文件修改时间。
  • ls -l 受本机时区影响,跨机器验收优先看 stat 的 epoch。
  • FAT 等低精度文件系统要结合 --modify-window,不能只看肉眼显示。

先判断“时间不对”是哪一种不对

Linux 文件至少有修改时间(mtime)和访问时间(atime)等不同时间属性。rsync 的 --times 处理的是修改时间,不会因为你看到了访问时间变化就自动把它当成复制失败。更容易混淆的是,ls -l 把时间格式化成当前机器的本地时区,同一秒数在不同主机上可能显示成不同的日期和小时。

rsync 修改时间从源文件到目标文件的传递与 stat 验收
从源文件时间到目标文件时间,先看参数,再用 stat 验收。

默认复制为什么会留下传输时间

下面的实验先创建一个固定修改时间的文件。为了让结果可复核,命令不使用当前时间作为判断依据:

mkdir -p /tmp/rsync-demo/src /tmp/rsync-demo/dst
printf 'rsync time check\n' > /tmp/rsync-demo/src/report.txt
touch -d '2024-05-20 08:30:00 UTC' /tmp/rsync-demo/src/report.txt
stat -c 'src mtime=%y epoch=%Y' /tmp/rsync-demo/src/report.txt

# 没有 -t,目标文件通常使用接收时刻作为修改时间
rsync -a --no-times /tmp/rsync-demo/src/ /tmp/rsync-demo/dst/
stat -c 'dst mtime=%y epoch=%Y' /tmp/rsync-demo/dst/report.txt

-a 是归档模式,但参数可以被后面的 --no-times 关闭。这个例子中,文件内容可能完全一致,只有 mtime 不一致;所以只用大小或打开文件看内容,无法证明时间属性也被保留。

用 --times 保留修改时间并确认结果

实际同步时可以直接使用 -a,或者在已有参数上明确写出 --times。后者更适合排查脚本,因为读命令的人不必再展开归档模式:

rm -f /tmp/rsync-demo/dst/report.txt
rsync -rltv /tmp/rsync-demo/src/ /tmp/rsync-demo/dst/
stat -c 'src epoch=%Y mtime=%y' /tmp/rsync-demo/src/report.txt
stat -c 'dst epoch=%Y mtime=%y' /tmp/rsync-demo/dst/report.txt

-t 就是 --times。日志中如果出现 t 属性变化,表示 rsync 正在更新修改时间;最终两行的 epoch 应该一致。对于目录本身,如果不希望同步目录时间,可以在需要时使用 --omit-dir-times,不要因此关闭所有文件的时间保留。

同一个时间戳为什么在两台机器上显示不同

ls -l 看到的时间是格式化后的本地时间。可以把检查命令固定成 UTC,或者直接比较 epoch:

rsync 跨时区验收中比较 epoch、UTC 显示与文件系统精度
跨机器验收时,把显示时区和真实时间戳分开检查。
stat -c 'epoch=%Y local=%y' /path/to/report.txt
TZ=UTC stat -c 'epoch=%Y utc=%y' /path/to/report.txt
date +%Z
timedatectl status

两台主机的 epoch 相同而格式化时间不同,问题在时区显示;两者 epoch 也不同,才继续检查 rsync 参数、目标文件系统和中间挂载层。不要用“看起来是昨天”替代数值验收。

低精度文件系统要调整比较窗口

rsync 默认按文件大小和修改时间做快速检查,时间比较精度默认是整数秒。复制到 FAT 一类只能稳定保存更粗时间精度的文件系统时,源和目标可能相差一两秒。此时可以使用:

rsync -rt --modify-window=1 ./src/ /mnt/usb/dst/
rsync -rtni --modify-window=1 ./src/ /mnt/usb/dst/

第二条命令用 -n 做试运行、用 -i 输出变更摘要,适合在正式同步前确认 rsync 是否还把文件当成有变化。这个参数是比较容差,不是把错误时间写回目标;如果目标文件确实落后很多秒,仍应先查挂载类型和同步参数。

一套可以留在脚本里的验收顺序

  1. 在源端和目标端分别运行 stat -c '%n %s %Y %y',记录路径、大小、epoch 和显示时间。
  2. 确认同步命令包含 -t--times,并检查脚本后面是否有 --no-times
  3. 跨时区场景固定用 epoch 或 UTC 输出,不拿 ls 的本地格式直接比较。
  4. 目标是低精度介质时,先用 --modify-window 做一次 -ni 预检,再决定是否重传。

如果内容和大小都一致、epoch 也一致,只是 ls 的日期格式不同,复制已经完成,不需要重复传输。相反,若 epoch 不同但命令带了 --times,就检查接收端权限、挂载文件系统能力和 rsync 两端版本。

常见问题:rsync 时间验收

rsync -a 还需要额外写 --times 吗?

通常不需要,归档模式包含保留修改时间的行为。但排查脚本时明确写 -t 更容易读懂;同时留意后续参数是否关闭了它。

为什么复制后 atime 变了?

--times 针对 mtime。访问时间受读取行为和挂载选项影响;如果业务确实需要保留 atime,要单独评估 --atimes 及其权限和文件系统支持。

两台服务器日期差一天就是 rsync 失败吗?

不一定。先比较 stat 输出的 epoch;epoch 一样只是时区显示不同,epoch 不同才进入参数和文件系统排查。

把“看起来不一样”变成可验证的结果

rsync 的时间问题不适合靠重新执行命令碰运气。用 --times 明确保留 mtime,用 epoch 排除时区干扰,再根据目标介质精度设置比较窗口,最后把 stat 和 rsync 的 dry-run 摘要留在发布或备份记录里,下一次出现同样症状时就能快速判断是显示差异还是实际属性丢失。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>