企业官网建设流程全解析

简介：这份PDF图文教程面向SQL Server 2000数据库管理员与运维初学者，聚焦数据库备份还原这一核心运维场景，帮助读者掌握数据安全保障与业务连续性的基础操作。内容围绕完整备份、差异备份与事务日志备份三种类型展开，并覆盖企业管理器下的还原流程、从设备导入备份文件、恢复模式选项设置，以及MDF与LDF文件的附加数据库方法和Mssqluser权限配置要点，可帮助读者排查还原失败、路径错误等常见问题。资源包共1个PDF文件，大小约327KB，轻量便携，适合随时查阅对照。目前已有302人学习，说明该教程在老旧系统维护场景中仍有实用参考价值，适合需要快速上手SQL Server 2000备份还原操作的技术人员收藏使用。

1. SQL Server 2000 备份还原：老库还在跑，这件事就绕不开

机房角落里那台工控机还在跑 Windows 2000 Server，上面挂着一个 SQL Server 2000 实例，里面存着十几年的生产工单。你明知道它老得掉牙，可业务没停，你就得管。SQL Server 2000 数据库备份还原这件事，说穿了就两条路：一条是图形界面点鼠标，一条是查询分析器敲 T-SQL。前者适合偶尔救急，后者适合写成作业每天自动跑。麻烦在于，这版本太老，网上搜到的教程大多默认你用的是 2005 以后的版本，界面截图对不上，命令语法也有出入，照着做很容易在“还原”那一步翻车。这篇笔记就按我实际处理老库的顺序，把备份、还原、常见报错和几个容易忽略的参数讲清楚，适合还在维护 SQL Server 2000 的运维和开发，也适合第一次接手老系统、需要把库完整搬走的人。

2. 先搞清楚 SQL Server 2000 有哪几种备份，别上来就点完整备份

2.1 完整备份、差异备份、事务日志备份分别解决什么问题

SQL Server 2000 的备份类型和后面版本大体一致，但界面和选项位置不同。完整备份是把整个数据库的数据和日志一起写进一个 .bak 文件，恢复时能回到备份完成的那一刻。差异备份只记录上次完整备份之后变化的数据页，文件小、速度快，但必须依附于一个完整备份才能还原。事务日志备份记录的是日志文件里的所有事务，能把数据库恢复到某个时间点，前提是数据库的恢复模式是“完整”或“大容量日志”。

我一般这样组合：每周日做一次完整备份，周一到周六每天做一次差异备份，如果业务对数据丢失时间敏感，再加每小时一次的事务日志备份。SQL Server 2000 默认的恢复模式是“简单”，这种模式下事务日志备份不可用，日志会在检查点后自动截断。如果你需要日志备份，先去数据库属性里把恢复模式改成“完整”。

提示：改恢复模式之前先做一次完整备份，否则切换瞬间的日志链会断，后面日志备份可能报错。

2.2 用企业管理器做一次完整备份的步骤

打开企业管理器，展开服务器组，找到目标数据库，右键选择“所有任务”里的“备份数据库”。在弹出的窗口里，备份类型选“数据库-完整”，目标选“磁盘”，然后指定一个路径，比如D:\Backup\MyDB_Full_20240101.bak。如果勾选“重写现有媒体”，新备份会覆盖同名文件；不勾选则追加。老库的备份文件通常不大，但磁盘空间要留够，至少是数据库大小的两倍。

点“确定”之后，SQL Server 2000 会开始备份。备份过程中可以在“备份进度”窗口看到进度条。如果数据库比较大，建议在业务低峰期做，因为完整备份会占用较多 I/O。备份完成后，去目标路径确认文件存在，大小不为 0。这一步看着简单，但我见过有人把路径写到不存在的目录，企业管理器不报错，备份直接失败，事后才发现。

2.3 用 T-SQL 做备份，方便写成作业

图形界面适合手动操作，但如果你要每天定时备份，用 T-SQL 更靠谱。在查询分析器里连上实例，执行下面这段：

-- 完整备份，覆盖同名文件 BACKUP DATABASE [MyDB] TO DISK = N'D:\Backup\MyDB_Full_20240101.bak' WITH INIT, NAME = N'MyDB-Full Backup', STATS = 10;

