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 把时间格式化成当前机器的本地时区,同一秒数在不同主机上可能显示成不同的日期和小时。

默认复制为什么会留下传输时间
下面的实验先创建一个固定修改时间的文件。为了让结果可复核,命令不使用当前时间作为判断依据:
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:

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 是否还把文件当成有变化。这个参数是比较容差,不是把错误时间写回目标;如果目标文件确实落后很多秒,仍应先查挂载类型和同步参数。
一套可以留在脚本里的验收顺序
- 在源端和目标端分别运行
stat -c '%n %s %Y %y',记录路径、大小、epoch 和显示时间。 - 确认同步命令包含
-t或--times,并检查脚本后面是否有--no-times。 - 跨时区场景固定用 epoch 或 UTC 输出,不拿
ls的本地格式直接比较。 - 目标是低精度介质时,先用
--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 摘要留在发布或备份记录里,下一次出现同样症状时就能快速判断是显示差异还是实际属性丢失。
-
489 收藏
-
426 收藏
-
387 收藏
-
242 收藏
-
238 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习