云备份该备份哪些数据？多数人只备了一半

备份这东西，最容易出问题的地方往往不是没备，而是备了一堆用不上的，真正要命的那些反而漏在外面。云备份该备份哪些数据，问十个人，八个的回答是照片、文档、代码，全停在“文件”这一层。听着没错，可真到要恢复那天，光有文件根本拼不回一个能跑的站。

文件备得挺全，数据库却在裸奔

相册、视频、素材、源码，占空间最大，也最容易被想起来。几十 MB 的数据库反而没人碰。文章、订单、用户、评论、后台设置，全躺在里面。mysqldump 就是一行命令的事，很多人却把主机商送的“每日备份”当成保险箱。得问清楚：它备的是整站还是只备文件？保留几天？能不能单独把某个库拿出来？这几个问题问下去，不少“备份”当场露馅。

跑 MySQL 的，binlog 也建议留着。误删一张表、改错一条记录，有 binlog 就能按时间点往回找，比翻整库快得多。前提是它没跟数据盘挤在一块儿，盘一坏，两个一起没。

云备份该备份哪些数据，多数人只备了一半卡在哪

卡在“状态”和“身份”这两类东西上。它们体积小得可怜，重建成本却高得离谱。nginx.conf、php.ini、.env、docker-compose.yml、应用目录里的 .htaccess，加起来可能就几十 KB。重装一台机器，这些没了，站点能不能起来全看运气。

还有一堆系统层面的东西没人想着备：crontab -l 导出来的定时任务、iptables 规则、supervisor 的进程配置、改过的 SSH 端口、系统里多出来的那几个账号。平时从不看，机器一重装全凭记忆复原，通常是复不全的。

凭据和私钥丢了，比数据丢了还难受

SSL 私钥、SSH key、各类 API token、对象存储的 AccessKey、域名注册商和 DNS 的登录方式，严格说这些不算“数据”，可丢了之后的重建流程比恢复数据麻烦得多。证书能重签，token 得一个一个去换，DNS 账号要是进不去，连解析都动不了。

别把它们跟网站放在同一个目录，也别顺手塞进 git 仓库。加密之后放个离线的地方，或者用密码管理器统管起来。听着是麻烦，真出事那晚省下来的可是一整夜时间。

对象存储和图床，不是“上了云就自动有备份”

附件、图片、视频传到对象存储，很多人心里就默认“云上有份”。云上确实有份，但那是一份，删了就是删了。生命周期规则配错、同步脚本写反、批量替换图片路径时手滑，都会原样作用到桶里。

想靠得住，得往外挪一份：另一个账号、另一个区域，或者索性拉到本地。跨区域复制这类功能各家都有，开不开、怎么计费，以服务商官方页面说明为准。

快照和备份，压根不是一回事

快照确实好用，点一下，整块盘的时间点副本就有了，回滚也快。问题在于它太“顺”了，容易让人以为万事大吉。多数人只留最近一个或几个快照，还跟实例绑在同一个账号、同一个区域。账号出问题、欠费、误删，副本跟着一起走。

更稳的做法是分层：本地或同区域留一份快照，异地留一份，条件允许再留一份离线的。全量加增量，定期做一次完整归档。频率看数据变化速度，一天改不了几次的站每天一次够了；订单类的，可能得往小时级走。

备了不等于能恢复，每个月抽一次

备份文件的大小最会骗人。0 字节的、几百 KB 的、日期停在半个月前的，都见过。定时任务可能早就没跑，磁盘可能满了，密钥可能过期了，全都没人知道。备份失败要能报警，报了警还得有人看，不然等于没有。

更直接的办法是每月真恢复一次：挑一个库导入测试环境，解一份配置，随手打开一张附件看看能不能读。跑通了心里有底；跑不通那是提前发现，总比上线当天发现强。

照着这个顺序过一遍

代码和配置文件先打包，数据库做全量加 binlog，附件和对象存储往外复制一份，证书私钥单独加密存，定时任务和系统改动导出成文本，账号凭据收进密码管理器，日志按需要留一段时间，最后把备份存在哪、谁负责、多久验证一次写下来。一页纸就够，放在脑子里不顶用。

真想做点什么，现在就能动手：打开服务器，把 /etc 和项目里的 .env 打个包，导一次数据库，然后找台干净的机器恢复看看。恢复不出来，那就等于没备。剩下的慢慢补齐就行，别等到出事那天才想起少了哪几样。