“我们有备份”这句话，在出事之前都是对的。
真正的考验是那一天：网站被改坏了、被入侵了、或者某次更新之后打不开了。这时候有三个问题决定损失有多大——备份到哪一天、恢复要多久、谁会操作。
这三个问题，多数人是在需要的时候才第一次想。
先分清两种事故
它们需要的东西不一样。
一类是”改坏了”。改了模板、装了插件、动了配置，网站出问题。这类事故你知道大概什么时候发生的，需要的是回到几小时前。
另一类是”被搞了”。被入侵、被加了恶意代码、数据被删。这类事故你可能几天后才发现，需要的是回到一个确定干净的时间点——而且要能判断哪一天还是干净的。
只有每天一份、只保留最近三天的备份，能应付第一类，应付不了第二类。
备份要包含什么
一个完整的网站备份有三部分，缺一份就恢复不了：
文件。程序代码、模板、图片、上传的文档。
数据库。文章内容、页面、设置、用户、订单。这一份最关键——文件丢了可以重做，数据库丢了内容就真的没了。
配置。服务器设置、DNS 记录、证书配置、定时任务。这一部分最常被漏掉，因为它不在网站目录里。
很多”自动备份”只备份了前两项。等到需要在一台新服务器上恢复的时候，才发现要花几个小时重新配环境。
保留策略：不是越多越好，是分层
合理的做法是分几档保留，而不是简单地”每天备份，保留 7 天”：
最近几天：每天一份。应付”改坏了”这类事故，最常用。
最近几周：每周一份。应付”上周好像还是好的”这类模糊的时间判断。
最近几个月：每月一份。应付潜伏很久才被发现的问题。
这样占用的空间不大，但覆盖的时间跨度长得多。只保留一周的备份，遇到一个两周前被埋下的问题就完全无解。
备份放在哪
一条规矩：备份不能只存在被备份的那台机器上。
这听起来显然，但相当多的网站备份就放在网站服务器的一个目录里。服务器出问题、被入侵、被误删的时候，备份跟着一起没了。
入侵的情况尤其明显：拿到服务器权限的人，第一件事往往就是删掉备份，让你只能付赎金或者认栽。
所以备份至少要有一份在别的地方——另一个服务商的存储、云盘、甚至定期下载到本地。位置不同比份数多重要。
最容易被跳过的一步：试一次恢复
这是整篇里最重要的一句话：没试过恢复的备份，不算备份。
常见的失败，全都是在真正需要的时候才发现的：
备份文件是损坏的，一直在生成但从来没打开过。数据库备份不完整，缺了某些表。备份里的配置和现在的环境对不上，恢复了跑不起来。压缩包设了密码，而没人记得密码是什么。恢复流程需要某个只有前一个技术人员知道的步骤。
这些问题都只有真正跑一遍恢复才会暴露。建议每半年演练一次：找一个测试环境，从备份完整恢复一遍，记录花了多长时间。这个时间就是你真实的恢复能力。
回滚和备份不是一回事
备份是”恢复到某个时间点”，回滚是”撤销刚才那次改动”。后者应该更快、更精确。
如果你的网站代码在版本控制里，回滚是一条命令的事，而且能精确回到某一次改动之前，不影响这期间新增的内容。这比从备份恢复整站好得多——从备份恢复会把这期间客户提交的表单、新发的文章一起退回去。
所以两者要分开准备：代码用版本控制，内容和数据用备份。大部分事故是代码或配置引起的，能用回滚解决的就不要动备份。
我们自己的流程里，任何改动落地前先做语法检查、装完自动验证关键页面、所有代码在版本控制里。这三道防护都是被真实事故逼出来的。
该问服务商的五个问题
如果你的网站有人在维护，这五个问题值得问一次，答案应该是具体的：
多久备份一次，保留多久？“定期备份”不是答案。
备份存在哪，和网站是不是同一台机器？
包不包括数据库和服务器配置？
上一次实际测试恢复是什么时候？这一问最能看出真实水平。
如果现在要恢复，多长时间能好？要具体到小时。
答不上来不一定说明有问题，但说明这件事没被认真想过。而备份这件事的特点是：平时完全看不出差别，出事那天差别就是全部。
我们托管的项目里备份是分层保留、异地存放的，恢复流程有文档。这一项写在服务内容里，不是出事之后才谈的。