问负责的同事系统有没有备份，回答通常是有，每天自动备。再问一句最近一次验证恢复是什么时候，多半答不上来。
备份的目的是能恢复，不能恢复的备份等于没有。判断备份做没做对，标准只有一条，真的出事时能不能把数据找回来，以及要花多长时间。
一、三条最低要求
第一条是异地或者离线。备份文件和数据库放在同一台服务器上，服务器坏了备份跟着一起没。放在同一个机房的另一台机器上，机房出问题一起没。至少要有一样是离开这台服务器、离开这个机房的，比如拷到移动硬盘或者传到另一处的存储。防止勒索病毒的话，还要有一份是离线的，因为在线存储往往会被一起加密。
第二条是频率对得上业务。每天改一次的数据，每周备一次就有六天的损失。判断标准是能接受丢多少数据，如果丢一天的数据业务就乱，那至少要每天备，重要的甚至要每小时或者实时同步。
第三条是保留多个时间点。只保留最新一份备份，万一数据是被慢慢改坏的，比如某个错误操作连续执行了半个月，最新备份里同样带着问题。保留最近三十天的每日备份，加上每月保留一份，是比较常见的做法。
二、必须定期做恢复演练
备份没用过，就不知道能不能用。文件损坏、权限不对、备份任务其实早就失败了但没人发现，这些问题只有恢复一次才会暴露。
建议每季度做一次恢复演练。找一台空闲机器，用最近的备份还原出完整系统，检查三件事，数据是不是完整的、系统能不能正常启动、恢复用了多长时间。第三点尤其重要，因为恢复时间直接决定了业务中断多久。
演练结果要记录，谁做的、用的哪份备份、恢复了多久、发现了什么问题。这份记录在真出事的时候，是能救命的参考。
三、备份之外还要防的几件事
备份解决的是数据丢失，但有几类事故它解决不了。
误删除和误修改。这类问题数据还在，是被改错了。如果保留多份历史备份，可以把受影响的时间段找回来。如果没有多份，就只能认了。所以前面说的保留多个时间点，很大程度上是为这类情况准备的。
账号被盗用后的大量篡改。这种情况需要配合操作日志来定位被改动的范围，然后从备份里定向恢复。没有操作日志，就不知道哪些数据被动过，只能整库还原，损失更大。
还有一种是业务逻辑本身造成的数据错误，比如某个计算规则写错了，跑出来的成批数据都不对。这类只能靠修正程序加数据订正，备份帮不上忙。要避免这类问题，靠的是上线前充分测试。
四、中小单位的最低标准
人手有限的情况下，可以按这个标准起步。数据库每天自动全量备份一次，保留最近三十天。每周把备份文件复制一份到另一台不同物理位置的设备上。每月手动导出一份放到移动硬盘，硬盘锁在柜子里。每季度做一次恢复演练并留下记录。
这套做下来，日常投入不大，但能覆盖绝大多数常见事故。等业务对中断时间的要求提高了，再考虑更复杂的方案，比如实时同步或者双机热备。不必要一上来就上最重的方案，那样往往维护不起来，最后变成摆设。