大多数 WordPress 站主都有备份，但几乎没有人拥有真正测试过的备份。这一差别会在最糟糕的时刻——需要用到备份的那一天——残酷地暴露出来。本文讲述一个真实案例，来自近期悉尼一家代理机构的事件：备份问题差点把一次艰难的恢复变成一场准灾难，以及我们做了哪些改变来确保它不再发生。
事件经过
这家代理机构在同一台共享主机上运营着一组小企业客户网站。其中之一——代理机构自己的网站——被攻破了。一次 SEO 隐藏（cloaking）攻击悄悄在文档根目录中植入了恶意文件，用攻击者控制的内容模仿真实的 WordPress 页面名称。一旦确定了入侵入口，清理本身并不复杂。更难的部分是决定要回滚到多久以前。
取证分析表明，攻击者在被发现前至少已在网站上潜伏了数周。出于稳妥考虑，恢复方案要求从疑似入侵日期之前的备份进行还原。入侵前的基线越干净，某个隐蔽后门在清理后残留的概率就越小。
第一个意外
备份插件是在两年前网站上线时安装并配置好的。计划是每日备份数据库、每周做完整备份，两者都上传到一个异地云存储账户。当代理机构负责人去取事件发生前六周的备份时，得到的答案却令人不安：云存储中最新的备份是十二个月前的。
备份插件已经静默失败了至少一年，代理机构却毫不知情。有关失败的通知一直发往一个早已无人查看的邮箱地址。没有人想到去检查目标存储，以确认文件是否真的送达。这套系统悄然损坏的时间，远比真正的安全事件要长得多。
第二个意外
代理机构转而求助主机商作为退路。许多托管主机会保留自己独立于任何插件的备份。在本例中，主机商的备份保留期为 30 天。而入侵被怀疑始于被发现前约 45 天。主机商的备份都落在入侵窗口之内，而非之前。
主机商能提供的任何备份，都极有可能包含攻击者的文件。用它们来还原，只不过是把计时器重新归零。根本没有一个干净的、入侵之前的还原点可用。
真正奏效的恢复路径
在没有任何干净备份的情况下，恢复只能逐个文件地进行。把当前网站的取证快照与全新下载的 WordPress 核心逐一对比，主题文件在有版本控制的地方与之核对，插件从其官方来源重新安装、而非从被攻陷的代码库中沿用，数据库则在不回滚的前提下清除已知的恶意模式。
这比一次简单的还原多花了数倍时间，每一步都必须核验。总成本相当可观，而且由于最新可核验的主题代码来自几个月前的一次导出、而非线上实时状态，网站上的若干改进也随之丢失。清理最终成功了，但成本远高于本应付出的水平。
新的备份方案
事件之后，这家代理机构改用了我们在所管理的 WordPress 网站上采用的备份方案。其中的细节很关键，因此值得具体说明。
每日对文件和数据库进行增量备份，每周进行完整备份。所有备份都存放在异地、一个 WordPress 网站本身无法访问的存储账户中，这样一次入侵就无法把备份连同线上网站一起抹除。
保留期设置为备份至少可用 90 天。这样即使面对缓慢潜伏的入侵，也能有一个干净的、入侵之前的时间窗口。
备份失败的警报通知会发往一个有人监看的企业收件箱，而不是个人邮箱。两个人同时接收警报，这样单独一个人休假也无法掩盖一次失败。
每季度会在预演（staging）环境中执行一次还原测试。下载备份、进行还原，并与线上网站核对。如果发现任何问题，都会在下一季度到来之前修复。
你今天就能做的事
如果这个案例让你感到不安地熟悉，下面是一份本周就能逐项完成的简短清单，每一项都只需几分钟。
登录你的备份所存放的那个目的地，无论它是什么。确认最新的文件是今天或昨天的；确认过去 90 天里文件一直在稳定地送达；打开本应接收备份失败通知的邮箱地址，确认它仍然有人监看。
挑出最新的备份，把它下载下来，尝试将其还原到一个预演站点或本地环境。确保它真的能作为备份使用，而不仅仅是一个文件。
检查你主机商的备份保留期。保留窗口是否足够长，能覆盖一次缓慢的入侵？如果不够，就用一个保留期更长的异地方案来补充。
原则
一份备份只有在你成功还原过之后才是真实的；在那之前，它只是一个猜测。测试的成本很小，而以惨痛方式才发现问题的代价，却大到足以威胁恢复本身。把备份验证当作日常流程的一部分，而不是某天有空才去做的事。
需要帮忙吗？
如果你的 WordPress 备份方案存在漏洞，Defyn 可以对其进行审计，建立可靠的、具备适当保留期的异地备份，运行一次还原测试来验证它确实有效，并确保警报发送给真正会看到它们的人。与我们联系，我们会为你提供一套你真正能够依赖的备份方案。
