网站备份的三二一原则 怎么落到具体配置

"三二一"是备份领域的经典原则：至少三份数据、存在两种不同介质上、其中一份在异地。原则不复杂，难的是在有限预算里落地。

一、三份副本怎么分

第一份是生产数据，也就是正在跑的数据库和文件。第二份是本地备份，放在同一台服务器的另一块盘或另一目录。第三份是异地备份，放在对象存储或另一台服务器。

很多人的做法是"每天备份到服务器 /backup 目录"，这只有两份，而且同一台机器——服务器挂了，两份一起没。

二、两种介质怎么选

介质可以是：本地 SSD、机械硬盘、对象存储、磁带、云盘。中小企业实际可选的就三种：服务器磁盘、对象存储、另一台服务器。

建议组合：服务器磁盘（快速回滚）+ 对象存储（长期保留、成本低）。如果要更稳，再加一个不同云厂商的存储桶。

三、一份异地怎么落地

异地的意义是防"区域性事故"和"账号级事故"。同一个云账号下的两个桶，不算真正的异地——账号被盗或欠费，两个桶一起停。

低成本方案：主站在阿里云，备份同步到腾讯云 COS 或七牛。跨厂商，账号独立，成本每月几块钱。

四、频率与保留

这个策略下，最坏情况会丢失一天的数据。如果业务不能接受，就要做增量备份或数据库主从。

五、备份的四个技术要求

1. 完整性：数据库导出要包含所有表，文件要包含上传目录。备份后用工具校验压缩包是否可解压。
2. 可恢复：恢复流程要写下来，任何人照着能操作。别只有一个人会。
3. 加密：备份文件里可能有客户信息，上传对象存储前加密。
4. 隔离：备份目录不能通过 web 访问。放在 web 根目录之外，或用对象存储的私有读。

六、验证机制

三层验证，缺一不可：

• 自动检查：备份任务执行后，检查文件大小是否在合理区间（比如数据库备份不应小于 1MB）。异常则告警。
• 月度抽检：每月随机挑一份备份，解压看文件是否完整。
• 季度演练：完整恢复一次到测试环境，记录耗时和问题。

没有验证的备份，只是心理安慰。

七、几个真实事故

我处理过的三次数据事故，原因分别是：磁盘写满导致 MySQL 崩溃且备份任务静默失败；运维误删数据库且本地备份同盘；服务器被入侵，攻击者删了备份目录。

三次的共同点：备份"看起来有"，实际不可用。所以这篇反复强调验证和异地，不是啰嗦。

备份也要防"内部误操作"

相当一部分数据事故不是黑客，是误删、误覆盖、误执行 SQL。所以备份要能支持"按时间点恢复"，而不只是"恢复到最新"。

保留七份日备的意义就在这里：发现数据错了，可以退回到出错前一天，而不是在错误数据上继续修补。

备份也要防内部误操作

相当一部分数据事故不是黑客，而是误删、误覆盖、误执行 SQL。所以备份要能按时间点恢复，而不只是恢复到最新。保留七份日备的意义，就是发现数据错了还能退回前一天。

每月做一次恢复演练：从备份里恢复一个栏目或一张表，确认文件能打开、数据完整。只备份不演练，真出事时很容易发现备份本身是坏的。

异地备份不要和主站放在同一个服务商、同一个账号下。账号被盗或欠费，两份一起没。至少一份放在你控制之外的存储里。

备份文件要定期恢复一次，确认能打开；只备份不演练，等于没有备份。

备份文件每季度恢复一次，确认真的能用。

常见问题

小网站也要这么复杂吗

可以简化成两层：每天数据库备份到本地 + 每周同步到对象存储。成本每月不到十块，但能救命。

快照算备份吗

算一种，但粒度粗、成本高、恢复慢。适合系统级灾难，不适合误删单篇文章这种场景。

备份文件要保留多久

至少三个月。有些问题（比如被挂马）几个月后才发现，需要回溯到感染前的版本。

备份之外，服务器层面的防护见服务器被攻击后的应急处理。