WITH INIT表示覆盖现有备份集，不加则追加。STATS = 10让 SQL Server 每完成 10% 在消息窗口输出一次进度。NAME是备份集名称，方便以后用RESTORE HEADERONLY查看。

差异备份的写法：

BACKUP DATABASE [MyDB] TO DISK = N'D:\Backup\MyDB_Diff_20240101.bak' WITH DIFFERENTIAL, INIT, STATS = 10;

事务日志备份：

BACKUP LOG [MyDB] TO DISK = N'D:\Backup\MyDB_Log_20240101.trn' WITH INIT, STATS = 10;

这三条命令可以放进 SQL Server 代理作业里，按计划执行。SQL Server 2000 的代理作业配置和后面版本差不多，新建作业、加步骤、设计划就行。注意作业的“所有者”要设成有权限的账号，否则执行时会报权限错误。

2.4 备份文件怎么验证有没有坏

备份做完不等于能用。我习惯用RESTORE VERIFYONLY检查备份集是否完整：

RESTORE VERIFYONLY FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak';

如果返回“备份集有效”，说明文件没损坏。这个命令只读备份头，不实际还原，速度很快。另一个办法是RESTORE HEADERONLY，能看到备份集里的数据库名、备份类型、备份时间、LSN 等信息。老库的备份文件如果放在网络共享上，还要注意权限和网络稳定性，我遇到过备份写到一半网络断了，文件大小正常但实际不完整，VERIFYONLY直接报错。

3. 还原才是真正容易翻车的地方：路径、权限、版本一个都不能错

3.1 还原完整备份的最小命令

还原完整备份的基本语法：

RESTORE DATABASE [MyDB] FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak' WITH RECOVERY, STATS = 10;

WITH RECOVERY表示还原完成后数据库可用。如果后面还要接着还原差异备份或日志备份，这里要改成WITH NORECOVERY，否则数据库会进入“正在还原”状态，后续还原会报错。

如果目标数据库已经存在，需要先确保没有连接占用，或者用WITH REPLACE覆盖：

RESTORE DATABASE [MyDB] FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak' WITH REPLACE, RECOVERY, STATS = 10;

REPLACE会覆盖现有数据库，包括文件。用之前确认目标库确实可以丢。

3.2 还原时文件路径不对怎么办

SQL Server 2000 的备份文件里记录了原始数据库的数据文件和日志文件路径。如果还原到另一台机器，或者原路径不存在，还原会失败，报“无法打开备份设备”或“文件路径无效”。解决办法是用WITH MOVE把文件重定向到新路径：

RESTORE DATABASE [MyDB] FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak' WITH MOVE N'MyDB_Data' TO N'E:\Data\MyDB_Data.mdf', MOVE N'MyDB_Log' TO N'E:\Data\MyDB_Log.ldf', RECOVERY, STATS = 10;

MyDB_Data和MyDB_Log是逻辑文件名，不是物理文件名。用RESTORE FILELISTONLY可以查出来：

RESTORE FILELISTONLY FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak';

结果里LogicalName列就是逻辑文件名，PhysicalName是原始物理路径。还原到新环境时，先跑这条命令，把逻辑名和你要放的新路径对应好，再写MOVE子句。

3.3 差异备份和日志备份的还原顺序

如果你有完整备份 + 差异备份 + 日志备份，还原顺序不能乱：

1. 先还原完整备份，用WITH NORECOVERY。
2. 再还原差异备份，用WITH NORECOVERY。
3. 最后还原日志备份，用WITH RECOVERY。

示例：

-- 第一步：完整备份 RESTORE DATABASE [MyDB] FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak' WITH NORECOVERY, STATS = 10; -- 第二步：差异备份 RESTORE DATABASE [MyDB] FROM DISK = N'D:\Backup\MyDB_Diff_20240101.bak' WITH NORECOVERY, STATS = 10; -- 第三步：日志备份 RESTORE LOG [MyDB] FROM DISK = N'D:\Backup\MyDB_Log_20240101.trn' WITH RECOVERY, STATS = 10;

