简介针对SQL Server 2000数据库管理员与运维人员这份图文教程系统梳理了备份与还原的完整流程涵盖完整备份、差异备份及事务日志备份三种类型的适用场景并演示通过企业管理器执行还原、从设备导入备份文件以及附加MDF/LDF文件的具体操作。资源共1个PDF文件约327KB篇幅紧凑配合步骤截图可直接对照练习尤其适合需要快速掌握MSSQL2000数据保护操作的新手。已有302人在CSDN下载学习。内容还特别提醒备份目录需赋予Mssqluser完全控制权限、还原前确认数据库路径等易忽略细节能帮助读者规避常见失败原因提升数据恢复的成功率。1. 为什么还在用 SQL Server 2000 的备份还原以及你该怎么下手SQL Server 2000数据库备份还原的图文教程其实最难的往往不是点按钮而是搞清楚备份出来的文件里放着哪些文件、还原子系统给不给过。我上周刚帮客户处理一台 Windows Server 2003 上的旧库调度作业一直备份失败打开备份文件一看磁盘剩不到 1GB日志文件却占了 60GB。这类问题在遗留系统上太常见了。这篇教程会从入口和权限说起接着给出一条能直接执行的备份命令再演示把库还原成原库和新库最后把容易翻车的几个场景一次说清。适合要接手老系统的新手也适合准备做迁移前备份的运维。2. 先把环境摸清SQL Server 2000 的备份还原入口和权限准备2.1 三个入口别只在企业管理器里找SQL Server 2000 时代没有 SSMS维护和管理主要靠企业管理器、查询分析器和 osql 命令行。图文教程里截到的界面绝大多数来自企业管理器所以先把入口认齐。企业管理器开始菜单 - Microsoft SQL Server - 企业管理器。左侧树展开 Microsoft SQL Servers - SQL Server 组 - 本机实例名 - 数据库。右击某个数据库 - 所有任务 - 备份数据库/还原数据库这就是图形备份还原的入口。查询分析器开始菜单 - Microsoft SQL Server - 查询分析器登录后输入 T-SQL。很多还原报错在企业管理器里只弹一句“不能恢复”在查询分析器里才能看到完整的错误信息。osql命令提示符下运行适合远程排错和无人值守备份。例如osql -S 服务器名 -U sa -P 密码 -Q BACKUP DATABASE...。如果企业管理器打开后连不上服务器先看任务栏里的 SQL Server 服务管理器绿色三角形才表示服务在跑。默认实例名就是计算机名命名实例则是“计算机名\实例名”的格式。下面这个表可以当备忘。入口适合场景常用操作企业管理器日常图形化备份/还原右键数据库 - 所有任务 - 备份/还原查询分析器写脚本、看完整错误BACKUP DATABASE / RESTORE DATABASEosql远程、批处理、计划任务osql -S server -U sa -Q 命令2.2 先查版本、权限和磁盘空间备份和还原在 SQL Server 2000 里都要求 sysadmin 固定服务器角色或者数据库所有者 db_owner。如果你用 sa 登录注意 2000 在安装时 sa 很可能没设密码这在现在的安全环境下非常危险建议进查询分析器立刻改掉如果你用 Windows 身份登录确认该 Windows 账号已经被加入 sysadmin 角色。连上查询分析器后先执行下面这段确认当前实例的基本状态USE master; GO -- 查看实例名和版本确认确实是 SQL Server 2000 SELECT SERVERNAME AS instance_name, VERSION AS version_info; -- 返回值是 1说明当前登录是 sysadmin具有备份还原权限 SELECT IS_SRVROLEMEMBER(sysadmin) AS is_sysadmin; -- 列出实例上所有数据库确认要备份的库存在 SELECT name, dbid, crdate FROM master.dbo.sysdatabases ORDER BY dbid;逻辑说明第一行SERVERNAME返回当前实例名VERSION返回完整版本字符串能从里面看到“Microsoft SQL Server 2000”字样IS_SRVROLEMEMBER(sysadmin)是权限探测函数返回 1 表示具备权限最后从master.dbo.sysdatabases查所有数据库这个系统表在 2000 里承担了后来sys.databases的职责。参数说明如果你用的是命名实例instance_name会显示成“主机名\实例名”后面写连接字符串时会用到。备份文件放哪里也要提前想好。常见的做法是单独建一个D:\Backup目录和系统盘、SQL Server 的数据库数据目录分开。执行下面的命令可以看磁盘剩余空间-- 查看所有磁盘剩余空间单位是 MB EXEC master.dbo.xp_fixeddrives;执行后结果里每一行是一个盘符和剩余 MB 数。备份前至少保证有数据库大小的 1.5 倍以上空闲。很多人忽略还原环节备份文件本身不大但还原时数据文件和日志文件会同时膨胀如果目标磁盘只剩几百 MB最后一定卡在“操作系统错误 3”这种莫名其妙的提示上。备份文件的命名也是坑。我一般用“库名_日期_时间.bak”格式例如MyDB_20250915_2310.bak。不要用中文路径和中文文件名2000 的命令行工具对字符编码处理得很粗换到别的机器上还原时很容易出现路径找不到。另外备份文件不要放在数据目录比如C:\Program Files\Microsoft SQL Server\MSSQL\Data下否则做全库备份时可能会把过去几个备份文件也扫进去目录会越来越乱。3. 用企业管理器做一次完整备份从图形界面到 T-SQL 脚本3.1 图形界面右键任务里的完整备份假设你已经用 sysadmin 身份登录企业管理器现在要对MyDB数据库做一次完整备份。打开企业管理器展开服务器和“数据库”右击MyDB选择“所有任务”里的“备份数据库”。这一步是整个图形界面备份的核心入口。在打开的“备份数据库”对话框里先确认“数据库”下拉框选中的是MyDB。“备份”区域有三个选项数据库-完全、数据库-差异、事务日志。第一次备份或要做完整迁移必须选“数据库-完全”。备份名称默认会显示“MyDB 完整 数据库 备份”可以改成MyDB_Full_20250915这个名称会成为备份集内部名字还原时能直接看到。接着看“目标”区域。2000 支持两种目标一种是“备份设备”要先在 SQL Server 里创建逻辑设备另一种是直接指定物理文件。临时备份建议直接选“文件”点“添加”输入D:\Backup\MyDB_20250915_2310.bak。如果之前创建过备份设备也可以从下拉框里选逻辑设备的好处是脚本里只写设备名不用记路径。然后切到“选项”页注意“媒体集”下的两个选项“追加到媒体”和“重写现有媒体”。追加不会覆盖已有内容适合保留历史备份重写会直接覆盖目标文件适合每天固定文件名的计划备份。最后如果勾选“调度”可以设置 SQL Server Agent 定时执行。确定以后2000 会显示“备份已成功完成”如果没有看到立刻去查询分析器查错误。备份设备不是必须的但如果你要跑维护计划可以提前建一个。在查询分析器执行-- 创建一个指向 D:\Backup\MyDB.bak 的逻辑备份设备 EXEC master.dbo.sp_addumpdevice disk, MyDB_Backup, ND:\Backup\MyDB.bak;说明sp_addumpdevice的第一个参数disk表示磁盘文件第二个参数是逻辑设备名称第三个是物理路径。建完后在企业管理器的备份对话框里就能看到MyDB_Backup。如果以后物理文件被移动了这个设备会失效需要删除重建。3.2 T-SQL 完整备份一条命令说清楚图形界面点按钮适合偶尔手动一次真正要落到运维脚本里T-SQL 更可控。和上面图形界面完全等价的完整备份命令是BACKUP DATABASE [MyDB] TO DISK ND:\Backup\MyDB_20250915_2310.bak WITH INIT, NAME NMyDB-Full Database Backup, STATS 10;这段代码里的参数每个都有实际意义[MyDB]是数据库名如果库名里有空格或保留字中括号是必须的TO DISK指定物理备份文件路径INIT表示重写现有媒体等价于图形界面里的“重写现有媒体”不用INIT则默认追加NAME给备份集起一个可读的名字还原时会在“查看内容”里显示STATS 10表示每完成 10% 就往消息窗口打一条进度。SQL Server 2000 没有COMPRESSION选项如果你按高版本的习惯写WITH COMPRESSION会直接语法报错。执行完备份命令后不要只看消息窗口那句“已为数据库 MyDB 生写日志”。建议顺手验证一下-- 验证备份文件的结构是否完整、是否可读 RESTORE VERIFYONLY FROM DISK ND:\Backup\MyDB_20250915_2310.bak;返回“成功”只能说明备份集文件头和数据页面大体可读不能完全替代实际还原演练但至少能拦下很多文件拷贝不完整的问题。关于更严格的验证我会在第 6 章专门讲恢复演练。3.3 差异备份和事务日志备份什么时候该用当你面对一个很大的库每天做完整备份时间太长或者业务要求能恢复到某个时间点就要引入差异备份和事务日志备份。它们和完整备份在指令上的区别非常小-- 差异备份只备份自上次完整备份以来的所有变化 BACKUP DATABASE [MyDB] TO DISK ND:\Backup\MyDB_20250915_1200_Diff.bak WITH DIFFERENTIAL, INIT, STATS 10; -- 事务日志备份前提是数据库不是“简单恢复模式” BACKUP LOG [MyDB] TO DISK ND:\Backup\MyDB_20250915_1300_Log.trn WITH INIT, STATS 10;差异备份的DIFFERENTIAL参数决定了它只记录上一次完整备份之后变化的数据页所以文件通常比完整备份小很多恢复时也必须先恢复到那个“基准完整备份”再按顺序还原差异备份。事务日志备份则记录从上次日志备份以来所有的事务日志记录文件更小但链非常脆中间缺一环后面的日志全用不上。2000 有个特殊点完整备份不会截断事务日志事务日志备份会截断日志文件。如果数据库长期不备份日志LDF 会涨到几十 GB 甚至撑爆磁盘。反过来如果你用了“简单恢复模式”事务日志备份会直接报错这种情况就别纠结日志备份老老实实做完整备份加差异备份。另外 2000 没有COPY_ONLY这个功能任何备份都可能影响后续日志链所以不要把“临时备份”和“日志链维护”混在一起做容易让自己踩坑。4. 还原到原库和还原到新库最常用的操作步骤4.1 还原到原库强制还原和 NORECOVERY 的取舍要还原到原库最直接的方式是企业管理器右击MyDB- 所有任务 - 还原数据库。在“还原为数据库”框里保持MyDB然后选择“从设备”通过“选择设备”添加那个.bak文件再点“查看内容”确认备份集。选项页里有两个关键勾选一个是“在现有数据库上强制还原”对应 T-SQL 里的WITH REPLACE另一个是“保持数据库为非运营状态”对应NORECOVERY。如果只是做一次完整还原并且要用MyDB这个名字覆盖原来的混乱状态强制还原一定要勾。如果不勾源库还存在还原会报“数据库是打开的”。但强制还原不能解决连接占用所以更稳妥的顺序是先在查询分析器里把占用连接杀掉USE master; GO -- 查看所有连接找到占用 MyDB 的 SPID EXEC sp_who; -- 假设占用的 SPID 是 55就执行 KILL 55; GO RESTORE DATABASE [MyDB] FROM DISK ND:\Backup\MyDB_20250915_2310.bak WITH REPLACE, RECOVERY;WITH REPLACE代表强制覆盖原库RECOVERY表示还原完成后数据库直接进入可读写状态。如果之后还要接着还原差异备份或日志备份这一条不要用RECOVERY改成NORECOVERY-- 还原完整备份但保持数据库处于“正在还原”状态 RESTORE DATABASE [MyDB] FROM DISK ND:\Backup\MyDB_20250915_2310.bak WITH REPLACE, NORECOVERY; -- 接着还原差异备份 RESTORE DATABASE [MyDB] FROM DISK ND:\Backup\MyDB_20250915_1200_Diff.bak WITH NORECOVERY; -- 最后一条日志备份用 RECOVERY 让数据库上线 RESTORE LOG [MyDB] FROM DISK ND:\Backup\MyDB_20250915_1300_Log.trn WITH RECOVERY;注意使用NORECOVERY后数据库在企业管理器里会显示“还原中”这是正常的。如果你搞错了顺序在完整备份还原完成后直接用RECOVERY那么后续差异和日志都会拒绝应用。很多人第一次都栽在这。4.2 还原到新库用 FILELISTONLY 找出逻辑文件名当你需要把备份还原成一个新库名或者只是想把库放到另一台服务器的不同路径就必须处理“物理文件重定向”。因为备份集内部记录了源数据库的数据文件和日志文件在当时机器上的绝对路径目标机器不可能原样存在。先不要急着还原在查询分析器里看一下备份集内部的文件清单-- 列出备份集中的数据文件和日志文件逻辑名、物理路径 RESTORE FILELISTONLY FROM DISK ND:\Backup\MyDB_20250915_2310.bak;结果会返回类似下面这样的信息TypeLogicalNamePhysicalNameDMyDB_DataC:\Program Files\Microsoft SQL Server\MSSQL\Data\MyDB_Data.MDFLMyDB_LogC:\Program Files\Microsoft SQL Server\MSSQL\Data\MyDB_Log.LDF看到LogicalName后再用MOVE参数把数据文件和日志文件放到目标机器上的真实路径。例如还原成MyDB_New-- 把备份还原成一个新库并把数据文件和日志文件移动到新路径 RESTORE DATABASE [MyDB_New] FROM DISK ND:\Backup\MyDB_20250915_2310.bak WITH MOVE NMyDB_Data TO ND:\MSSQL\Data\MyDB_New.mdf, MOVE NMyDB_Log TO ND:\MSSQL\Data\MyDB_New_Log.ldf, RECOVERY;这里的MyDB_Data和MyDB_Log必须和FILELISTONLY查出来的逻辑名完全一致大小写最好也保持一致因为 2000 的排序规则可能区分大小写。TO后面的路径是目标服务器上的物理位置目录必须提前存在。如果你漏掉了日志文件的MOVE日志文件会尝试写回源机器上的原始路径照样报错。如果目标目录已经有同名 MDF 或 LDF需要先清掉或者换一个库名。图形界面也可以完成同样的事在还原数据库对话框的“选项”页下面有一个“将数据库文件还原为”列表双击每个行的“移到物理文件名”列改成目标路径效果等同于MOVE。但文件多的时候脚本比界面直观。4.3 还原后的验证不只盯着“已还原成功”还原完成不等于数据可用。我见过不少案例还原后能打开库但 DBCC 检查却有大量错误原因要么是备份文件本身有问题要么是磁盘坏道。所以验证要分三步。第一步做一致性检查-- 检查新还原出来的库是否有页面损坏、分配错误 DBCC CHECKDB (NMyDB_New) WITH NO_INFOMSGS;NO_INFOMSGS是让 DBCC 只输出错误不输出那些无关的信息。消息窗口里如果只有一句“DBCC 执行完毕。如果 DBCC 输出了错误信息请与系统管理员联系。”就算基本干净。如果出现错误就要追溯到源库去做备份。第二步抽业务数据。找一个你熟悉的业务表比如订单表、流水表查最近的数据-- 抽样验证避免查到的是空库 SELECT TOP 100 * FROM MyDB_New.dbo.Orders ORDER BY CreateTime DESC;这里表名和列名要根据实际业务改。如果查询返回了正常业务数据说明数据到了新库如果没有可能是备份集选错了。第三步确认兼容级别和状态。在 2000 里执行-- 查看新库的状态、创建时间、恢复模式 EXEC sp_helpdb MyDB_New; -- 查看兼容级别8 表示 SQL Server 2000 兼容级 EXEC sp_dbcmptlevel MyDB_New;sp_helpdb的结果里能看到数据库状态是否 Onlinesp_dbcmptlevel返回当前兼容级别。2000 对 2000 的备份还原后兼容级别一般是 80如果是高版本还原过来的则是 90 或更高需要对应调整。注意如果在 2005 或 2008 上还原 2000 备份库的兼容级别可能还是 80这会影响某些新语法但是不影响访问旧数据。5. 避坑SQL Server 2000 备份还原的常见翻车现场5.1 还原时提示“数据库正在使用”企业管理器一直等现象执行 RESTORE 命令进度条停在那里过一会儿提示“无法获得独占访问权”或“数据库正在使用”。有时连企业管理器里删除一个库都会卡住。原因有一个或多个连接占用了这个数据库。最常见的是你自己在另一个查询分析器窗口打开着MyDB或者应用服务器的连接池没有释放。2000 的还原要求对目标库有独占访问权任何连接都会挡路。解决在查询分析器里执行EXEC sp_who查看每个会话的dbname字段找到占用MyDB的 SPID然后KILL 55。如果连接来自应用服务器可以暂时停掉应用如果只是想快速还原直接 KILL 掉业务连接是常规做法但要提醒自己高频繁连接下 KILL 后会马上重连最好先把应用停掉再还原。有些人在还原对话框里勾了“强制还原”还是失败原因就在这——WITH REPLACE覆盖的是文件不是连接。5.2 拿到一个 .bak 就往 2000 上还原版本对不上现象在 SQL Server 2000 上恢复一个从别处拷来的 .bak报错“备份集保存于较新的版本不能在此服务器版本上恢复”有时连RESTORE FILELISTONLY都打不开。原因SQL Server 备份集只能向同版本或更高版本还原。2000 是最老的版本之一不能还原 2005、2008、2012 甚至更高版本产生的备份。这个问题尤其多发生在老机器迁移时客户给了一个从生产库导出的文件却不说生产库是什么版本。解决先确认备份来源。用高版本实例打开这个备份再把源库迁移回 2000 是不现实的低版本环境永远读不了高版本备份。正确做法是如果要保留 2000 环境只能从源高版本库里把数据抽出来用导入导出工具或编写脚本把表和数据落到 2000如果目标是升级那就直接让高版本实例还原这个备份不要把它往 2000 上塞。顺带说一句常见的“sql server 2012的数据库备份2008能用吗”这类问题答案也是一样低版本不能恢复高版本备份2008 不能用 2012 的备份。反过来2000 的备份放到 2005、2008 上是没问题的。5.3 还原到另一台机器报“操作系统错误 3”找不到文件现象从 A 服务器拷出备份放到 B 服务器上还原报“Operating system error 3 (The system cannot find the path specified)”但备份文件明明就在 D 盘。原因备份集内部记录的物理路径是 A 服务器上的路径比如C:\Program Files\Microsoft SQL Server\MSSQL\Data\MyDB.mdfB 服务器没有这个盘符或者目录名不一样。2000 不会自动帮你找同层目录。解决不要凭感觉填路径先用RESTORE FILELISTONLY把备份集内的数据文件和日志文件逻辑名列出来再写带MOVE的还原语句把每个逻辑文件指到目标机器的真实路径。如果你已经在企业管理器里操作在选项页把“移到物理文件名”改成现有目录即可。目标目录需要存在并且 SQL Server 服务账号有写权限。这个问题我在迁移老库时几乎必踩现在已经养成“还原前先FILELISTONLY”的习惯。5.4 日志链断了后面所有日志备份都白做现象完整备份、差异备份、日志备份都做了还原时前几个日志可以正常恢复还原到某个日志备份时提示“LSN 无法前滚”或“备份集不匹配”。原因日志备份链被截断。常见原因有三个一是有人执行了BACKUP LOG WITH TRUNCATE_ONLY或BACKUP LOG WITH NO_LOG来压缩日志二是切换了恢复模式三是多个 SQL Server Agent 作业同时备份同一个库后面的作业覆盖了顺序。2000 没有COPY_ONLY备份所以任何人为截断操作都会让后续日志备份失效。解决不要在日常维护里用TRUNCATE_ONLY截断日志这个命令只腾日志空间不产生备份等于把日志链剪断。如果确实需要压缩日志先做一次完整备份然后只保留完整备份点之后的日志备份。恢复时如果发现某个日志文件应用不了回到最近一次完整备份加上这之后的连续日志备份重新来中间断掉的部分无法绕过。记住差异备份虽然文件小但它依赖完整备份不依赖日志链所以差异备份日志是最稳妥的组合。5.5 备份文件打不开怀疑文件损坏现象从 FTP 或共享目录拷贝下来的 .bak执行RESTORE VERIFYONLY时报“媒体簇结构不正确”或“备份集无效”。原因多数是拷贝不完整字节数变了也有少部分是备份文件本身已经损坏比如源端备份过程中磁盘空间不足备份文件没写完就结束了。解决先对比源文件和拷贝文件的大小如果大小一样再执行RESTORE HEADERONLY FROM DISK N...能读到BackupName、BackupStartDate、DatabaseName这些字段说明文件头是完整的如果连头都读不到就重新备份并重新传。注意不要用文本编辑器打开 .bak某些编辑器保存后会破坏文件格式。遇到这种问题最简单的后悔药就是去源服务器再执行一次完整备份别死磕那个坏文件。6. 进阶批量备份、恢复演练与最终验证6.1 用一条游标脚本批量备份所有数据库如果你的实例上挂着十几个业务库一个个右键备份太原始。我一般会在 SQL Server 2000 里直接跑游标脚本把除了tempdb之外的所有库遍历一遍USE master; GO DECLARE dbname sysname, file varchar(200), sql nvarchar(500) DECLARE cur_db CURSOR FOR SELECT name FROM master.dbo.sysdatabases WHERE name NOT IN (tempdb) OPEN cur_db FETCH NEXT FROM cur_db INTO dbname WHILE FETCH_STATUS 0 BEGIN SET file ND:\Backup\ dbname _ CONVERT(varchar(8), GETDATE(), 112) .bak SET sql NBACKUP DATABASE [ dbname ] TO DISK N file WITH INIT, STATS 10 PRINT sql EXEC (sql) FETCH NEXT FROM cur_db INTO dbname END CLOSE cur_db DEALLOCATE cur_db这段脚本用sysdatabases系统表拿到所有库名排除tempdbCONVERT(varchar(8), GETDATE(), 112)生成YYYYMMDD格式的日期避免文件名重复。库名通过中括号保护即使库名里有空格也不会拼接出错。如果你想把 system 库也备份可以去掉dbid 4之类的过滤条件但我一般只备份业务库。脚本跑完后到D:\Backup目录看文件是否都生成再用RESTORE VERIFYONLY抽查两个文件。6.2 恢复演练验证备份不是黑匣子只备份不还原等于把数据交给一个黑匣子。我现在的习惯是每个月做一次恢复演练把最近一次完整备份还原成带_Test后缀的库再连续还原日志最后跑一次 DBCC-- 第一步还原完整备份暂时停在 NORECOVERY 状态 RESTORE DATABASE [MyDB_Test] FROM DISK ND:\Backup\MyDB_Newest.bak WITH MOVE NMyDB_Data TO ND:\MSSQL\Data\MyDB_Test.mdf, MOVE NMyDB_Log TO ND:\MSSQL\Data\MyDB_Test_Log.ldf, NORECOVERY; -- 第二步按顺序还原日志备份最后一条用 RECOVERY RESTORE LOG [MyDB_Test] FROM DISK ND:\Backup\MyDB_20250915_1200_Log.trn; RESTORE LOG [MyDB_Test] FROM DISK ND:\Backup\MyDB_20250915_1300_Log.trn WITH RECOVERY; -- 第三步做一致性检查 DBCC CHECKDB (NMyDB_Test) WITH NO_INFOMSGS;如果目标只是验证完整备份第一步可以直接用WITH RECOVERY不需要日志部分。验证完把MyDB_Test删掉避免长期占用磁盘。我吃过最大的亏是只备份不还原验证结果真出故障时备份里的文件结构早就坏到恢复不了。现在我的习惯是每次备份后留一行记录每个季度做一次恢复演练文件名里写清楚日期和类型。希望帮到你。本文还有配套的精品资源点击获取