独立站备份策略：全量增量、频率、存储位置与恢复演练
一、备份什么：数据库和文件要分开备
独立站备份要备两类东西：数据库和文件。数据库是WordPress的wp_posts、wp_options、wp_users这些内容，文件是wp-content/uploads里的图片、主题、插件代码。两类东西的变化频率和备份方式完全不同，混在一起备会出问题。
数据库用mysqldump或者wp-cli导出，每次导出要带–single-transaction参数，避免锁表影响线上。文件用rsync增量同步，只同步变化的部分，不要每次全量拷贝——一个10GB的wp-content目录，全量拷贝一次要十几分钟，增量同步只要几秒。
| 备份对象 | 变化频率 | 推荐工具 | 备份方式 |
|---|---|---|---|
| MySQL数据库 | 每小时可能变化 | mysqldump或xtrabackup | 每4小时增量binlog，每日全量dump |
| wp-content/uploads | 每周新增图片 | rsync | 每日增量同步 |
| 主题和插件代码 | 每月改几次 | git或rsync | 版本控制，每月全量 |
| wp-config.php | 极少变化 | 单独存密码管理器 | 变更即备份 |
| nginx/站点配置 | 每月改几次 | git管理 | 变更即备份 |
场景示例：一个用WordPress的工业装备出海站，每天新增3到5个询盘和2到3张产品图片。数据库用脚本每4小时导一次，文件用rsync每天凌晨3点增量同步到异地对象存储。一周下来数据库备份占约500MB，文件增量备份占约200MB，总存储成本每月不到20元。这个配置比装任何付费备份插件都可靠。
备份脚本怎么写，和环形山技术栈里的自动化运维思路一致：不依赖GUI插件，用cron加脚本，失败了发告警。
二、频率与保留策略：不是备份越频繁越好
反直觉的判断：备份不是越频繁越好。备份太频繁会占用大量存储和IO，而且恢复时反而更乱——你面对一堆差不多的备份，不知道哪个是干净的。合理的频率是按业务变化速度定：数据库4小时一备，因为询盘随时可能来；文件每日一备，因为图片上传不频繁。
保留策略用祖父-父-子三层：每日备份保留30天，每周备份保留12周，每月备份保留12个月，每年备份保留3年。这样你既能恢复到昨天误删的文章，也能恢复到半年前被黑前的干净版本。
| 备份类型 | 频率 | 保留时长 | 存储位置 | 用途 |
|---|---|---|---|---|
| 数据库全量 | 每日凌晨3点 | 30天 | 异地对象存储 | 日常误删恢复 |
| 数据库增量binlog | 每4小时 | 7天 | 本地+异地 | 精确到分钟的恢复 |
| 文件全量 | 每周日凌晨 | 12周 | 异地对象存储 | 周级回滚 |
| 文件增量rsync | 每日凌晨 | 30天 | 异地对象存储 | 日级回滚 |
| 月度归档 | 每月1号 | 12个月 | Glacier冷备 | 月度合规与长期 |
| 年度归档 | 每年1月 | 3年 | Glacier冷备 | 年度审计与历史 |
场景示例：一个出海站3月15日下午发现数据库被注入了恶意内容。有了binlog增量备份，可以把数据库恢复到3月15日中午12点——攻击发生前的状态，只丢半天的询盘记录。如果只有每日全量备份，只能恢复到3月15日凌晨3点，丢掉一整天的询盘。这就是4小时增量和每日全量的差别。
三、存储位置：3-2-1原则，异地是硬要求
3-2-1备份原则的意思是：重要数据保留3份副本，存在2种不同介质上，其中1份放在异地。这不是理论，是从无数次勒索软件事件里总结出来的。真实事故里，攻击者加密服务器的同时也会加密本地备份——因为备份和网站在同一台机器上。
三层存储怎么选：第一层本地备份，放在服务器另一个磁盘分区，恢复最快但抗风险能力最差；第二层异地对象存储，用AWS S3或阿里云OSS，跨可用区冗余，不怕单台服务器挂掉；第三层冷备归档，用S3 Glacier或OSS归档，便宜但恢复慢，用于年度合规和长期留存。
| 存储层 | 位置 | 恢复速度 | 成本 | 主要用途 |
|---|---|---|---|---|
| 本地磁盘备份 | 服务器另一分区 | 秒级 | 0元 | 日常快速恢复 |
| 异地对象存储 | S3/OSS跨区 | 分钟级 | 约0.02元/GB/月 | 主备份，每日同步 |
| 冷备归档 | Glacier/OSS归档 | 小时到天级 | 约0.005元/GB/月 | 年度合规与长期 |
| 离线介质 | 本地硬盘/磁带 | 物理取盘 | 一次性硬盘成本 | 极端勒索场景兜底 |
反直觉提醒：备份文件不要放在web目录下。很多人把备份放在wp-content/backup/，以为多了一份副本，实际上攻击者扫到这个路径直接下载，数据库名表名全泄露。正确做法是备份文件放到web根目录之外，或者备份完自动上传到对象存储并删除本地副本。被黑之后的清理流程见网站被黑之后。
和CDN全球加速配合时注意：CDN缓存不是备份，它只是把你的静态内容复制到边缘节点，源站挂了CDN缓存也会过期。不要把CDN缓存当成灾难恢复方案。
四、恢复演练：每季度一次，验证备份真的能用
备份策略里最被忽略的一环是恢复演练。很多企业备份脚本跑了一年，从来没恢复过一次，真到出事时才发现备份文件损坏、解压密码忘了、或者恢复流程根本跑不通。真实事故里，超过40%的备份恢复失败，原因都在这三类。
恢复演练怎么做：每季度选一个维护窗口，从异地对象存储拉一份最近的备份，恢复到一台全新的测试环境，跑通”恢复文件、导入数据库、配置nginx、访问站点、验证询盘表单提交”全流程。整个过程计时，记录实际RTO（恢复时间目标）和RPO（数据丢失量）。具体RTO/RPO怎么定见独立站灾难恢复与RTO/RPO定义。
| 演练步骤 | 动作 | 验收标准 | 常见失败点 |
|---|---|---|---|
| 1 拉取备份 | 从S3下载最近全量+增量 | 5分钟内下载完成 | 对象存储凭证过期 |
| 2 解压验证 | tar -tzf列出文件清单 | 文件数完整无损坏 | gzip包损坏，没校验 |
| 3 恢复文件 | 解压到测试环境web目录 | 权限正确755/644 | 权限丢失，站点白屏 |
| 4 导入数据库 | mysql < backup.sql | 表数和线上一致 | 字符集错误，中文乱码 |
| 5 配置nginx | 复制配置改端口 | 域名能访问 | 伪静态规则丢失 |
| 6 功能验证 | 走一遍询盘表单提交 | 邮件收到，CRM落库 | SMTP密码写死在配置里 |
场景示例：一个团队半年没做恢复演练，服务器硬盘坏了才去拉异地备份，结果解压到一半报错——原来三个月前备份脚本里的gzip参数写错了，后面两个月的备份全是损坏文件。最后只能从更早的干净备份恢复，丢了两个月的内容。这种事故只要每季度跑一次恢复演练就能提前发现。
备份监控怎么配，见站点监控与告警：备份任务失败要发企业微信告警，备份文件大小突降要告警，备份年龄超过24小时要告警。日常维护清单见官网维护期每月六件事。
FAQ 常见问题
独立站备份用什么插件，UpdraftPlus够吗？
备份频率定多少合适，需要每小时备一次吗？
3-2-1备份原则具体怎么落地？
恢复演练怎么做，多长时间做一次？
备份文件要不要加密，怎么存密钥？
备份脚本失败了怎么知道，怎么告警？
写在最后
备份这件事，最忌讳的是”装了插件就以为完事了”。插件每天跑，备份文件每天生成，但从没恢复过一次，真出事时才发现备份损坏、密码丢失、流程跑不通。备份策略一半是怎么存，另一半是怎么恢复——后者比前者重要十倍。
落地三步：第一，按3-2-1原则把三层备份搭起来，本地、异地对象存储、冷备归档各一份；第二，定好频率和保留策略，数据库4小时增量加每日全量，文件每日增量，保留30天到3年；第三，每季度跑一次恢复演练，在测试环境完整走通恢复流程，记录实际RTO和RPO。这三步做完，你才敢说自己有备份。
一句可以记住的话：没恢复过的备份等于没有备份——备份脚本跑一年不如一次完整恢复演练，真实事故里40%的备份在关键时刻打不开。