早上办公室老张满头大汗，说服务器突然蓝屏，公司财务系统打不开了，数据库里几十万的账单要完蛋。我递给他一杯水，说别慌，咱们先看看SQL2000的数据文件还在不在。这种场景我见了太多次，SQL2000虽然是个老古董，但很多企业内部系统还在用它跑，备份和恢复这事儿，看着简单，实际操作起来坑不少。今天我就把那些年踩过的坑和总结的招数一次性讲清楚，保证你读完能自己动手搞定。
备份数据库，先别急着点鼠标。很多人觉得备份就是右键任务然后选备份，结果恢复的时候发现要么文件损坏，要么恢复后数据不对。SQL2000的备份有几种方式：完整备份、差异备份、事务日志备份。完整备份就像拍全家福，一次把所有数据都复制出来，适合每周做一次。差异备份只记录上次完整备份后的变化，好比今天拍个全家福，明天只拍新增或修改的人。事务日志备份更细，记录每一次操作，恢复时能回到某个时间点。我建议小公司每周日做一次完整备份，每天做一次差异备份，如果数据变化频繁，还得每小时做一次日志备份。别嫌麻烦，真出问题的时候，这些备份就是救命稻草。
备份路径和文件名要养成好习惯。我见过有人把备份文件直接放在C盘系统盘，结果系统重装，备份文件全没了。正确做法是单独分一个盘，比如D盘专门放备份，文件夹按日期命名，比如“20240115完整备份”。文件名也要规范，别叫“backup1.bak”这种，恢复时根本分不清是哪个库的。我的格式是“数据库名备份类型日期.bak”，比如“FinanceDBFull20240115.bak”。另外，备份完一定要验证完整性，SQL2000的备份对话框里有个“验证备份”选项，勾上它，系统会检查备份文件能不能正常恢复。别省这一步，我吃过亏，备份了半年，结果恢复时提示文件损坏，那种绝望不想再经历第二次。
说到恢复，很多人以为恢复就是把备份文件拖回去。实际上SQL2000恢复时最头疼的是权限问题。比如你备份数据库时用的是管理员账号，恢复时换了普通用户，系统可能报错说无法访问备份文件。解决办法是先检查文件权限，确保SQL Server服务账号有读写权限。还有一个常见坑：恢复时目标数据库已经存在，系统会提示是否覆盖。如果你选择覆盖，原数据库的所有记录会被清空，换成备份里的数据。这时候得谨慎，尤其是生产环境，先停机，确保没人操作数据库，然后再恢复。我习惯先把原数据库改名，比如加个“old”后缀，然后恢复备份，这样万一出问题还能回滚。
事务日志恢复是SQL2000的一大特色，但也最容易出乱子。假设你上午10点做了完整备份，11点做了差异备份，12点做了日志备份。下午1点数据库崩溃，你想恢复到12点整的状态。恢复顺序是：先恢复完整备份，再恢复差异备份，最后恢复日志备份。注意，恢复日志时有个选项叫“恢复完成状态”，默认是“回滚未提交事务”，意思就是恢复到备份时间点后，系统会自动撤销未完成的操作。如果你选“不回滚”，系统会保留所有未提交事务，看起来数据多了，实际上那些事务没完成，可能导致数据不一致。我建议普通场景用“回滚”，需要分析问题时用“不回滚”。
还有一种情况是数据库直接损坏，连附加都附加不上。这时候别慌，尝试用SQL2000自带的DBCC CHECKDB命令检查数据库完整性。命令格式是：DBCC CHECKDB('数据库名')。如果发现错误，可以加上REPAIRALLOWDATALOSS参数尝试修复。但注意，这个参数会删除损坏的数据页，可能导致部分数据丢失。所以修复前一定先备份当前状态。我遇到过一次，客户数据库文件损坏，用REPAIRALLOWDATALOSS修复后，丢失了最近两天的新增记录，但好在之前的备份完整，从备份里恢复了那两天的数据，算是亡羊补牢。
备份和恢复的自动化也很关键。手动备份容易忘，尤其周末加班后周一容易忘。SQL2000支持通过维护计划自动备份。打开企业管理器，找到“管理”下的“维护计划”，新建一个计划，设置备份类型、频率、存储位置。我习惯每周日凌晨2点做完整备份，每天凌晨1点做差异备份，每小时做一次日志备份。自动备份有个细节：日志备份设置时，记得勾选“截断事务日志”，否则日志文件会无限膨胀，撑爆硬盘。我见过有人没勾选，三个月后日志文件比数据库本身大20倍，C盘直接爆红。
提醒一句，备份文件别只放本地。本地服务器万一被雷劈、被水淹、被勒索病毒攻击，备份也会跟着玩完。我建议至少做两份异地备份，比如一份放公司文件服务器，一份放云存储。当然，SQL2000本身不支持直接备份到云，但你可以写个批处理脚本，每天自动把备份文件压缩后上传到云盘。或者用第三方工具，比如BackupExec之类的。别觉得麻烦，数据无价，尤其现在勒索病毒猖獗，我见过一家公司所有服务器被加密，就因为本地备份也连在一起，结果全军覆没。异地备份是一道防线，绝对不能省。现在你可以关掉这篇文章，先去检查一下自己的备份策略，看看有没有漏洞。记住，备份不是做给别人看的，是给自己留后路的。
