备份这件事最常见的失败方式不是备份失败，而是备份成功、文件也在，真出事的时候恢复不出来。整站压缩包只解决了"文件还在"这一半问题：数据库、密钥、版本清单、恢复步骤这四样东西不一起备，压缩包本身的价值会打折。Google 在讲恶意软件防护时也把这件事说得很朴素——把访问控制文件单独备一份，以便在它被破坏时用备份恢复，而且恢复完成后要记得把那份备份文件删掉，否则它自己就成了新的风险点。Google 关于预防恶意软件入侵的建议
一份整站压缩包解决不了什么
它解决的是文件，解决不了另外三件事。第一是数据：文章、页面、菜单、设置项、用户、订单都在数据库里，文件目录里没有这些。第二是身份：能登录后台的凭据是配置里的密钥与连接信息，丢了就得重新发邀请。第三是知识：这个站当时跑的是什么版本、装了哪些插件、依赖哪台主机的哪个设置——这些不在任何文件里。
还有个容易被忽略的前提：备份不只是你的事。站点跑在哪台机器上、机器本身有没有打上补丁，同样影响恢复结果。Google 提醒过，即便网站组件都在更新，主机商没装最新系统补丁时你依然可能是脆弱的；反过来也成立：你的备份再好，也补不了主机环境那一层。
该覆盖的五类东西
- 文件：wp-content 里的上传目录最容易被漏，它不在版本库里，也常常是最大的那一块。
- 数据库：定期导出一份，最好能落到站点之外的存储。
- 关键配置：wp-config 这类文件里的密钥与连接信息，单独加密存一份。
- 版本与依赖清单：核心、主题、插件的版本号，以及主机环境（PHP 版本、扩展）写下来。
- 恢复步骤：谁来做、先恢复哪一样、验证哪几个页面，写成别人也能照做的样子。
怎么把"能恢复"这件事做实
动作只有三个，但经常被跳过。一是定期演练：把最近一次备份真恢复到一个测试环境，跑一遍关键功能；不演练的备份只能算心理安慰。二是把恢复动作脚本化：WP-CLI 官方文档里列了不少这类日常操作，包括跨表做批量查找替换、在不同环境之间迁移数据库、轮换密钥、清理临时数据、重新生成缩略图，也可以把命令挂到计划任务或部署流程里。WP-CLI 官方文档对这类可脚本化操作的说明有了脚本，恢复就从"凭记忆操作"变成"跑一条命令"。
三是别手改数据库：WordPress 官方文档在讲常见漏洞时给的第一条原则是"有 WordPress 函数就用它"，理由是这些函数在处理数据时已经带了清理与转义；需要复杂查询时也该用官方提供的数据库方法，而不是自己拼语句。WordPress 官方关于常见漏洞与优先使用官方函数的说明恢复时同理：能用接口和命令完成的，就别开数据库客户端直接改表。
什么时候这份备份本身变成风险
- 备份文件放在网站目录下、且可以直接访问：谁都能下载，等于把数据库和密钥公开。Google 特意提醒过，成功恢复后要把这份备份删掉。
- 备份里带着旧密钥的会话凭据：会话状态是靠 cookie 维持的，RFC 6265 定义了 Cookie 与 Set-Cookie 这两个首部字段，服务端靠它们把状态存在用户代理上，从而在无状态的 HTTP 上维持有状态的会话——所以恢复一份带回旧配置的备份之后，原来有效的登录态可能仍然可用。
- 只有一份、存在同一台机器上：这不叫备份，这叫同一份风险存了两次。
- 包含真实客户数据的数据库被随手发给第三方：导出前先脱敏。
怎么验证这份备份真的有用
验证只有一个办法：恢复。四步——在测试环境恢复文件与数据库；用恢复出来的配置登录一次，确认密钥与连接信息都对；打开首页、一个列表页、一个表单页，确认页面输出与索引标记符合预期；最后把恢复出来的版本号与清单对照一遍，看跟出事那一刻是不是同一状态。整个过程要能重复，而不是靠一次侥幸成功。
把这套东西写进托管验收里，比事后补救便宜得多：WordPress 托管验收清单里的异地备份与安全运维项、托管报价里备份、迁移与运维分别怎么计价都能直接拿去对照；而真正要换环境时，换托管商时企业邮箱和询盘通知会不会跟着迁提醒的是容易被漏掉的那一半。
最后一句实话：官方没有公布任何"备份频率"或"多久必须演练一次"的要求，也没有承诺任何插件在被停用时会替你清干净它写下的数据。这两件事都得自己定规矩。
