做了一次数据资产盘点，发现服务器上躺着2TB的数据，但运维说不清楚哪些重要哪些不重要。这种现象太普遍了——企业做了很多备份，但该备份的没备份，不该备份的天天备份。结果恢复时缺关键数据，不缺的又占满硬盘。

问题的根源在于没有做数据分类分级。备份策略不应该是“全部备份“或“随便选几个文件夹备份“，而应该基于数据的重要程度来决定备份频率、备份方式和保留周期。下面是一套实操方法。

一、四个等级，够用就行

L1核心数据：业务直接依赖的数据。包括数据库主库、用户账号体系、支付交易记录、业务配置文件。这类数据丢失=业务停摆，必须实时备份或每天全量备份+增量备份，保留至少90天。恢复时间目标（RTO）应在4小时以内。

L2重要数据：业务间接依赖的数据。包括操作日志、客服记录、报表数据、上传的附件文件。每周全量+每天增量备份，保留180天。RTO可以放宽到24小时。

L3一般数据：有参考价值但不影响业务运转的数据。包括历史归档、系统监控数据、开发测试数据。每月备份一次，保留一年。不需要快速恢复，能找回来就行。

L4临时数据：缓存、临时文件、会话数据。不需要备份，定期清理即可。备份这类数据纯属浪费资源。

二、盘点和标记怎么做？

第一步，列清单。用脚本扫描所有服务器上的数据库、文件目录，输出一张表格：路径、大小、最后修改时间、所属业务系统。这个表就是数据资产清单的基础。

第二步，找业务负责人确认等级。每个业务系统负责人看自己的数据清单，标上L1到L4。别让运维一个人拍板，他不一定了解每个目录的业务重要性。

第三步，制定差异化的数据迁移备份策略。L1数据迁移时用在线迁移+实时同步，迁移窗口选在业务低峰期，迁移前后做完整性校验。L2数据可以在线迁移，允许短暂停机。L3数据离线打包迁移就行，不着急。

还有个容易忽略的点：配置文件和脚本也要分级备份。很多企业只备份数据库不备份配置，服务器挂了之后数据库恢复回来，但应用配置丢了，照样跑不起来。把Nginx配置、应用配置文件、定时任务列表都纳入L1或L2备份范围。