昨天凌晨两点，据库我被一通电话吵醒。备份客户那边的据库ERP系统彻底卡死，所有订单都堵在队列里。备份我远程连上去一看，据库数据库日志文件已经撑爆了硬盘，备份事务日志无法截断，据库备份作业早就失败了整整三天。备份没人注意到。据库这活儿我干了八年，备份类似场景见了不下二十次——SQL Server备份这事，据库从来都不是备份“配个计划就完事”那么简单。

备份的据库核心逻辑其实就一句话：你要能接受丢多少数据，就决定你用什么备份策略。备份但大多数企业压根没想过这个问题，据库他们只知道“我们有备份”。有次我帮一家贸易公司做灾备演练，真到恢复的时候才发现，他们的“每日完整备份”居然存在同一块物理硬盘上。硬盘坏了，备份和源数据一起没了。那种尴尬，你在会议室里根本没法跟老板解释。

说回技术本身。SQL Server的备份类型无非三种：完整备份、差异备份、日志备份。完整备份就是把整个数据库的状态拍个快照，这是地基。差异备份只记录最后一次完整备份之后的变化，体积小、恢复快。日志备份则是把每次事务操作都记下来，能精确还原到某个时间点——比如误删数据前的十分钟。

但很多人搞混了恢复模式。简单恢复模式下，你根本没法做日志备份，只能完整加差异。完整恢复模式才能支持时间点恢复，但它要求你定期备份日志，否则日志文件会像吹气球一样膨胀。我见过最离谱的一次，某系统日志文件涨到300GB，磁盘直接跪了。运维说“我们开了完整恢复模式啊”，可他们压根没配日志备份作业。

选择备份频率也有讲究。我一般建议：核心业务库，完整备份一天一次，差异备份每四小时一次，日志备份每十五分钟一次。这不是拍脑袋定的，而是根据RPO（恢复点目标）反推的。如果老板说“最多丢五分钟数据”，那日志备份间隔就得小于五分钟。别信那些“每天备份一次就够了”的鬼话，那种策略只适合开发库或者报表库。

备份文件要定期做恢复验证。光看备份作业显示“成功”没意义。SQL Server的备份接口有时候会静默失败——文件写坏了，但错误码没抛出来。我自己的做法是，每周挑一个备份文件，在一台隔离的测试实例上做一次完整的RESTORE WITH RECOVERY，然后跑几个关键查询。成本不高，但能救你的命。

还有存储位置。别把鸡蛋放一个篮子里，这句话在备份领域是铁律。本地磁盘一份，异地或者云存储一份，最好再弄个离线磁带或者不可变对象存储。勒索病毒可不管你是不是内网，它扫到备份文件一样加密。我认识一个DBA，他们公司被勒索后，发现备份文件全在同一个NAS上，结果连备份一起被锁了，最后只能交赎金。

压缩备份也是个实用技巧。SQL Server自带的备份压缩能省不少空间，代价是CPU占用稍微高一点。现在服务器CPU普遍过剩，我基本都开着压缩。还有校验和（CHECKSUM）选项，建议打开，它能在备份时验证页级完整性，虽然会拖慢一点点速度，但能提前发现坏页。

最后说个反直觉的事：备份作业跑得越快，不代表越好。有一次我把某库的备份时间从40分钟优化到12分钟，结果发现是因为日志文件太大，完整备份里包含了大量无用的历史日志数据。后来清理了日志，备份时间反而回到25分钟，但恢复时间缩短了将近一半。备份不是给自己看的，是给恢复用的。你备份得再快，恢复不了就是一堆废数据。

做这行久了，我越来越觉得备份是门手艺活，不是按钮活。你得理解业务、理解恢复目标、理解存储特性，然后才能设计出真正能扛事的方案。别等到半夜被电话吵醒才开始想这些。