几乎每个运维过服务器的人，都听过或经历过同一个故事：一条写错的命令、一次没看清目录的删除、一个覆盖了生产库的迁移脚本，几秒钟就抹掉了几年的数据。真正区分「虚惊一场」和「灭顶之灾」的，从来不是运气，而是有没有一份可用的备份。

先分清快照和备份

很多人以为开了快照就万事大吉，其实两者作用不同：

  • 快照（Snapshot）：整机某一时刻的镜像，恢复快、适合系统升级或大改动前的「后悔药」。但通常和实例存放在同一基础设施上，粒度粗，不适合找回单个文件。
  • 备份（Backup）：数据文件级别的副本，可以存到别处，支持保留多个历史版本，适合应对误删、数据损坏和勒索软件。

结论：两者都要，且不能互相替代。

3-2-1 原则依然是最实用的框架

  • 3 份数据：生产数据 + 两份备份。
  • 2 种介质或位置：不要把备份和源数据放在同一台机器、同一块盘上。
  • 1 份异地：至少一份放在不同的服务商或不同地区，避免单点故障或账号问题导致全军覆没。

具体怎么落地

  • 数据库单独逻辑备份：直接复制数据目录常常拿到不一致的状态。用 mysqldump、pg_dump 等工具做逻辑导出，并压缩存档。
  • 用增量备份工具：restic、borg 等支持去重、增量和加密，长期保留多个版本的空间开销远低于每天完整拷贝。
  • 定时任务自动执行：用 cron 或 systemd timer 每日自动跑，人工手动备份必然会忘。
  • 加密后再上传异地：备份里往往包含用户数据和凭证，传到对象存储前务必加密。
  • 设置保留策略：例如日备保留 7 天、周备保留 4 周、月备保留 6 个月，避免存储无限膨胀。
  • 监控备份是否成功：静默失败的定时任务比没有备份更危险——你以为有，实际没有。给失败加上告警。

最关键的一步：定期演练恢复

这是绝大多数人跳过、却最不该跳过的环节。没有验证过恢复流程的备份，不能算备份。每季度花半小时，在一台临时实例上把最近的备份完整还原一次，确认数据完整、服务能起来、你还记得操作步骤。真正出事的那天，你要的是一份演练过的流程，而不是一堆没人打开过的压缩包。

SharkCloud 支持实例快照与灵活的资源配置，你可以随时开一台临时实例做恢复演练，用很小的代价换来「出事时真的救得回来」的确定性。