如果中间某一步报错，数据库会停在“正在还原”状态。想放弃还原，执行：

RESTORE DATABASE [MyDB] WITH RECOVERY;

这会让数据库直接可用，但只恢复到当前已还原的部分。

3.4 还原到不同版本或不同实例的注意事项

SQL Server 2000 的备份不能直接还原到 SQL Server 2005 及更高版本，反过来也不行。高版本的备份文件在低版本上无法识别，低版本的备份文件在高版本上虽然能还原，但会触发升级，还原后数据库兼容级别会变。如果你只是想把老库搬到新实例，常见做法是在老实例上做完整备份，然后在新实例上用“还原数据库”向导，让新实例自动升级。升级前务必在测试环境验证一遍，老库里的某些 T-SQL 语法在新版本可能不兼容。

另外，SQL Server 2000 Desktop Engine（MSDE）的备份还原和标准版基本一致，但 MSDE 没有企业管理器图形界面，只能用命令行工具osql或sqlcmd（如果装了）。用osql执行备份：

osql -S .\实例名 -U sa -P 密码 -Q "BACKUP DATABASE [MyDB] TO DISK = 'D:\Backup\MyDB.bak' WITH INIT"

MSDE 的还原同样用osql调RESTORE DATABASE语句。注意 MSDE 有 2GB 数据库大小限制，备份文件超过这个限制还原会失败。

4. 避坑：SQL Server 2000 备份还原最常见的 5 个问题

4.1 还原报“数据库正在使用，无法获得独占访问”

现象：执行RESTORE DATABASE时提示数据库正在使用，无法还原。

原因：有活动连接占着数据库，SQL Server 2000 不像后面版本有WITH ROLLBACK IMMEDIATE选项，不能自动踢掉连接。

解决：先把数据库设成单用户模式，再还原。命令：

