- 引言 —— 区域下拉框回答不了的那个问题
- 一家公司把自己的复制拓扑整个公开了
- 数据住的地方不是一处，是七处
- 选了可用性，就会失去驻留
- 管辖权附着在法人身上，而不是位置上
- 它怎么处理迁移，本身也是信息
- 该真正拿去问供应商的问题
- 把同样的问题回过头问自家系统
- 参考资料
引言 —— 区域下拉框回答不了的那个问题
你大概在安全评审文档里写过一行「客户数据存储于欧盟境内」。而支撑这句话的依据，往往只有一个事实：有人在供应商控制台的区域下拉框里选了 EU。
要确认这句话是不是真的，至少得回答七个问题。主副本在哪里。副本呢。备份呢。会被全局引用的元数据呢。日志呢。用于支付和客服的第三方呢。以及，当欧盟区挂掉时，你的客户端会连到哪里去。
Fastmail 在 2026 年 8 月 3 日发布欧盟数据区时写的那篇文章之所以有用，是因为它把这七个问题的答案全都写下来了 —— 连对营销不利的那些答案也一并写了。
这篇文章不是在推荐 Fastmail，而是在说：把那份文档当作供应商尽调的基线。
一家公司把自己的复制拓扑整个公开了
先看这家公司的构成。Fastmail 不租云，而是把自有硬件放进托管机房自己运维。按原文的说法，他们「连每台机器里装哪个型号的硬盘都指定」，并写道：在原有的费城和圣路易斯之外，他们按同样标准在阿姆斯特丹也装了服务器。
复制策略也原样写着。他们长期以来一直保持「每位用户的邮件，在主站点的不同服务器上至少两份，在地理上分离的站点再至少一份」。
这一句话里其实已经包含了答案。「维持地理分离副本」的策略和「数据只待在一个地区」的策略，不可能同时成立。 持久性的要求本身就把所在地变成了不止一处。
所以，一家开放欧盟区的公司能诚实说出口的句子，不是「你的数据在欧盟」，而是「主副本在欧盟」。Fastmail 实际上就是这么写的。
数据住的地方不是一处，是七处
把原文里对应欧盟区账号的项目整理出来是这样。
| 对象 | 位置 |
|---|---|
| 主副本（邮件与文件） | 阿姆斯特丹 |
| 地理分离副本 | 美国（按原文的说法是「目前来说」） |
| 灾备备份 | 费城（全体用户共用） |
| 全局复制的元数据 | 欧洲与美国两边 |
| 系统日志 | 美国（汇总在一处） |
| 第三方集成 | 与区域无关，完全相同 |
| 故障时的接入路径 | 美国站点之一 |
区域下拉框能改变的，只是这张表的第一行。剩下六行原封不动。
其中第四行尤其重要。原文把全局复制的对象具体列了出来：包含邮件地址在内的用户与客户元数据、网站及独立文件功能所用的存储、已连接第三方服务的详细信息。也就是说，它明确写着「每个人的数据都有一部分同时在欧洲和美国」。
你的系统里也一定有这个范畴：账号查询表、路由规则、功能开关、套餐信息。这些是因为延迟原因而放在全局的东西，也是在区域隔离设计中最晚被发现的东西。
选了可用性，就会失去驻留
原文里有这样一句话：「我们优先保证可用性。所以如果你的主站点宕掉，你会临时连到我们的其他站点，继续访问自己的数据。」
这是数据驻留设计中最常被忽视的一项取舍。
打不开邮箱，和数据短暂地跨了一趟大西洋，哪个更糟？对大多数用户来说，前者糟得多。所以大多数服务都会做同样的选择。只不过大多数不会把这个选择写进文档而已。
在合同里写下「数据不会离开欧盟」的那一刻，你其实同时承诺了在欧盟区故障时把服务停掉。你得确认自己是否准备好履行这个承诺，以及有没有把这项取舍照实向客户解释过。
邮件路由也有同样的问题。原文写道：如果你在自有域名上使用 Fastmail 的域名服务器，或者使用区域专用域名，收到的邮件会「优先」进入该区域的服务器；反之，如果用的是没有区域属性的通用域名，邮件就可能从任意一边进出。连接主机名也一样：通用的 IMAP 主机名会在内部被代理到当前活跃的服务器，想控制连接位置，就得使用区域专用的服务器名。
在设置界面里选了 EU，并不代表协议层的路径也变成了 EU。
管辖权附着在法人身上，而不是位置上
这是整份文档里最坦率的一段。
Fastmail 说明自家是澳大利亚法人，受澳大利亚法律管辖，其中包括澳大利亚与其他国家之间的司法协作条约。然后它写道：「无论数据存放在哪里，我们对相关当局的合法请求都会以同样的方式响应。」
紧接着的那句话值得引用：「如果你需要的是『数据只留在欧盟』这样一个保证，我们没有。与其让你去做这样的假设，不如直接说出来。」
数据驻留与数据主权，就在这里分道扬镳。
- 驻留是技术属性：硬盘在哪栋楼里。可以通过配置改变。
- 主权是法律属性：谁能强制要求交出这份数据。它取决于控制数据的法人受哪个国家的法律管辖，不会因为改了区域设置而改变。
哪怕把数据放在阿姆斯特丹的数据中心，只要运营这份数据的公司受另一个国家的法律管辖，那个国家的合法请求依然有效。如果你真的需要主权，需要的就不是一个区域，而是一个管辖权上相互分离的法人实体，或者是运营方无法解密的端到端加密。
它怎么处理迁移，本身也是信息
这是个细节，但从设计角度有可学之处。
Fastmail 写道，他们为账单地址在欧洲或附近的用户预先选定了欧盟区，在公告之前就把加密副本挪到了欧洲，并会很快把它提升为主副本。最近注册的用户被分配到了美国，可以在设置里更改。
而且它明确写出方向不同、代价不同：从美国迁到欧盟时，因为那边没有副本，所有邮件都得跨大西洋同步，所以慢；从欧盟迁回美国时，因为美国已经有副本，只需要对齐一致性，所以快。
这种不对称直接来自复制拓扑 —— 因为欧盟账号的副本在美国。知道拓扑，迁移成本就可以预测；不知道拓扑，就预测不了。 面对那些把跨区迁移说成「改一个设置」的供应商，把这个问题抛过去，回答的深浅立刻见分晓。
切换路径也有文档：在设置的 Users & Sharing 下的 Team Settings 里，GDPR 项目下面有一个数据驻留区块，可以看到等待中、传输中、已完成三种状态，并说明迁移过程中账号照常可用。
该真正拿去问供应商的问题
把上面的内容直接改写成问卷，就是下面这些。相当多的供应商只准备了前两三个问题的答案。
- 主副本存储在哪里？（几乎所有供应商都答得上）
- 活的副本在哪里？有几份？
- 备份在哪里？备份位置与主副本是否处于不同区域？
- 有没有与区域无关、被全局复制的数据？如果有，请给出清单。
- 日志存在哪里？日志里是否包含个人可识别信息？
- 支付、客服、错误追踪是否用到第三方？会传给他们什么？
- 主区域故障时请求会去哪里？那时数据会移动到哪里？
- 贵司是哪个国家的法人？会响应哪个管辖区的合法请求？
- 有透明度报告吗？
对话经常在第 4 和第 5 题就停住了。这不是因为供应商坏，而是因为销售团队里没有人知道这些答案。这些问题必须被转交给工程团队，而「拿到答案需要时间」这件事本身就是一条信息。
把同样的问题回过头问自家系统
最后，建议把这份问卷套到自己的系统上。通常是按下面这个顺序垮掉的。
日志是第一个。把应用日志按区域分开存放的组织很少见。可观测性工具的默认做法基本都是汇总到一处，而那些日志里含有用户标识、IP，有时还有请求体的一部分。
备份是第二个。为了持久性打开了对象存储的跨区域复制，然后就忘了这回事的情况很多。去确认一下它是不是还开着。
分析与错误追踪是第三个。从前端直接把事件发往外部 SaaS 的代码，会把后端的区域设计整个绕过去。
管理访问是第四个。就算数据在欧盟，如果运维人员从别的地区连进来查询，那次查询是在哪套规定之下进行的？这一项不是技术配置问题，而是访问控制与审计日志的问题。
Fastmail 那份文档之所以是好文档，是因为它在卖欧盟区的同时，先写下了「没有『只在欧盟』这样的保证」。你的安全评审文档也值得以同样的标准为目标。写一句守得住的话并写准确，远好过写一句守不住的话。
参考资料
현재 단락 (1/59)
你大概在安全评审文档里写过一行「客户数据存储于欧盟境内」。而支撑这句话的依据，往往只有一个事实：有人在供应商控制台的区域下拉框里选了 EU。