数据丢失的真实代价
郑东新区一家做教育培训的公司，服务器硬盘坏了，3年积累的学员数据、课程视频、财务记录全没了。找数据恢复公司花了2万多，只恢复了40%的数据。剩下的60%彻底找不回来，公司差点倒闭。老板后来说了一句话：我宁愿花2万做备份也不愿意花2万做恢复。
这就是不做备份的代价。硬盘是消耗品，平均寿命3到5年，坏是迟早的事。人为误操作、程序bug、黑客攻击、机房断电，任何一个因素都能导致数据丢失。备份不是可选项，是刚需。
3-2-1备份原则 数据安全的黄金法则
业界公认的备份原则叫3-2-1：3份数据副本，2种不同存储介质，1份异地存储。翻译一下就是别把鸡蛋放一个篮子里，而且其中一个篮子还要放在别的地方。
3份副本：1份在服务器本地（生产数据本身），1份在同机房的另一台服务器或者NAS上，1份在异地。2种介质：比如本地用SSD，备份用机械硬盘和云存储。1份异地：异地可以是云存储，也可以是另一个城市的机房。
郑州很多企业的备份方案是：在服务器上用tar打包一份放到backup目录。这叫备份吗？硬盘坏了你backup目录也一起没了。这跟不备份有什么区别？
数据库备份的正确姿势
数据库备份分逻辑备份和物理备份。逻辑备份就是用mysqldump或者pg_dump导出SQL文件，优点是跨版本兼容、可读性强，缺点是大数据量时备份慢、恢复慢。物理备份就是直接复制数据库的数据文件，优点是快，缺点是必须同版本才能恢复。
推荐方案：每天凌晨做一次逻辑全量备份（mysqldump加single-transaction加routines加triggers），每小时做一次binlog增量备份。全量备份保留30天，binlog保留7天。这样你可以恢复到过去7天内任意一个时间点的数据状态。
备份脚本跑完之后，一定要验证备份文件。mysqlcheck检查表的完整性，或者把备份恢复到测试库跑几个查询确认数据没问题。管城区一家公司备份跑了两年从来没验证过，真要恢复的时候发现备份文件是0字节——磁盘满了备份脚本写不进去但没报错。两年的备份等于没做。
网站文件备份和自动化
网站文件备份比数据库简单，就是打包压缩。但要注意几个点：第一，备份内容包含代码文件、上传的图片附件、配置文件。不要只备份数据库忘了网站文件。第二，备份文件不要存在同一块硬盘上，至少放到另一块硬盘或者另一台机器上。第三，定期清理旧备份，不然硬盘迟早被备份文件填满。
自动化很关键。写个shell脚本，crontab定时跑，备份完自动上传到云存储。阿里云OSS、腾讯云COS都行，一年几十块钱的存储费，买的是安心。脚本里加个邮件通知，备份成功了发一封邮件，失败了也发一封。连续3天没收到成功通知就赶紧去检查。
恢复演练 比备份本身更重要
备份做了不等于数据安全了，你还得能恢复回来。很多企业的备份是做了的，但从来没试过恢复。等到真要恢复的时候发现：备份文件格式不对、恢复步骤不熟悉、缺少依赖环境、备份文件损坏。各种问题。
建议每季度做一次恢复演练。把备份文件恢复到一台测试服务器上，跑一遍业务流程，确认数据完整、功能正常。把恢复的步骤文档化，谁都能照着做，不要只有一个人会恢复。
郑东新区那家教育公司后来痛定思痛，花了一个月时间搭建了完整的备份体系：本地加异地加云存储三份备份，每天自动执行，每周验证备份文件，每季度恢复演练。老板说现在晚上睡觉踏实多了。说白了备份这件事就是保险，你希望永远用不上，但你不能没有。