灾难恢复文件传输：确保业务连续性

灾难恢复文件传输确保主站故障时业务持续运行——通过跨区域复制（S3 CRR、Azure GRS）、温备基础设施和有文档记录的故障切换手册实现。DR 就绪的文件系统持续将变更复制到次级位置，RPO 在秒到小时之间，支持在 RTO 目标内完成故障切换，并经过真实条件下的测试。最快上手 DR 的路径：选一个工作负载，复制到第二个区域，某个周六模拟区域故障，测量实际发生了什么。

按业务影响分类工作负载

不是每个文件系统都值得热热复制。业务影响分析按停机和数据丢失容忍度对系统分类：

Tier 0（关键任务）：支付处理、临床系统。RPO <1分钟，RTO <15分钟。
Tier 1（重要）：订单管理、面向客户的应用。RPO <15分钟，RTO <1小时。
Tier 2（较重要）：内部工具、报表。RPO <24小时，RTO <8小时。
Tier 3（标准）：培训材料、档案。RPO <1周，RTO <3天。

Tier 0 的复制成本是 Tier 3 的3-10倍。如实映射系统。大多数公司5-10%的系统在 Tier 0-1，应将投入集中在那里，而不是对所有系统平均加固。

复制拓扑

文件存储的三种主流复制模型：

主动-被动：主端写入，备端接收副本。故障切换需要提升操作。大多数区域 DR 方案采用。
主动-主动：两个区域都接受写入，带冲突解决机制。复杂度更高但 RTO 近零。全球系统采用。
基于备份：定期备份到备端。RPO 最高但最简单。Tier 3 采用。

S3 跨区域复制（CRR）实现主动-被动，RPO 在分钟以内。S3 多区域访问点增加故障切换路由。对于主动-主动，数据库层可用 DynamoDB Global Tables 和 CockroachDB；文件层，双向 rclone 加冲突解决标签是一种自建方案。

选择次级区域

主备区域应独立故障。经验法则：

不同地理区域（us-east-1 → us-west-2，而非 us-east-1 → us-east-2）
不同电网（美国东西海岸，欧洲不同国家电网）
在相关地区不同地质构造区（避免两个都在环太平洋火圈）

对于合规工作负载，两个区域都必须满足监管要求。GDPR 数据应留在欧盟——复制到巴黎对法兰克福或都柏林，而非弗吉尼亚。次级区域同样需要 HIPAA BAA。记录区域选择和原因；审计方会问。依据《数据安全法》（DSL）和 PIPL，中国境内的重要数据和个人信息的跨境复制需满足网信办（CAC）相关审批要求。

跨区域复制成本

复制有三个成本组成：

存储：主端成本翻倍（两个区域各保留一份）
数据传输：AWS 跨区域 CRR 约每GB 0.14元
请求费用：目标端的 PUT 操作

每月复制10TB，AWS 弗吉尼亚到俄勒冈约每月5000元。缓解措施：目标端复制到更便宜的存储类别（S3 Glacier Instant 而非 Standard），按前缀或标签过滤复制排除非关键数据，使用存储桶复制指标捕获失控复制。

故障切换手册

只存在于构想中的手册，就是失败的手册。生产就绪的手册涵盖：

触发标准：什么条件启动故障切换（区域状态页、应用健康检查、p99延迟超过阈值）
决策权限：谁做出决定（通常是工程副总裁加 SRE 负责人，预先批准自动触发的阈值）
步骤：按顺序的精确命令，带预期输出
验证：如何确认每步执行成功
回滚：故障切换本身引发问题时如何回退
沟通：状态页更新、客户通知、内部微信企业消息或飞书群组通知

S3 支撑应用的示例故障切换步骤：更新 Route 53，将 files.example.com 从主存储桶的 CloudFront 指向备用存储桶的 CloudFront。用 dig 和金丝雀上传验证。时间目标：10分钟以内。

DNS 与路由策略

DNS 通常驱动故障切换。选项：

Route 53 故障切换路由：基于健康检查的主动-被动自动切换
Route 53 延迟路由：流量到最近的健康区域
CloudFront 带源站故障切换：对客户端透明
带多区域后端的负载均衡器：可行但增加复杂度

TTL 很重要。300秒 TTL 的 DNS 记录在5分钟内完成故障切换；3600秒 TTL 需要一小时。将 DR 关键记录设置为 TTL 60-300秒，接受略高的 DNS 流量换取更快的收敛。

故障切换期间的数据完整性

复制延迟意味着备端略微落后于主端。故障切换可能丢失最近的写入。将 RPO 记录为预期的最坏情况丢失，并制定核对计划：

在应用层记录未提交的写入，使其可以重放
捕获进行中的事务，并从事件日志重放
明确接受数据丢失（对非关键数据，简单胜于复杂）

对于文件上传，被故障切换中断的分段上传可能在备端留下不完整的上传。在两个区域都配置 AbortIncompleteMultipartUpload 生命周期规则进行清理。

认真测试 DR

经过测试的 DR 计划和未经测试的 DR 计划是完全不同的东西。测试层次：

桌面演练：口头演练手册。每季度。
部分故障切换：切换一个子系统（比如仅文件服务）。每半年。
完整区域故障切换：在预定维护窗口切换所有内容。每年。
混沌工程：非预定的、模拟的、在工作时间进行。Tier 0 系统每季度。

记录所有内容。哪里出了问题。每步实际耗时多久。谁在需要时找不到文档。每次测试后改进手册。做了这些的团队有能正常工作的故障切换；没做的团队在真实事故中发现问题。

沟通渠道至关重要

事故期间，云内通信可能不可用。Slack 托管在同一个正在故障的 AWS 区域里，在关键时刻毫无用处。提前安排带外渠道：

托管在不同区域的备用通信工具（飞书或企业微信作为主要渠道，同时保有短信备用）
通过 Twilio 或 Telnyx 的短信桥接
作为最后手段的个人电话联络链
托管在主要基础设施之外的公开状态页（Atlassian Statuspage、StatusGator）

将渠道信息记录在物理手册中。演练切换到这些渠道。

在人与人之间传输恢复文件

当区域故障将人们锁定在正常协作工具之外时，传输特定文件——当前数据库转储、配置导出、事故响应手册——需要独立于你的基础设施运行的渠道。支持个人设备的工具在这时尤为有用。

HexaTransfer 在任何浏览器上都无需账户配置即可运行——当 SSO 服务商也宕机时，或外部响应顾问需要接收文件但尚未被纳入你的租户时很有用。端对端 AES-256-GCM 加密意味着即使在紧张的手动操作时刻也不会通过网络泄露密钥。

事后复盘

每次 DR 测试和每次真实事故都值得做无责任事后复盘（blameless postmortem）。记录：

事件时间线
什么起作用了
什么没起作用
根本原因（技术和流程）
带负责人和截止日期的行动项

追踪行动项直至完成。有20个行动项但零完成率的复盘，比没有复盘更糟糕——它向团队传递了改进无关紧要的信号。形成闭环，下一次事故就会比上一次处理得更好。

灾难恢复本质上是纪律。设定 RPO/RTO，持续复制，记录手册，每季度测试，带外沟通。技术是其中最简单的部分。

免费试用 hexatransfer.com——无需注册，单次最大10GB。