rsync时间戳错乱需校准时间或改用--size；云网关挂载点应禁用激进缓存、避免直接cp；异地续传须--partial+--append-verify并原子重命名；数据库热备不可直同步至网关，应本地打包后中转。
rsync 同步时文件时间戳错乱导致重复传输
rsync 默认用 --times 保存修改时间，但异地服务器时区或系统时间不同步，会触发全量重传。不是 rsync 本身坏了，是时间比对逻辑被干扰了。
- 同步前先校准双方时间：
ntpdate -s time.windows.com或启用chronyd - 若无法统一时区（如旧业务系统固定 UTC+8），改用
--size替代时间判断：rsync -av --size /data/ user@backup:/backup/ - 避免用
-c（checksum）模式——它强制计算每个文件的 MD5，跨千兆网络+TB 级数据时 I/O 和 CPU 开销陡增
云存储网关挂载后 ls 卡顿、cp 失败
这类问题几乎都出在网关对 POSIX 语义的模拟缺陷上，尤其在元数据操作（如 stat、readdir）环节。对象存储本质不支持“快速列目录”或“精确文件大小预读”，网关强行桥接就会卡。
- 确认挂载参数是否禁用缓存：
cache_timeout=600比默认值更稳；避免设成0（完全禁用缓存）导致每次ls都走 HTTP 请求 - 不要直接在挂载点执行
cp -r：对象存储不支持原子重命名，大目录复制容易中断且残留临时文件；应改用网关提供的 CLI 工具（如cloudsync upload）或 rsync over SSH 到网关本地中转目录 - 检查网关日志里是否有
ENOTSUP或ETIMEDOUT错误——这说明底层云 API 返回了不支持的操作，得查对应云厂商文档确认该网关版本是否支持你用的 bucket 权限策略
异地备份链路中断后如何安全续传而不破坏一致性
断点续传不是 rsync 自动解决的，它只保证单次运行的文件级一致性。数据库备份文件（比如 pg_basebackup 生成的 tar 包）一旦被截断，整个包就不可用。
- 永远用
--partial+--append-verify组合：前者允许保留已传部分，后者在续传时校验已有块内容是否匹配 - 对数据库备份文件，加一层原子性保护——先同步到带
.tmp后缀的临时名，传输完成后再mv重命名；恢复端只认不含.tmp的文件名 - 别依赖网关的“自动重连”：某些网关在连接闪断后会静默切换 endpoint，但挂载点内核态缓存未刷新，导致后续
write()返回成功实则丢数据；建议配合inotifywait监控/proc/mounts中对应挂载行是否存在
为什么不能把数据库热备份目录直接 rsync 到云网关挂载点
因为多数数据库（PostgreSQL / MySQL InnoDB）的热备份要求文件系统具备强一致性语义：写入顺序、fsync 可见性、硬链接支持。而云存储网关挂载点本质是 FUSE 层+HTTP 客户端，不保证这些。
- PostgreSQL 的
pg_basebackup输出含大量硬链接（指向相同物理块），网关通常不支持硬链接透传，会导致备份体积暴增数倍 - MySQL 的
mysqldump输出是纯文本，可以安全同步；但xtrabackup生成的.qp或.xbstream流式文件，若网关对 partial write 处理异常，解压时直接报invalid header - 真正稳妥的做法：在本地完成热备份 → 用
tar --format=posix打包 →gzip -1压缩（兼顾速度与压缩率）→ rsync 到中转服务器 → 再由中转机推送到云存储（避开挂载点）
