简介：这份PDF图文教程面向SQL Server 2000数据库管理员与运维初学者，聚焦数据库备份与还原这一核心运维场景，帮助读者在硬件故障、软件错误或人为失误后快速恢复数据、保障业务连续性。资源共1个PDF文件，压缩包约327KB，内容以截图配文字说明的形式呈现，便于对照操作界面逐步理解。教程系统覆盖完整备份、差异备份与事务日志备份的差异，还原数据库时从设备添加备份文件、勾选强制还原及检查恢复路径等关键环节，并延伸讲解MDF与LDF文件的附加数据库流程，以及为Mssqluser账户配置目录完全控制权限的注意事项。目前已有302人学习，适合需要掌握SQL Server 2000备份还原机制、排查还原失败原因并规范权限设置的读者参考。
1. 老系统还在跑，SQL Server 2000 的备份还原你真会吗？
上周帮一个做 ERP 的朋友救火，他们的用友 U8 跑在 Windows Server 2003 + SQL Server 2000 上，硬盘突然报 SMART 错误。运维小伙子第一反应是“我有 bak 文件”，结果还原时企业管理器弹了一串英文报错，折腾到凌晨两点。这事让我意识到，SQL Server 2000 虽然老，但大量制造业、零售、医疗的存量系统还在用它，数据库备份还原这个基本功，很多人其实只停留在“点右键、选还原”的层面。这篇笔记就把 MSSQL 2000 的备份还原、附加数据库、权限配置和几个血泪坑一次讲透，适合还在维护老系统的 DBA 和运维，也适合需要从旧库导数据到新环境的开发。核心就一句话：备份文件能不能还原，取决于你懂不懂它的逻辑和路径权限。
2. 备份与还原的底层逻辑：为什么 bak 文件不是万能后悔药
2.1 完整备份、差异备份与事务日志备份的区别
SQL Server 2000 的备份不是简单复制文件。它有三种模式，理解它们才能决定还原策略。完整备份记录整个数据库在某个时间点的状态，包括数据页和足够的事务日志，能独立还原。差异备份只记录自上次完整备份后变化的数据页，体积小、速度快，但必须依赖上一次完整备份才能还原。事务日志备份记录自上次日志备份后的所有事务，能把数据库恢复到故障前的某个时刻，但要求数据库恢复模式是“完整”或“大容量日志”。
我见过有人只做差异备份，结果完整备份文件被误删，差异备份直接变成废纸。常见做法是：每周一次完整备份，每天一次差异备份，每 15 分钟到 1 小时一次事务日志备份。这样 RPO 可以控制在分钟级，而不是热词里说的 24 小时。对于用友 U8 这类财务系统，RPO 超过 1 小时财务就要跳脚。
2.2 还原时的“数据库”与“从设备”到底选哪个
企业管理器的还原界面有两个选项：“数据库”和“从设备”。很多人搞不清。选“数据库”时，下拉列表里显示的是 SQL Server 实例中已经注册的备份历史记录，也就是之前在这台服务器上做过备份、且备份历史还在 msdb 里的那些。如果你拿到的 bak 文件是从别的服务器复制过来的，msdb 里没有它的记录，选“数据库”根本看不到它，必须选“从设备”，然后点“添加”浏览到 bak 文件。
这里有个细节：bak 文件本质上是一个或多个备份集组成的文件，一个 bak 里可以包含多次备份。点“添加”后，如果文件里有多个备份集，还原界面会让你选具体哪一个。我一般会先点“查看内容”确认备份集的时间戳和类型，避免还原错版本。
2.3 恢复模式与“在现有数据库上强制还原”的含义
“选项”标签页里的“在现有数据库上强制还原”对应的是 WITH REPLACE 选项。默认情况下，如果目标数据库已经存在，且备份文件里的数据库名和现有数据库名相同，SQL Server 会拒绝还原，防止误覆盖。勾选强制还原后，它会先删除现有数据库再重建。这个操作不可逆，但有时候必须用——比如数据库处于“恢复挂起”或“可疑”状态，不强制还原根本进不去。
另一个关键选项是“将数据库文件还原为”。备份文件里记录的是源服务器的物理文件路径，比如 D:\MSSQL\DATA\UFDATA.MDF。如果目标服务器没有 D 盘，或者路径不存在，还原会直接失败。这时候要在“选项”里把路径改成目标服务器上真实存在的目录，比如 E:\MSSQL\DATA\。我习惯在还原前先手动创建好目录，并确认 SQL Server 服务账户有写权限。
3. 从 bak 文件还原数据库：企业管理器操作与 T-SQL 双路径
3.1 图形界面还原的完整步骤与参数含义
打开企业管理器，展开 SQL Server 组，找到“数据库”，右键你要还原的目标数据库（如果不存在就右键“数据库”节点选“所有任务”里的“还原数据库”）。在“常规”页，还原方式选“从设备”，点“选择设备”，再点“添加”，浏览到 bak 文件。如果 bak 文件里有多个备份集，列表里会全部显示，选中你要的那个。
切到“选项”页，重点看三个地方：第一，“将数据库文件还原为”下面的“移至物理文件名”，确认路径存在且磁盘空间足够；第二，“恢复完成状态”选“使数据库可以继续运行，但无法还原其它事务日志”还是“使数据库不再运行，但能还原其它事务日志”，一般选前者；第三，如果目标库已存在且要覆盖，勾选“在现有数据库上强制还原”。点确定后，进度条走完会弹提示，成功的话数据库会变成可用状态。
提示：还原大库时，企业管理器界面可能假死，别急着杀进程，打开任务管理器看 sqlservr.exe 的 CPU 和磁盘 IO，只要还在动就等着。
3.2 用 T-SQL 还原：RESTORE DATABASE 语句拆解
图形界面背后就是 RESTORE 语句。在查询分析器里执行更可控，也方便脚本化。下面是一个典型还原脚本：
-- 先查看 bak 文件里有哪些备份集 RESTORE HEADERONLY FROM DISK = 'D:\backup\UFDATA.bak' GO -- 查看备份集里的逻辑文件名和物理路径 RESTORE FILELISTONLY FROM DISK = 'D:\backup\UFDATA.bak' GO -- 执行还原，WITH MOVE 重定向物理文件，WITH REPLACE 强制覆盖 RESTORE DATABASE UFDATA FROM DISK = 'D:\backup\UFDATA.bak' WITH MOVE 'UFDATA_Data' TO 'E:\MSSQL\DATA\UFDATA.MDF', MOVE 'UFDATA_Log' TO 'E:\MSSQL\DATA\UFDATA.LDF', REPLACE, RECOVERY GO第一段 RESTORE HEADERONLY 返回备份集列表，看 BackupType 字段：1 是完整备份，2 是差异备份，3 是事务日志备份。第二段 RESTORE FILELISTONLY 返回 LogicalName 和 PhysicalName，LogicalName 就是 WITH MOVE 里要写的名字。第三段是实际还原，MOVE 把源路径映射到目标路径，REPLACE 对应强制还原，RECOVERY 表示还原后数据库可用。如果还要继续还原差异备份或日志备份，把 RECOVERY 换成 NORECOVERY。
3.3 差异备份与事务日志的链式还原
假设你有完整备份 Full.bak、差异备份 Diff.bak、日志备份 Log.trn，还原顺序必须是：先还原完整备份（WITH NORECOVERY），再还原差异备份（WITH NORECOVERY），最后还原日志备份（WITH RECOVERY）。顺序错了或者中间漏了一个，SQL Server 会报“该备份集无法还原”之类的错误。
-- 1. 还原完整备份，保持不可用状态 RESTORE DATABASE UFDATA FROM DISK = 'D:\backup\Full.bak' WITH NORECOVERY, REPLACE GO -- 2. 还原差异备份，继续保持不可用 RESTORE DATABASE UFDATA FROM DISK = 'D:\backup\Diff.bak' WITH NORECOVERY GO -- 3. 还原事务日志，恢复可用 RESTORE LOG UFDATA FROM DISK = 'D:\backup\Log.trn' WITH RECOVERY GO注意差异备份还原时不需要 WITH MOVE，因为完整备份那一步已经确定了物理文件位置。日志还原用 RESTORE LOG 而不是 RESTORE DATABASE。如果日志链断了，比如中间某个日志文件丢失，只能还原到最后一个连续日志点，后面的数据就丢了。这就是为什么日志备份文件要按顺序编号保存，别用日期覆盖。
4. 附加 MDF/LDF 与权限配置：绕开还原失败的隐形墙
4.1 附加数据库的适用场景与操作流程
当你手里只有 MDF 和 LDF 文件，没有 bak 文件时，附加是唯一选择。典型场景是服务器崩溃后直接拷贝了数据文件，或者从开发环境拿来了数据库文件。操作流程：先把 MDF 和 LDF 放到目标服务器的非系统盘目录，比如 D:\MSSQL\DATA\。然后打开企业管理器，右键“数据库”节点，选“所有任务”里的“附加数据库”。点“…”按钮浏览到 MDF 文件，SQL Server 会自动识别同目录下的 LDF。如果 LDF 丢失或损坏，可以只附加 MDF，SQL Server 会尝试重建日志，但可能失败。
附加时要注意“指定数据库所有者”这一项。默认是 sa，但如果你的应用连接用的是其他登录名，附加后可能因为所有者不匹配导致权限问题。我一般附加后立刻用 sp_changedbowner 改成 sa 或应用专用账户。
4.2 Mssqluser 权限：为什么还原总是提示“拒绝访问”
SQL Server 2000 默认以本地系统账户或指定的服务账户运行。在 Windows Server 2003 上，常见的是以 Mssqluser 这个本地用户运行 SQL Server 服务。如果你的备份文件放在某个目录，或者还原目标目录，Mssqluser 没有完全控制权限，还原就会失败，报错通常是“操作系统错误 5（拒绝访问）”或“无法打开备份设备”。
解决方法是：右键备份文件所在目录和还原目标目录，选“属性”→“安全”→“添加”，把 Mssqluser 加进去，勾选“完全控制”。如果服务器上找不到 Mssqluser，去“服务”里看 SQL Server 服务的“登录”身份是什么，可能是 LocalSystem 或 NetworkService，那就给对应账户加权限。这个坑我踩过不止一次，尤其是从其他服务器拷贝 bak 文件过来，NTFS 权限不会跟着文件走，必须手动加。
4.3 用 sp_attach_db 和 sp_attach_single_file_db 脚本附加
图形界面附加偶尔会抽风，比如报“错误 1813：无法打开新数据库”或“错误 823：I/O 错误”。这时候用 T-SQL 更直接：
-- 附加 MDF 和 LDF EXEC sp_attach_db @dbname = 'UFDATA', @filename1 = 'D:\MSSQL\DATA\UFDATA.MDF', @filename2 = 'D:\MSSQL\DATA\UFDATA.LDF' GO -- 只有 MDF 时，尝试单文件附加 EXEC sp_attach_single_file_db @dbname = 'UFDATA', @physname = 'D:\MSSQL\DATA\UFDATA.MDF' GOsp_attach_db 最多支持 16 个文件，适合有多个 NDF 的情况。sp_attach_single_file_db 只附加 MDF，并重建日志，但要求数据库在分离时是干净的。如果数据库是崩溃后直接拷贝的，单文件附加大概率失败，需要先用第三方工具修复 MDF 或者从备份还原。
5. 避坑与排查：还原失败时先看这五个地方
5.1 现象：还原时报“备份集中的数据库备份与现有数据库不同”
原因：bak 文件里的数据库名和你要还原的目标数据库名不一致，或者目标库已存在且没有勾选强制还原。解决：在还原界面的“常规”页把“还原为数据库”改成 bak 里的原名，或者勾选“选项”页的“在现有数据库上强制还原”。如果还是不行，用 RESTORE FILELISTONLY 确认备份集里的数据库名。
5.2 现象：还原进度到 100% 后报“无法打开物理文件，操作系统错误 5”
原因：Mssqluser 或 SQL Server 服务账户对目标目录没有写权限。解决：给目标目录加 Mssqluser 完全控制权限，或者把还原路径改到 SQL Server 默认的 DATA 目录下。注意，即使你是管理员，SQL Server 服务账户没权限照样失败。
5.3 现象：附加数据库时报“错误 823：I/O 错误”或“错误 9004”
原因：MDF 文件损坏，或者 LDF 文件与 MDF 不匹配。解决：先尝试 sp_attach_single_file_db 只附加 MDF，如果失败，用 DBCC CHECKDB 检查文件，或者从备份还原。如果是从其他服务器拷贝的文件，确认 SQL Server 版本一致，2000 的 MDF 不能附加到 2005 及以上，需要先升级。
5.4 现象：还原后数据库显示“可疑”或“恢复挂起”
原因：还原过程中事务日志不完整，或者还原时选了 WITH NORECOVERY 但后续没有继续还原日志。解决：如果还有日志备份，继续用 RESTORE LOG 还原；如果没有，尝试执行 sp_resetstatus 重置状态，然后 DBCC CHECKDB 修复，但可能丢数据。预防方法是还原完整备份时如果还要还原差异或日志，必须用 NORECOVERY。
5.5 现象：用友 U8 备份提示“获取数据库 mfmeta_001 大小时出错：BOF 或 EOF 中有一个是‘真’”
原因：这个报错通常不是 SQL Server 本身的问题，而是用友 U8 的备份程序在读取某个表或文件时遇到了损坏或权限不足。解决：先确认 SQL Server 服务账户对 U8 的备份临时目录有完全控制权限；然后用 DBCC CHECKDB 检查数据库一致性；如果 mfmeta_001 这个对象损坏，从最近的 bak 还原。我遇到过几次，最后发现是磁盘坏道导致 MDF 文件局部损坏，只能还原到故障前。
6. 把备份还原做成可验证的例行操作
老系统的备份还原，最怕的不是不会操作，而是“以为备份能用，真出事时还原不了”。我现在的习惯是：每次做完完整备份，立刻在测试服务器上还原一遍，确认 bak 文件可读、路径可写、权限正确。这个验证流程花 10 分钟，但能避免凌晨两点救火。
具体做法：写一个批处理脚本，用 osql 执行 RESTORE VERIFYONLY 检查备份集完整性，再自动还原到一个临时库名，跑一句 SELECT COUNT(*) 确认数据可查，最后 DROP 掉临时库。脚本核心如下：
-- verify_backup.sql RESTORE VERIFYONLY FROM DISK = 'D:\backup\UFDATA.bak' GO RESTORE DATABASE UFDATA_Verify FROM DISK = 'D:\backup\UFDATA.bak' WITH MOVE 'UFDATA_Data' TO 'E:\MSSQL\DATA\UFDATA_Verify.MDF', MOVE 'UFDATA_Log' TO 'E:\MSSQL\DATA\UFDATA_Verify.LDF', REPLACE, RECOVERY GO USE UFDATA_Verify GO SELECT COUNT(*) FROM sysobjects WHERE type = 'U' GO DROP DATABASE UFDATA_Verify GO用 osql -S 服务器名 -U sa -P 密码 -i verify_backup.sql 执行。RESTORE VERIFYONLY 只读备份集头，不实际还原，速度很快。后面的还原和查询验证了物理文件和权限。最后 DROP 掉临时库，不影响生产。
还有一个技巧：把备份文件按“数据库名_备份类型_yyyyMMddHHmm.bak”命名，比如 UFDATA_FULL_202405201200.bak、UFDATA_DIFF_202405210200.bak。还原时看文件名就知道顺序，不用去查 msdb。备份目录单独挂一块盘，和数据库数据盘分开，避免一起坏。
从那以后我每次交付老系统运维，都强制走一遍“备份→验证还原→记录路径权限”的流程，再也不敢只点一下备份就完事。希望帮到你。
本文还有配套的精品资源，点击获取
