先讲个让人心疼的真事

去年底，昆山有家做电子代工的企业，网站运行了六年，积累了两千多篇产品技术文档和几百个客户案例。服务器硬盘坏了，没有备份。六年内容，全没了。老板找了好几家苏州的建站公司想恢复，最后只从百度快照里找回了不到30%。重建网站花了3个月，那段时间新客户搜不到他们的产品，老客户也找不到技术资料。算下来这一块硬盘的故障，直接间接损失超过20万。备份这件事，不出事的时候觉得没必要，出了事就是救命稻草。但备份也不是"复制一份"这么简单，得有策略。

备份什么：不只是数据库

很多人理解的备份就是导出数据库。不够。一个网站需要备份的东西有四块：数据库、网站程序文件、配置文件、上传的附件。数据库存的是文章内容、产品信息、用户数据、订单记录。网站程序文件是你的模板、控制器、模型代码。配置文件包括数据库连接信息、Nginx/Apache配置、PHP配置。上传的附件是产品图片、PDF资料、客户上传的文件。这四样缺了哪个，恢复的时候都会缺胳膊少腿。苏州工业园区一家做工业自动化设备的公司，有次服务器故障后只恢复了数据库，发现产品图片全丢了——因为图片存在另一个挂载盘上，备份脚本没覆盖到。所以第一步，搞清楚你网站所有数据的存放位置，别遗漏。

备份频率：多久一次合适

看你的更新频率。纯展示型网站，一个月更新一两次的那种，每天备份一次数据库就够了。电商网站、资讯网站、有用户互动的平台，数据库变化频繁，建议每小时增量备份+每天全量备份。太仓有家做精密机械的德资企业，官网带产品询盘功能，每天大概有20-30条询盘数据。他们设的是每2小时备份一次数据库，万一服务器挂了最多丢2小时的数据，可以接受。频率不是越高越好，备份也消耗服务器资源。高峰期跑备份脚本可能影响网站响应速度。建议把全量备份安排在凌晨2-4点，那个时段流量最低。

3-2-1原则，记住这个就够了

备份行业有个经典原则叫3-2-1：3份数据，2种介质，1份异地。翻译成大白话就是：你的网站数据要有三份拷贝，存在两种不同的存储介质上，其中一份放在异地。具体怎么落地？第一份：服务器本地备份，用定时任务每天打包，存在服务器的另一个磁盘上。恢复最快，但如果服务器挂了这份也没了。第二份：同云厂商的对象存储，比如阿里云OSS。设置生命周期规则，30天后自动转低频存储，90天后转归档存储，省钱。第三份：跨云备份。苏州本地有家企业把数据库备份同时传到阿里云OSS和腾讯云COS，两朵云同时挂掉的概率基本为零。整个方案的成本：OSS标准存储50GB以内每月不到10块钱。你一个月花20块钱买三份备份，这笔账怎么算都划算。

自动备份脚本怎么写

以最常见的LNMP环境为例。写一个Shell脚本，做这几件事：导出MySQL数据库，打包网站根目录，加上时间戳命名，上传到OSS，删除本地7天前的旧备份。用crontab定时执行。代码不复杂，30行左右就能搞定。不会写？让建站公司帮你配，一次性的活儿，收费不超过500块。关键是要验证脚本真的在跑。苏州吴中区有家做机器人集成的公司，运维设了备份脚本但从来没检查过，半年后网站出问题才发现脚本第一天就报错了，半年的备份全是空的。所以：备份脚本上线的第一天，手动跑一遍确认没问题；之后每周看一次备份日志有没有报错；每月做一次恢复测试。

恢复演练：不做等于没备份

备份做了但从来没恢复过，等于没做。你不知道备份文件是否完整，不知道恢复流程要多久，不知道有没有遗漏。建议每季度做一次恢复演练。找一个测试环境，把最新的备份文件恢复进去，检查网站能否正常访问，数据是否完整。记录恢复耗时。 BioBay有家生物医药初创公司，每季度做一次恢复演练，第一次演练发现备份里少了配置文件，花了2小时手动补上。如果真出事那天才发现这个问题，停机时间就不是2小时了。把恢复流程写成文档：第一步去哪里取备份文件，第二步怎么导入数据库，第三步怎么恢复网站文件，第四步怎么验证。运维人员离职了新人也能照着做。说白了，备份不是技术问题，是管理问题。花一个下午把这套流程搭好，后面自动运行，你的网站就多了一层保险。苏州中小企业的数据量没那么大，备份方案不需要搞得复杂，关键是做了、做对了、验证过了。