前两天接了个朋友的电话，说他们公司的财务系统突然崩了，数据库文件损坏，整整三天的账目数据找不回来。我问他有没有定期做备份，他说“备份了，但还原的时候报错”。这种情况，搞过数据库的人应该都懂。SQL 2000虽然是个老古董，但很多中小企业仍在使用，尤其是跑了几年的 ERP 或财务系统，换数据库成本太高，只能硬撑。今天我就跟你聊聊这位老伙计的备份和还原，不说那些虚头巴脑的理论，全部是实战中踩过的坑。
先说备份这步，很多人觉得备份就是点个“备份”按钮完事，结果真到还原时才发现备份文件是坏的。SQL 2000 的备份其实有讲究，最简单的办法是用企业管理器，右键点击数据库，选“所有任务”，然后点“备份数据库”。但有个细节：备份类型别选“差异备份”或“事务日志备份”，除非你特别懂怎么管理日志链。我见过太多人为了省空间只做差异备份，结果还原时缺了基础备份，直接废掉。最稳妥的做法是选“完整备份”，并勾选“覆盖现有媒体”，这样每次备份都是完整的，虽然文件大点，但出错的概率最低。
备份文件放哪儿也是个问题。有人图省事直接存在 C 盘，结果系统盘满了，数据库直接罢工。更离谱的是把备份文件放在数据库同一块硬盘上，硬盘一坏，数据和备份一起完蛋。我的习惯是，备份文件至少放两个地方：一个本地，另一个在网络路径或移动硬盘。SQL 2000 不支持直接备份到云盘，但可以写个简单的批处理脚本，用 xcopy 把备份文件拷贝到共享文件夹。例如：先执行备份作业，然后在作业完成后运行 xpcmdshell 调用系统命令，把文件复制到另一台服务器的共享目录。虽然麻烦点，但总比数据丢了哭天喊地强。
再来说还原，这步才是真正的技术活。还原前一定要先确认备份文件完整，别等点“还原”按钮才报错。最简单的检验方法是新建一个测试库，比如叫 “TestRestore”，对它执行还原操作。如果还原成功，说明备份文件没问题；如果报错，就要检查备份文件是否损坏或版本不匹配。SQL 2000 有个特点：还原时默认会覆盖现有数据库，很多人不知道，直接点“确定”就把生产库给覆盖了，数据全没了。所以还原前一定要勾选“在现有数据库上还原”，除非确认当前数据库可以丢掉，别选“覆盖现有数据库”。
实际工作中最头疼的是还原时报“媒体集有 2 个家族，但只提供了 1 个”这种错误。这通常是因为备份时指定了多个目标文件，例如同时写入 C 盘和 D 盘。SQL 2000 的备份机制会把数据分散到这两个文件里，还原时必须把所有文件都提供，缺一个都不行。很多人随手填了两个路径，以为是在做冗余，结果还原时找不到另一个文件，整个备份就废了。所以备份时最好只指定一个文件路径，别画蛇添足。
还有一种情况是还原时报“数据库正在使用，无法还原”。这通常是因为有人通过企业管理器或应用程序连接着数据库。最简单的处理办法是在企业管理器里右键点击数据库，选“分离”，然后重新附加。但分离前一定要确认没有其他人在用，否则可能导致数据丢失。更稳妥的方式是用 T‑SQL 强制断开连接，例如执行然后立即还原，完成后再改回多用户模式。该命令会回滚所有未完成的事务，生产环境要慎用，但紧急情况下比分离数据库快得多。
说到 T‑SQL，我建议大家学会用命令行备份和还原。企业管理器虽然直观，但一旦需要批量操作或自动化，命令行更靠谱。比如备份可以用还原则是WITH INIT 表示覆盖原有备份文件，WITH REPLACE 表示强制替换现有数据库。这两个参数用好了能省很多事，但用错了也会出大问题。建议在测试环境多练几次，弄清每个参数的作用，生产环境才能不慌。
说个很多人忽略的点：定期做还原测试。备份文件放那儿，半年不碰一次，等到真出事才发现是坏的，那才叫欲哭无泪。我的做法是每个月抽一天，把最近一次备份恢复到一台测试服务器上，跑几条查询检查数据是否完整。顺便还能检查索引碎片和日志文件大小，一举两得。SQL 2000 虽然老了，但只要备份策略得当、还原流程熟练，它依然能稳稳当当地跑下去。记住一句话：备份不是终点，能还原的备份才是真正的备份。
