备份任务以绿色结束，只是一个说法。说法是：将来某个早晨，这些文件会变成一个能用的网站。在没有人等候的时候，我在一台临时机器上故意做过那个早晨之前，我不信这个说法。没测过的备份是您讲给自己的故事。您真正跑过的恢复，才是备份。
按计划恢复到空环境
临时环境不是生产，也不是编辑在用的 staging。它从空开始。备份是唯一的入口。我把它拉起来，登录，走一条出事时会要紧的路径：一笔订单页、一条还在数据库里的表单提交、一个应该在归档里而不只在旧磁盘上的媒体文件。然后我把这份临时副本丢掉。
如果那一步失败，我宁可在星期二知道，也不要在备份所针对的故障里才知道。常见的失败很无聊。数据库转储比 uploads 新。插件的一张表指向一个被排除的文件。归档假定的 PHP 版本，临时机器上没有。这些都不会出现在备份插件的绿色勾上。
更新需要退路
装一次更新很容易。带着退路去装，才是这项服务。之前一份快照，之后一次短的冒烟测试，测试失败就有书面的回退。说备份可以恢复，在您还没量过恢复要多久之前，那不是回退。我要的时长来自临时机器上的试跑，不来自插件的宣传册。
我在空副本上真正打开的东西
如果备份里有用户，请以真实用户登录，不要用安装时的管理员。打开一笔有状态、有总额、至少有一条备注的订单。打开含图片的页面，确认图片是归档里的文件，而不是指回生产环境的热链接。什么都不要提交。我在确认过去回来了，不是在一台用完即弃的主机上造一个新的现在。
我把耗时写在日期旁边。「上次恢复，18 分钟，卡在 uploads 归档，改了排除项，又跑了一次。」这句比监控徽章有用。有人问计划里有没有备份，我能用一个日期回答。答不出日期的计划，是带着发票的 cron。
如果我还没有恢复过任何东西，维护计划里的响应时间在第一天没有意义。我愿意写下来的计时，从基线、访问权限和一次成功的恢复之后才开始。在那之前，我还在弄清网站是怎么拼起来的。在那层雾里承诺当天答复，维护计划就会变成道歉。
问上次试恢复是什么时候跑的。回答之前的停顿就是回答。
维护不是一张为新功能敞开的标签
一份计划如果承诺监控、更新、恢复，再加上您之后想到的任何事，它的价钱是按幻想开的，或者幻想第一次到来时就要重谈。新页面、一次改版、一次迁移：那些各有范围。我愿意站在后面的计划更窄。网站继续做它已经在做的事。备份已经证实。一个人在写下来的时间内答复。这不如一份没有边界的月费好看。它也是一份您能核对的计划。
