服务器安全

备份不是复制文件：面向勒索、误删和 AI 误操作的恢复设计

只有经过恢复验证、与生产隔离的副本，才真正算备份。

备份像消防通道：平时看起来占空间，出事时才发现门后堆满纸箱，和没有通道没有区别。

复制命令返回 0、云盘显示同步完成、压缩包存在，并不能证明可以恢复。真正的备份必须回答：误删多久能发现、勒索软件能否一起加密副本、凭据丢失后能否解密、应用恢复到哪个一致时间点、谁知道重建顺序。

AI 自动化又增加了一类事故：不是恶意软件，而是工具在错误目录执行了正确命令，或者根据错误判断批量改写数据。面对这种风险，备份应该提供可回到过去的版本，而不只是把最新状态快速同步到另一个位置。

同步、快照和备份不是同一件事

同步追求两边尽快一致，因此源端误删和加密也会迅速传播。快照保存某个时间点，但如果与生产账户和存储处在同一控制面，攻击者可能一起删除。备份应该有版本、校验、独立凭据和不同故障域，最好至少有一份离线或具备对象锁。

CISA 持续建议维护离线、加密备份并定期测试可用性与完整性。离线不一定只能是拔下来的硬盘，也可以是生产凭据无法删除、具有保留策略的对象存储。关键是攻击者拿到生产权限后，不能顺手抹掉所有历史。

三份数据、两种介质、一份异地只是便于记忆的起点。真正要检查的是它们是否共享同一账号、同一密钥、同一云区域和同一自动化脚本。如果三个副本都由一个具有删除权限的 Key 管理，它们看起来分散，控制面却只有一个。

个人服务器可以采用：生产卷；本机只读快照或数据库导出；另一家云存储中的加密版本库；再加周期性离线副本。不是每份都要实时，恢复点目标可以按数据价值区分。博客文章每天备份足够，密码库和重要项目可能需要更短间隔。

直接复制正在写入的 SQLite 或数据库文件可能得到不一致副本。优先使用数据库自己的在线备份、dump 或快照协调机制。对容器应用，要同时保存数据、Compose、环境变量、上传文件、反向代理规则和恢复说明。只恢复数据库却缺少图片目录，博客仍然残缺。

备份脚本应明确失败策略。上传失败不能静默覆盖上一次成功标记；磁盘空间不足、校验失败和远端不可达应产生告警。保留每次备份的清单和校验值，能够区分“任务执行过”和“数据确实可读”。

最有价值的测试不是在原服务器解压一个文件，而是在隔离目录或临时主机，从文档开始重建。记录缺少的包、隐含路径、域名依赖、密钥位置和实际耗时。每次演练都会把存在脑子里的步骤转成可复制资产。

可以每月随机恢复一篇文章和一个配置，每季度恢复完整服务。恢复后不仅看容器是否 Up，还要访问页面、登录、上传文件、检查定时任务。恢复成功是业务行为恢复，不是文件数量相同。

AI 可以比较备份清单、解释失败日志、生成演练步骤和识别遗漏路径，但备份账户不应与日常 Agent 共用。让 Agent 默认只读查看版本和状态，删除旧快照、改变保留策略、覆盖恢复目标时必须人工确认。

恢复时也要防止 AI 依据不完整上下文选错时间点。先由人确定事故时间线和目标恢复点，再让工具执行机械步骤。恢复是一场外科手术，不是把最新压缩包倒回去。

灾难发生后最浪费时间的争论，往往是所有人同时抢救自己最熟悉的服务。个人服务器也需要恢复优先级：先恢复身份与 DNS 控制，再恢复反向代理和数据库，随后恢复核心应用，最后处理缓存、监控和可再生成内容。依赖关系要写出来，例如博客数据恢复了，但域名、证书和上传目录没有恢复，用户仍然无法使用。

为每个核心服务写一个最小可接受状态。博客可能是首页和管理登录可用，远程浏览器可能是画面、鼠标、键盘与下载都可用。明确验收标准，恢复就不会停在“容器已经启动”的假终点。