很多人的备份是这样的：什么时候想起来，什么时候手动导一次，放在同一台机器的另一个目录里。这样的备份能应付误删，应付不了磁盘故障，也应付不了整台机器被入侵的情况。判断备份是否可用，不看有没有备份文件，而看数据真的丢的时候能不能拿回来。
拿得回来包含三个条件：有一份完整的数据、有一份不会跟着一起坏掉的副本、以及知道怎么把它恢复回去。三个条件里最容易忽略的是最后一个，很多人直到出事那天才第一次尝试恢复。
所以做备份的第一件事不是选工具，而是先想清楚哪些内容丢了最要命。数据库、用户上传的文件、配置文件、证书和密钥，通常这几类排在前面，其余的可以往后放。
快照快，是因为它记录的是磁盘在某一时刻的状态，几乎不影响业务运行。适合在做重大变更之前留一个还原点：改数据库结构、升级版本、调整系统配置之前打一个快照，出问题几分钟就能回到变更之前。
边界也要清楚。多数快照和磁盘处在同一套存储里，存储本身出问题，快照一起没；拿到权限的人也可以顺手把它删掉。它防的是操作失误，防不了硬件故障，也防不了有意为之的破坏，所以不能当作唯一的备份。
更稳的做法是两条路一起走：随时能打的快照负责快速回退，定时的异地备份负责兜底。两者解决的问题不一样，少一个都会留下缺口。
频率取决于数据变化的速度。内容站每天更新一次，一天一份就够；订单和用户数据一直在动，可能要每小时一次。频率定得比实际需要高，除了占空间，还会让恢复时挑版本变得麻烦。
保留规则同样要提前定：最近几天的留得密集一些，时间久的按周、按月各留一份。定好之后就不用每次手动清理，也不会在磁盘告警的时候，慌乱中删掉最需要的那几份。
备份任务本身要能被看见。跑完了有没有成功、文件有多大、耗时是否正常，这些都值得记一条，或者至少在失败时有通知。定时任务最大的风险不是失败，而是失败了半年没人发现。
每隔一段时间，真正走一遍恢复流程：从备份里取出一份数据，恢复到一台临时机器上，确认网站能正常打开、数据能对上。这个过程能暴露很多平时想当然的问题，比如备份里少了某个目录、恢复脚本早就过期、数据库版本对不上。
演练还会顺手验证一个容易忽略的点：恢复要花多久。这个时间决定了业务中断的时长，也决定了出事时该选择回滚还是修复。事先没测过，就只能靠猜。
最后一点是权限。备份文件包含全部数据，等于把整个站点装进一个压缩包里，存放的位置、能访问的人、传输的方式都要单独考虑。放在公开目录里，或者随手共享一个下载链接，等于把最坏的情况提前准备好。
把备份放在同一台机器的另一个目录，是最常见的一种。磁盘出问题、系统被重装，两份一起没。
只备份数据库、不备份上传文件，恢复出来的页面图片全是空的，内容站的这种缺失往往比数据表更显眼。
文件按日期命名，却没有记录它对应的是哪个版本的程序，恢复时经常出现结构与代码对不上。
任务设置好了却没有通知，跑失败半年没人知道，直到真的要用才发现最近一份是半年前的。
把备份放在网站目录下面，等于给扫描器准备了一个可以直接下载的压缩包，这比不备份还危险。
还有一种是从没验证过，文件能不能解开、里面的数据是不是完整，全是未知。
这些情况的共同点是：过程看起来都在做，真需要的时候派不上用场。
把恢复的步骤写成一份简短的说明放在手边，真出事时按步骤走，比临时翻资料快。
演练不用太频繁，一年两次已经能覆盖大部分问题，关键是每次都真的走完。
备份和恢复这件事，最后考验的是有没有人完整地做过一遍。
售后客服
企业微信
