聊到数据库，不管是做开发还是运维，SQL Server 一定是绕不开的话题。而说到SQL Server，备份与恢复这事儿，可能比建表、写查询还让人头疼。毕竟，数据丢了或者恢复不了，老板的脸色可不是闹着玩的。备份和恢复，说白了就是给数据买保险，平时觉得花钱花时间，真出事才知道值不值。不过，很多人把这活儿干成了“例行公事”——每天跑个脚本，备份文件堆成山，真到恢复时才发现要么文件坏了，要么策略不对。今天咱就聊聊，怎么把这套活儿干得既省心又靠谱。
先说说备份的种类。SQL Server 支持完整备份、差异备份、事务日志备份，还有文件组备份和部分备份。完整备份是基础，相当于给整个数据库拍个快照，但数据量大的时候，每天跑一次完整备份，硬盘和带宽都扛不住。差异备份只记录上次完整备份后的变化，体积小、速度快，适合做增量保护。事务日志备份就更细致了，可以恢复到某个时间点，比如你删错数据后，能精准回滚到删除前的状态。实际生产环境里，常见的做法是“每周一次完整备份 + 每天一次差异备份 + 每小时一次日志备份”，这样既能控制备份文件大小，又能把恢复时间窗口缩到最小。
不过光有备份策略还不够，备份文件的存储和管理才是坑最多的地方。很多人习惯把备份文件丢在服务器本地硬盘上，这其实很危险——服务器硬盘坏了，备份和原数据一起完蛋。理想的方案是异地存储，比如挂载网络共享、用Azure Blob或者AWS S3。SQL Server 2012之后支持URL备份，可以直接备份到云存储。另外，备份文件的命名和归档也很重要。我见过有人用“backup2023-01-01.bak”这种名字，结果一年下来文件夹里几百个文件，找起来像大海捞针。建议用“数据库名备份类型日期时间”的格式，比如“SalesDBFULL202501011200.bak”，配合定期清理脚本，只保留最近30天的日志备份和最近4周的完整备份，省时省力。
说到恢复，这才是真正考验功力的地方。恢复场景千奇百怪：可能是硬盘坏了要全库恢复，也可能是误删了个表要时间点恢复，还可能是从开发环境还原一份数据到生产环境。恢复操作前，第一步永远是“别慌”，第二步是“确认备份文件可用”。我见过最惨的例子：运维兄弟看着备份文件躺在那儿，恢复时才发现文件损坏，因为从来没做过恢复测试。所以，定期做恢复演练不是走过场，是真能救命。比如每个月挑个非业务高峰期，从异地存储拉一份备份，恢复到测试服务器上，跑一下数据校验脚本，确认数据一致性和完整性都OK。
时间点恢复是SQL Server 的一个杀手锏。当你误删了数据，或者某个事务提交错了，只要你有连续的事务日志备份，就能恢复到任意一个时间点。操作逻辑其实不复杂：先还原完整备份（WITH NORECOVERY），再还原差异备份（同样WITH NORECOVERY），还原日志备份（WITH STOPAT = '时间点'）。关键在于，还原过程中一定要用NORECOVERY模式，这样数据库才能保持“正在还原”状态，允许继续应用后续日志。如果你不小心用了RECOVERY，那后面的日志就再也加不进去了，等于前功尽弃。所以，写脚本时一定要小心这个参数。
再说说快照备份和文件组恢复这些高级玩法。SQL Server 2016之后支持快照备份，利用VSS技术可以秒级创建数据库的只读副本，特别适合做报表、测试或者临时恢复。不过快照备份不持久，一旦重启服务或者系统崩溃，快照就没了，所以不能替代常规备份。文件组恢复则适合超大数据库。比如一个几百GB的数据库，分成多个文件组，你只损坏了主文件组，那就只恢复主文件组，其他文件组在线运行，业务几乎不受影响。这要求前期设计表结构时，把热点数据和冷数据分开放到不同文件组，恢复时才能精准打击。
备份和恢复其实是个体系活儿，不是跑个脚本就完事。我见过太多公司，备份策略写得很漂亮，但恢复时间RTO和恢复点RPO根本没算过。比如日志备份每小时一次，理论上RPO是1小时，但如果你完整备份要跑8小时，那RTO就是8小时起步。业务方能不能接受？得提前对齐。另外，监控和告警也不能少。备份失败、备份文件大小异常增长、日志文件撑爆磁盘，这些都要有邮件或微信通知。推荐用SQL Server Agent的作业报警功能，或者接入Zabbix、Prometheus这类监控平台。数据安全这事儿，平时多花点心思，真出事时才能睡得着觉。
