诚鑫致达 企业数据管家
群晖教程 企业数据管家

同步上云会丢哪些属性：Cloud Sync 各云文件属性支持差异与选型前核查

引言

把 NAS 和公有云接起来做同步，选型会上比的是价格和容量，真正决定日常体验的却往往是两个不起眼的字段：文件哈希与最后修改时间。它们直接决定 Cloud Sync 怎么判断「这个文件有没有变」——增量识别准不准、会不会重复上传、云端网页里看到的时间对不对。官方帮助的「各云支持的文件属性」页把各公有云对这两项的支持列成了矩阵，这篇把这张表读成三件事：看什么、为什么、上线前怎么核查。

什么场景用它最值

一是选型前评估：数据要上哪家云，先看属性支持与自身增量策略合不合。二是同步异常排查：同样配置换个云表现不同，根因常在这张表里。三是合规与审计口径：云端文件的「修改时间」在很多云上其实是「上传时间」，审计对时间线有要求的环境必须先知道这一点。

操作步骤

  1. 先建立读表框架：官方矩阵按平台列出「文件哈希」与「最后修改时间」两项支持度。哈希列看算法——多数对象存储类（Synology C2 Object Storage、阿里云 OSS、S3 存储、百度、Google Cloud Storage、hicloud S3、京东云对象存储、Azure 存储、腾讯云 COS、OpenStack Swift）提供 md5，Backblaze B2、Box、Microsoft OneDrive 提供 sha1，SharePoint Online 是 QuickXOR；Dropbox、Dropbox 团队协作空间、HiDrive、Microsoft OneDrive for Business、WebDAV、Yandex、MegaFon 之外的少数平台则为不支持（MegaFon MegaDisk 支持 md5）。为什么：哈希是 Cloud Sync 做一致性比对的依据，有没有、用什么算法，直接决定「高级一致性检测」这类功能的判据精度。

  2. 读「最后修改时间」列时注意一个官方约定：表中标记 O1 的平台（Backblaze B2、Google Cloud Storage、Azure 存储、OpenStack Swift），是「不允许更新最后修改时间、但为第三方应用程序提供自定义文件属性字段」——Cloud Sync 会把 NAS 上的修改时间存进这个自定义字段。为什么：这意味着在云端网页界面和其他同步客户端里，你看到的修改时间不会随之更新；数据如果将来从云端被第三方工具再搬一次，时间线可能断在「上传时刻」。做归档与审计规划时，这条要写进数据说明。

  3. 把「哪些云允许第三方真正改写修改时间」单独记一张小名单：官方注明仅 Box、Dropbox、Google 云端硬盘（含共享云端硬盘）、MegaFon MegaDisk 和 OneDrive 允许第三方更新最后修改时间——其他公有云服务上的「最后修改时间」始终是文件的上传时间。为什么：如果业务依赖「按修改时间增量/检索」，选云就该优先在这份名单里挑；名单外的云不是不能用，而是时间语义要先在流程里改叫「上传时间」，避免下游脚本按错误语义写逻辑。

  4. 核对哈希的例外条款再开一致性检测：官方列出——通过多部分上传到 S3 存储、阿里云 OSS、腾讯云 COS 或京东云对象存储的文件不提供哈希值；OpenStack Swift 的动态大对象、Backblaze B2 经 b2_upload_part 上传的文件不提供哈希；Google Cloud Storage 采用 md5 散列，因此不使用复合对象的 crc32。为什么：大文件恰恰走多部分上传，而大文件也正是最需要一致性校验的对象——知道这些例外，才不会把「该校验的没校验到」误当成「同步没问题」。

  5. 给百度云与 Azure 存储的用户画重点：官方明确，Cloud Sync 上传后会比对两边散列值确认一致性，而这两家在许多情况下会响应不正确的散列值，导致 Cloud Sync 误判「云端与 NAS 文件不同」，进而尝试保持版本一致并再次同步，造成重复下载相同文件。为什么：这两个平台上的「反复同步同一文件」类工单，第一嫌疑就是它——排查时别急着怀疑带宽和任务配置，先对照官方口径判断是不是平台侧散列响应问题，能少走很多弯路。

  6. 落两条工程结论进方案：其一，官方建议在网络和资源条件允许时，增加同时上传/下载数量可以提高同步性能；其二，由于文件系统限制，在 NAS 上修改数据后，云服务和 NAS 上该目录的最后修改时间可能不同。为什么：前者是吞吐调优的官方背书，批量同步前按链路质量调并发；后者提醒你「目录时间戳对不上」不一定是故障，目录级时间差异是文件系统层的正常现象，别为它重跑全量。

  7. 上线前做一次小规模核查：拿三五个典型文件（大文件、改过时间戳的文件、多部分上传形态）在目标云上试同步，逐一核对云端实际表现与矩阵预期是否一致，再放量。为什么：矩阵描述的是平台行为框架，你的桶类型、网关与帐户形态可能落在例外条款里——用小样本把「预期行为」钉死，比全量上线后再解释「为什么审计对不上时间」便宜得多。

三条边界先知道

  • 属性支持是平台能力，不是 Cloud Sync 的开关：NAS 侧始终维护完整属性，差异发生在云端落地形态——讨论「丢属性」时先分清是「云端不显示」还是「真丢了」。
  • 对象存储与网盘语义不同：S3/OSS/COS 这类对象存储与 Dropbox/OneDrive 这类网盘在哈希与时间支持上分属不同阵营，拿网盘的经验套对象存储（或反过来）是常见误判源。
  • 合规场景先问时间语义：等保或内审要时间线证据时，O1 型平台的自定义字段时间只有 Cloud Sync 自己认——取证口径要以 NAS 侧或导出记录为准。

结语

同步方案的成熟度，体现在对「边角字段」的掌控上。把各云的哈希算法、修改时间语义、多部分上传例外这几栏读透，选型有依据、排障有方向、审计有口径。贵州诚鑫致达科技在为客户设计 NAS 与公有云的同步链路时，会先按业务对增量精度与时间线的要求过一遍属性支持矩阵，再定云、再放量——先看懂差异，再谈同步策略。