云端邮件备份与本地归档：谁能访问副本？

一旦有人接受了“收件箱不是备份”这件事 — 它确实不是，我们详细论证过这一点 — 接下来的本能反应通常是再找一个云产品来补救：一个第三方备份服务，接上 Gmail 或 Microsoft 365，把一切持续复制到它自己的服务器上。感觉像是把问题解决了。从结构上看，这更接近于把问题挪了个地方。

云到云备份可以创建独立的恢复副本，但也增加了一项需要评估的服务和访问授权。保留多久、谁能读取副本，取决于其配置、加密和合同。

云备份服务商实际掌握着什么

大多数云邮件备份产品背后的架构很直白：服务通过 API 或协议级访问直接连上你的邮件服务器，复制每一封邮件和附件，并把这份归档存在备份服务商自己运营和管理的服务器上 — 不是你的。这就是它全部的价值主张；同时也是它全部的风险面。

持续更新的备份可能保留不断增长的邮件历史。请评估服务的委托权限、保留期限、加密密钥和恢复控制，并了解撤销访问或订阅结束后的处理方式。第二份副本可以提升恢复能力，同时也会带来不同的访问风险。

这些都不意味着云备份服务商疏于职守或者做得不好。靠谱的公司在安全上投入很认真。这里说的是结构问题，不是对某家具体公司的评判：把敏感数据的更多副本，集中到更多由其他组织控制的地方，出错的路径就会变多，无论每一方各自执行得多好。

真正重要的那个问题

评估任何一种邮件备份方案时，要问的不只是“别处有没有一份副本”。而是：谁能读到那份副本，以及能读多久？

能否访问取决于服务的加密方式、密钥归属和权限。持有解密密钥的提供商可能能够访问存储的邮件；正确实现的客户端加密备份可以限制这种访问。请检查具体服务的政策、删除条款和恢复流程，不要假定所有云端副本都可由服务商读取。

本地副本依赖设备安全、磁盘健康、物理访问和备份安排。MailVault 邮件文件本身并非加密保险库。请启用磁盘加密，并保留经过测试的独立备份；如果文件位于云同步文件夹中，该服务也会成为存储安排的一部分。

本地备份还能扛住更多状况

除了访问权的问题，本地副本还能扛住一串具体的失败情形，而云到云的备份并没有真正解决它们：备份服务商涨价或者关停，备份服务商自己的服务偏偏在你要恢复时宕机，因为一张卡过期而导致订阅失效，或者服务商把条款改成一个你今天不会同意的方向。你磁盘上的一个文件没有订阅状态。它就在那儿。

MailVault 的做法不一样在哪里

MailVault 连接你现有的 IMAP 或 OAuth 邮箱账户，把每个文件夹都归档成一个个独立的 .eml 文件 — 直接写到你自己的磁盘上。中间没有一台由 MailVault 运营、存着你邮件副本的服务器。我们读不到你的归档，因为我们从来就没收到过；连接发生在你的设备和你的服务商之间，产生的文件只存在于你放它们的地方。 这些文件结构说明适用于默认的 Maildir 格式。设置 → 存储还提供 JMAP 存储，将原始邮件字节与 JSON 记录一起保留，并对相同邮件去重。

格式同样重要：.eml 是支持 EML 的邮件应用可以读取的简单开放标准，而非将归档绑定到单一软件或某家公司存续状态的专有数据库。 手动的、不限次数的本地备份是免费的，就这么简单。 不用你记着去点一下、自动让归档保持最新的定时备份，是 $4/月 或 $25/年 的 Premium 功能 — 年付方案含 14 天试用。

延伸阅读：挑选 IMAP 备份工具究竟该看什么、如何把 IMAP 邮件归档到本地，以及Mac 上的 MailStore 替代品。