生产在城市 A，容灾在城市 B，两边各跑一套对象存储集群。平时各写各的，真要切换才发现 B 的数据比 A 旧了半天，还得手工补。站点复制（Site Replication）要解决的正是这件事：把多套独立部署组成一套异步多站点复制关系，让桶、对象版本和 IAM 自动对齐，不用自己写同步脚本。
但要先把一件事说在前面，否则容易被误读成"两套都能随便写、写完了自动合并"：站点复制支持多站点接受业务写入，并不等于它替你做了冲突处理。官方确认的三条事实是：每个参与站点都必须支持桶版本控制，同步清单里含"对象版本，包括删除标记"，而复制是异步的。也就是说，同一个对象 key 在两地被先后覆盖时，两边各自产生新版本，再各自向对端复制，最后各留一份历史版本；官方没有说明这类冲突该按什么规则合并，也没有提供业务层的冲突消解。同一 bucket 的同名 key 尽量不要跨站并发写入，这条要写进应用的写入约束，而不是指望存储层兜底。
它和桶复制不是一回事。桶复制是单个桶上的定向规则（源桶 → 目标桶），站点复制是在整套部署之间建立更广泛的关系。更要紧的区别在写入方向：桶复制是单向的，想让两个桶互相复制，得在反方向再配一套目标和规则；站点复制面向的场景是"多个站点都要接受业务写入，同时保持存储和身份配置一致"。也就是说，两个站点都能写，写入哪边都会异步同步到其余站点，从站点不是只读镜像。把它理解成"主写从备"的异步主从拓扑，是这个功能最容易踩的第一个预期差，后面切流量、判冲突、算 RPO 都得按多站点可写的前提来设计。
站点复制同步什么
官方文档列得很清楚，站点复制在关联站点之间同步这几类资源：
- 桶与对象版本，包括删除标记（delete marker）。
- 桶元数据：站点复制工作流所需的桶级配置。
- IAM：用户、组、策略、策略映射、服务账号。
也就是说，在一边新建的桶、传的对象、建的 IAM 用户，都会出现在另一边。注意同步的是资源定义和对象数据，不是"站点互相接管流量"。
对象锁这一块要单独拎出来说，容灾场景里它比桶和 IAM 更容易翻车。官方在链接站点前的盘点清单里明确要求排查"存储桶名称、对象锁定设置、IAM 身份和策略"，对象锁定本身也是官方建议的启用前检查项之一。对象锁定文档里有两条更具体的说明值得抄进你的容灾手册：复制对象会在目标端创建新的目标版本，目标保留策略独立应用，不是把原版本的保留设置连带搬过去；另外锁定对象的复制目标必须支持兼容的对象锁定行为。还有一条硬约束：COMPLIANCE 保留在到期日之前既不能绕过也不能缩短，跨站点链路两端的时钟不同步会让两边的保留判定对不上。
桶元数据这一项官方写的是"站点复制工作流程所需的存储桶元数据"，范围是被限定过的，不是"所有桶级配置"。官方公开的同步清单里没有列生命周期规则和桶策略，这两类配置别默认会自动对齐到对端，切换前逐桶核一遍。
有一条硬前提：参与复制的每个站点都必须开启桶版本控制，否则链接会失败。
链接之前先满足这些条件
官方要求的清单不长，但每条都会在出问题时被人想起：
- 两个或更多独立的部署，且版本提供站点复制 Admin API。
- 每个部署有一个唯一且稳定的 S3 API 端点（端口通常 9000）。
- 各站点端点之间 S3 API 端口双向网络连通。
- 生产端点使用受信 TLS 证书；私有 CA 的话，先把 CA 装进管理主机的信任存储。
- 一台安全的运维机上装好 rc 客户端。
- 每个站点都有根管理员凭证，且都开启了桶版本控制。
还有一条容易踩：作为出站请求的安全控制，默认拒绝环回（loopback）复制目标。服务器选项RUSTFS_REPLICATION_ALLOW_LOOPBACK_TARGET=true官方明说只用于单主机开发和自动化测试，生产别开。
上一节的要求清单里有一条看起来像顺手加的、其实最该当真：链接已有站点前，要盘点两边的桶名、对象锁定设置、IAM 身份与策略，目的是发现冲突。这里要说清一个官方口径的边界，官方文档只提了"发现冲突"，没有说明冲突真的发生时是报错终止、覆盖还是跳过，这一块要按你自己的目标数据情况去验证，别照着"官方说会报错"的想象去做演练。真要上现有数据，先用两个空测试站点把整条链路跑通，再拿一个非生产副本做一次带冲突的预演。
双站点链路实操
先在 rc 里给两个站点各配一个别名，确认都通：
rcaliassetsite1 https://site1.example.com:9000<access-key-1><secret-key-1>\--regionus-east-1 --bucket-lookup path rcaliassetsite2 https://site2.example.com:9000<access-key-2><secret-key-2>\--regionus-east-1 --bucket-lookup path rc ready site1&&rc ready site2 rc admin info cluster site1 rc admin info cluster site2确认无误后，一条命令把两个站点链接起来。所有参与的别名一次性写进同一条命令，执行add命令的第一个站点是这套复制拓扑的管理控制点：
rc admin replicateaddsite1 site2 rc admin replicate info site1 rc admin replicate info site2 rc admin replicate status site1两个要点：超过两个站点时，把所有别名一次性写进同一条add命令，官方明确说不要用两两配对的方式去拼同一个多站点关系；状态检查从单个站点看到的只是该站点对关系的视图，不能替代对其他站点的检查。
这个"管理控制点"落到操作上就是一条硬约束：后续info、status、resync start、remove这些管理类命令，都要向第一个别名所在的那个站点发起，而不是随便挑一个站点。修复不可用站点后，按部署 ID 启动重新同步：
rc admin replicate resync start site1--site<deployment-id>--yes这里有一个官方专门加粗提醒的坑：重新同步状态不是实时进度。服务端返回的是最近一次启动或取消请求的持久化结果，它不检查活跃工作线程，生命周期状态报为未知；启动操作可能重叠，取消操作不幂等，网络超时还可能让执行结果变成未知。拿到不明确的结果后，先查replicate info、replicate status和目标数据，再决定要不要发下一个变更命令。另外官方也直说了：删除站点不会提供应用切换，也不能证明所有排队对象都已到达，remove之后数据缺没缺，得自己验。
边界与验证
站点复制有几个必须心里有数的边界，官方文档自己就放在页面开头：它是异步的，一个站点写成功不代表另一个站点已经拿到副本，别当强一致用；它不提供 DNS 故障转移、流量路由、应用恢复编排，这些都要自己规划，站点复制负责"数据和对齐"，不负责"切换"。
带宽这一块有个反直觉的地方值得提前知道：官方给限速旋钮的是桶复制，rc bucket replication add --bandwidth以及控制台里的 Bandwidth Limit 字段，站点复制那套rc admin replicate命令里没有对应的限速参数。跨城链路的带宽要按业务写入速率自己估，没有官方旋钮可以事后回调。官方给的判据不是拍脑袋的阈值，而是一条实测要求：应用写入速度可能超过异步复制，别从单个状态样本推断恢复点目标，要在实际工作负载下测延迟，并针对持续积压发告警，也就是说监控应该盯"积压是否在持续扩大"，而不是看某一刻落后了多少。
验证时别只信一条status。官方的验证路径是在一个站点建测试桶和对象，去另一个站点轮询，再比对内容：
rc bucket create site1/my-bucketprintf'hello rustfs\n'>hello.txt rc object copy hello.txt site1/my-bucket/hello.txt rc objectstatsite2/my-bucket/hello.txt rc object copy site2/my-bucket/hello.txt ./hello-from-site2.txtcmphello.txt hello-from-site2.txtIAM 也建议走一遍完整闭环：一个站点建临时用户、挂策略，另一个站点查用户和策略映射，验证完删掉临时身份：
rc admin useraddsite1 replication-test<temporary-secret-key>rc admin policy attach site1readonly--userreplication-test rc admin user info site2 replication-test rc admin policy entities site2--userreplication-test rc admin userrmsite1 replication-test真要切换的时候，站点复制给不了你什么
容灾演练写进 runbook 之前，先把三件官方没答的事摆到台面上，否则演练会变成碰运气。
站点宕机期间，其他站点不会自动补上那段写入。异步复制的语义决定了它不承诺这一点，官方给的动作只有一条：修复可用站点后启动resync。至于 resync 跑的是全量还是增量同步、要跑多久，官方文档没有给出明确口径。所以真实可用的做法只有一条：在自己的环境里实测一遍"断网 → 恢复 → resync"的完整链路，量出追平耗时，再把这个数写进 RTO；RPO 同理，别拍脑袋，用实测出来的落后时长去定。演练里任何"恢复即追平"的假设，在没量出这个数之前都不成立。
"把从站点提为新主"不在站点复制的命令集里。官方把 DNS 故障转移、流量路由、应用恢复编排明确划在站点复制之外。replicate edit能改的是站点名称、端点和 TLS 信任设置，切流量得靠你自己的 DNS 或负载均衡去完成，站点复制只保证数据最终到位。官方还有一句容易被略过提示：删除站点不提供应用切换，也不能证明所有排队对象都到了。
容灾前该做的准备，官方给了一份现成清单。对象锁定文档里那句"启用保护前，请在非生产存储桶中测试策略，并验证时间同步、权限、生命周期规则、复制和备份流程"，正好是站点复制场景下最该跑一遍的演练项，尤其是时钟，COMPLIANCE 保留在到期前无法绕过也无法缩短，两端时钟漂移会让"删除保护"在两地的判定结果不一致。
rc admin replicate add把多套独立部署连成异步同步关系，桶、对象版本、IAM 自动对齐，跨城容灾少写一堆同步代码。代价同样明确：故障转移和应用切换要自己补——它同步数据，不接管流量。先用两个空站点把 add、info、status、对象与 IAM 验证完整跑一遍再挂生产数据；把复制延迟和跨站点流量成本纳入监控，突发写入会临时落后，官方的建议是针对持续积压发告警，而不是看单次采样。
RustFS 已于 2026 年 9 月 16 日发布 1.0.0 正式版，站点复制的命令与边界均出自官方文档，代码在 GitHub 的 rustfs/rustfs 仓库，rc 客户端记得保持与服务器版本一致。
)