ALTER DATABASE [MyDB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

如果这条命令在 SQL Server 2000 上不支持WITH ROLLBACK IMMEDIATE，就先用sp_who2找到连接，用KILL杀掉。或者直接重启 SQL Server 服务，但生产环境慎用。

4.2 备份文件很大，还原时磁盘空间不够

现象：还原到一半报“磁盘空间不足”。

原因：备份文件里包含数据和日志，还原时需要额外空间解压和重建。如果原库 10GB，备份文件可能 8GB，但还原后数据文件加日志文件可能超过 15GB。

解决：还原前先估算目标库大小，用RESTORE FILELISTONLY看Size列，留出至少 1.5 倍空间。如果空间紧张，可以只还原数据文件，日志文件设小一点，但 SQL Server 2000 对日志文件大小控制不如后面版本灵活。

4.3 还原后数据库变成“只读”或“可疑”

现象：还原完成，但数据库状态显示“可疑”或“只读”，无法写入。

原因：常见于还原时文件路径权限不对，或者备份文件来自不同排序规则的实例。SQL Server 2000 的排序规则在实例级别设置，跨实例还原时如果排序规则不一致，数据库可能无法正常启动。

解决：检查 SQL Server 服务账号对数据目录是否有完全控制权限。排序规则问题比较麻烦，通常需要在同排序规则的实例上还原，或者用bcp导出数据再导入。老库迁移前，先确认源实例和目标实例的排序规则。

4.4 事务日志备份失败，报“日志已截断”

现象：执行BACKUP LOG时报错，提示日志已截断或没有可备份的日志。

原因：数据库恢复模式是“简单”，或者之前做过完整备份后没有做过日志备份，日志链断了。

解决：把恢复模式改成“完整”，做一次完整备份，然后再做日志备份。如果日志文件已经很大，先做一次完整备份，再收缩日志文件，但收缩前确认不需要恢复到之前的时间点。

4.5 用 osql 执行备份时中文路径或密码含特殊字符报错

现象：osql命令里路径含中文，或者 sa 密码含$、!等字符，命令执行失败。

原因：osql对特殊字符处理不好，命令行解析容易出错。

解决：路径尽量用英文，密码避免特殊字符。如果必须用，把密码写在脚本文件里，用-i参数执行，或者用-P参数时加引号。MSDE 环境下，我一般把备份语句写成一个.sql文件，然后用osql -S 实例 -U sa -P 密码 -i backup.sql执行，这样最稳。

5. 老库备份还原的进阶习惯：脚本化、验证、留后路

5.1 把备份还原写成可重复执行的脚本

手动点企业管理器只适合救急，长期维护一定要脚本化。我一般会建一个D:\Scripts\目录，里面放几个文件：

• full_backup.sql：完整备份语句
• diff_backup.sql：差异备份语句
• log_backup.sql：日志备份语句
• restore_full.sql：完整还原语句，带MOVE和NORECOVERY
• restore_diff.sql：差异还原语句
• restore_log.sql：日志还原语句，带RECOVERY

然后用 Windows 任务计划或 SQL Server 代理作业调用osql执行。脚本里的路径和数据库名用变量替换，方便复用到其他库。比如：

-- full_backup.sql DECLARE @dbName NVARCHAR(100); DECLARE @backupPath NVARCHAR(200); SET @dbName = N'MyDB'; SET @backupPath = N'D:\Backup\' + @dbName + N'_Full_' + CONVERT(NVARCHAR(8), GETDATE(), 112) + N'.bak'; BACKUP DATABASE @dbName TO DISK = @backupPath WITH INIT, STATS = 10;

这样每天生成的备份文件名带日期，不会互相覆盖。还原时按日期找对应文件就行。

5.2 定期做还原演练，别等出事才试

备份文件能不能还原，只有真正还原一次才知道。我习惯每季度做一次还原演练：在一台测试机上装同样的 SQL Server 2000 实例，把最近的生产备份还原进去，然后跑几个关键查询验证数据。演练时重点看三件事：还原耗时、还原后数据库状态、关键表行数是否对得上。如果还原失败，趁业务没停还有时间排查；等生产库真挂了再发现备份不能用，那就只能后悔了。

5.3 保留多份备份，至少一份离线

SQL Server 2000 的备份文件默认放在本地磁盘，如果磁盘坏了，备份也跟着没。我一般会保留三份：一份在本地D:\Backup\，一份在另一台机器的共享目录，一份定期拷到移动硬盘上离线保存。离线那份最重要，勒索病毒或者误删除时，只有离线备份能救你。拷贝到移动硬盘后，记得用RESTORE VERIFYONLY验证一遍，确认文件完整。

5.4 用 RESTORE HEADERONLY 快速定位该用哪个备份

备份文件多了以后，光看文件名不一定能确定里面是什么。用RESTORE HEADERONLY可以列出备份集里的详细信息：

RESTORE HEADERONLY FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak';

结果里BackupType列：1 是完整备份，2 是差异备份，3 是事务日志备份。BackupStartDate和BackupFinishDate是备份起止时间。DatabaseName是数据库名。还原前先跑这条命令，确认备份集类型和时间，避免拿差异备份当完整备份还原，那种错误一报就是“无法还原，因为备份集不包含完整备份”。

5.5 一个具体技巧：用 WITH MOVE 把老库还原到新路径并重命名

如果你想把老库还原成另一个名字，比如MyDB_Test，同时把文件放到新路径，可以这样写：

RESTORE DATABASE [MyDB_Test] FROM DISK = N'D:\Backup\MyDB_Full_20240101.bak' WITH MOVE N'MyDB_Data' TO N'E:\Test\MyDB_Test_Data.mdf', MOVE N'MyDB_Log' TO N'E:\Test\MyDB_Test_Log.ldf', RECOVERY, STATS = 10;

注意目标数据库名MyDB_Test不能和现有数据库重名。MOVE子句里的逻辑文件名必须和备份集里的一致，用RESTORE FILELISTONLY查。还原完成后，MyDB_Test就是独立的一份数据，改它不影响原库。这个技巧在做数据验证、测试升级、排查数据问题时特别有用。

我自己的习惯是：每次接手一个老库，先做一次完整备份，用RESTORE VERIFYONLY验证，再用RESTORE FILELISTONLY记下逻辑文件名和原始路径，然后写一套还原脚本放在手边。老库不出事则已，一出事就是急事，手边有脚本和验证过的备份，心里才不慌。希望帮到你。

本文还有配套的精品资源，点击获取