企业官网建设流程全解析

简介：本资源是一份面向数据库运维工程师与IT系统管理员的实战型技术文档，聚焦Symantec Backup Exec 2010对SQL Server 2008 R2数据库的备份与还原全流程操作。文档以真实测试环境为背景，完整覆盖Agent安装、SQL服务验证、test数据库创建、完全备份作业配置（含凭据设置、介质选择、SQL专属选项）、以及三种典型还原场景——删除后重建还原、覆盖还原和重定向还原（含跨实例恢复），并附关键界面截图与操作逻辑说明。资源为单文件Word文档（.doc格式），共1个文件，大小2.46MB，内容结构清晰、步骤可复现，适合作为日常运维参考或灾备方案学习材料。目前已有296人下载学习，读者可直接获取标准化操作路径、避坑提示及多场景还原对比思路，快速掌握企业级SQL Server数据保护的核心实践。

1. Symantec Backup Exec 2010 备份还原 SQL Server 2008 R2：不是点几下就能跑通的“图形界面幻觉”

你手头有一台运行着 SQL Server 2008 R2 的 Windows Server 2008 R2 服务器，业务系统还在跑，没人敢停；领导甩来一份十年前的老文档《Symantec Backup Exec 2010 备份还原SQL Server 2008 R2 数据库.doc》，要求“按这个恢复昨天误删的订单表”。你双击打开 Backup Exec 控制台，选中那个标着“SQL-Full-20231025”的备份作业，右键 → “还原”，勾选数据库名，点击“开始”——然后卡在“正在初始化 SQL Server Agent 服务…”十分钟不动，日志里只有一行红字：V-79-57344-34126: Failed to connect to SQL Server instance 'MSSQLSERVER'。这不是软件坏了，而是 Backup Exec 2010 和 SQL Server 2008 R2 这对黄金搭档，在真实生产环境里根本不是开箱即用的关系。它依赖 SQL Server VDI（Virtual Device Interface）驱动、特定版本的 SQL Server Agent 权限模型、Windows 服务账户上下文隔离，以及一个被很多人忽略的硬性前提：必须用 SQL Server 原生备份通道（而非文件级拷贝）生成的备份集，才能被 Backup Exec 正确识别并还原。本文不讲理论套话，只拆解一线工程师当年在客户机房熬夜三晚才跑通的完整链路：从 SQL Server 实例注册、VDI 驱动加载验证，到还原时绕过“挂载模式”陷阱、强制指定还原路径、修复孤立用户映射——每一步命令、每一处勾选项、每一个报错代码，都对应真实翻车现场。适合正在维护老旧 ERP/CRM 系统、手握 Backup Exec 2010 许可证、且不能升级 SQL Server 版本的运维和 DBA。

2. 为什么 Backup Exec 2010 能“看见” SQL Server 2008 R2？先搞懂 VDI 和 SQL Agent 的共生关系

Backup Exec 2010 对 SQL Server 的备份还原能力，不是靠扫描.mdf/.ldf文件实现的，而是通过 SQL Server 提供的Virtual Device Interface（VDI）接口，以“虚拟备份设备”的身份接入 SQL Server 的备份引擎。这决定了它和传统文件拷贝工具（如 robocopy 或再生龙）有本质区别：VDI 允许 Backup Exec 在 SQL Server 事务日志持续写入的同时，获取数据库的一致性快照（Consistent Snapshot），而无需停止服务或设置数据库为单用户模式。但这个能力的前提是 SQL Server 主动“信任” Backup Exec 的 VDI 客户端。而信任的桥梁，就是SQL Server Agent 服务——它不仅是调度作业的后台进程，更是 Backup Exec 与 SQL Server 之间执行还原脚本、验证数据库状态、重建日志链的唯一执行代理。所以，第一步不是打开 Backup Exec，而是确认 SQL Server 2008 R2 的底层服务是否已为 VDI 做好准备。

2.1 验证 SQL Server 实例是否启用 VDI 支持（关键前置检查）

Backup Exec 2010 安装时会向目标 SQL Server 注册一个名为BE_SQLVDI的虚拟设备（实际是注册表项 + DLL 文件）。但很多管理员在重装 SQL Server 后未重新注册，或因权限问题导致注册失败。最直接的验证方式是登录 SQL Server，执行以下 T-SQL：

-- 在 SQL Server Management Studio (SSMS) 中，以 sa 或 sysadmin 角色执行 SELECT * FROM sys.backup_devices WHERE name = 'BE_SQLVDI';

如果返回空结果，说明 VDI 设备未注册。此时需手动注册（注意：必须用 SQL Server 安装账户或 Local System 账户执行）：

-- 执行前确保 Backup Exec 2010 的安装目录已知（默认 C:\Program Files\Symantec\Backup Exec\） -- 并确认 SQL Server 2008 R2 是 64 位（绝大多数生产环境都是） EXEC sp_addumpdevice 'disk', 'BE_SQLVDI', 'C:\Program Files\Symantec\Backup Exec\SQLVDI.dll';

提示：sp_addumpdevice的第三个参数不是路径，而是 DLL 文件的完整物理路径。若 SQL Server 是 32 位（极罕见），需指向Program Files (x86)下的对应 DLL。注册后重启 SQL Server 服务，再查sys.backup_devices应出现BE_SQLVDI记录。

2.2 SQL Server Agent 必须以高权限账户运行（不是 Network Service 就行）

Backup Exec 还原时，会通过 SQL Server Agent 启动一个 T-SQL 脚本，执行RESTORE DATABASE ... WITH MOVE、ALTER DATABASE ... SET SINGLE_USER、ALTER DATABASE ... SET MULTI_USER等操作。如果 Agent 服务账户权限不足（例如仅是NT AUTHORITY\Network Service），将无法修改数据库状态或访问还原目标路径。必须将 SQL Server Agent 服务账户改为域账户或本地管理员组成员：

1. 打开SQL Server 配置管理器→SQL Server 服务
2. 右键SQL Server Agent (MSSQLSERVER)→属性→登录选项卡
3. 选择此账户，输入一个具有sysadmin权限的 Windows 账户（如DOMAIN\svc-sqlagent）
4. 切换到高级选项卡，勾选“允许服务与桌面交互”（Backup Exec 2010 某些 GUI 组件依赖此）
5. 点击确定，重启 SQL Server Agent 服务

验证方式：在 SSMS 中执行SELECT SUSER_SNAME() AS CurrentUser;，然后右键 SQL Server Agent → “启动”，观察 Windows 事件查看器中 Application 日志是否有The SQLServerAgent service is now running.且无Logon failure错误。

2.3 Backup Exec 控制台必须“感知”到 SQL Server 实例（注册而非发现）

Backup Exec 2010 不会自动扫描网络发现 SQL Server。你必须在控制台中显式添加 SQL Server 实例，否则还原向导里根本不会列出数据库名称：

1. 打开 Backup Exec 控制台 →工具→选项→SQL Server
2. 点击添加→ 输入 SQL Server 主机名（如DBSRV01）
3. 实例名：如果是默认实例，留空；如果是命名实例（如SQLEXPRESS），必须准确填写
4. 身份验证：选择Windows 身份验证（强烈推荐），并确保 Backup Exec 服务账户（通常是Local System或指定域账户）已在 SQL Server 中被授予sysadmin角色
5. 点击测试连接—— 成功后，该实例才会出现在“还原”向导的“SQL Server 数据库”节点下

参数说明：此处的“测试连接”实际调用的是sqlcmd -S <server>\<instance> -E -Q "SELECT @@VERSION"。若失败，请检查 SQL Server 是否启用 TCP/IP 协议、防火墙是否放行 1433 端口（或命名实例的动态端口）、以及SQL Server Browser服务是否运行（对命名实例必需）。

3. 备份作业配置：必须启用“应用一致性”且禁用“文件级备份”选项

Backup Exec 2010 提供两种 SQL Server 备份方式：应用感知备份（Application-Aware Backup）和文件级备份（File-Level Backup）。前者走 VDI 通道，后者只是把.mdf/.ldf文件当普通文件拷贝。只有应用感知备份生成的备份集，才能被 Backup Exec 正确还原为可挂载的数据库。而默认新建的备份作业，很可能勾选了错误的选项。

3.1 创建 SQL Server 专用备份作业（非通用文件备份）

1. 在 Backup Exec 控制台 →作业→新建备份作业
2. 在“选择要备份的数据”页面，不要点击“本地计算机”，而是展开左侧树状图，找到你刚注册的 SQL Server 实例（如DBSRV01\MSSQLSERVER）
3. 展开该实例 → 勾选具体数据库（如OrderDB,CustomerDB），不要勾选“系统数据库”除非你明确需要（master还原需特殊处理）
4. 点击下一步，进入“选择备份选项”页面

3.2 关键勾选项：锁定 VDI 通道的三个开关

在“选择备份选项”页面，必须严格设置以下三项：

注意：下方“高级”按钮里的“文件级备份”选项（通常在“常规”标签页）必须取消勾选。这个选项一旦启用，Backup Exec 会忽略 VDI，直接复制数据文件，导致后续还原时无法识别为 SQL Server 备份集，报错V-79-57344-17002: The backup set does not contain a valid SQL Server database backup。

3.3 备份目标与保留策略：避免磁盘空间耗尽的硬约束

Backup Exec 2010 默认将备份写入磁带或 B2D（Backup-to-Disk）文件夹。对于 SQL Server 2008 R2，强烈建议使用 B2D 目标，并设置严格的保留策略：

• B2D 目标路径：选择非系统盘（如D:\BE_Backup\SQL_Full），确保剩余空间 ≥ 3 倍数据库大小（VDI 备份含日志压缩，但仍需冗余）
• 保留策略：在作业属性 → “计划” → “覆盖保护”中，设置“覆盖旧备份”并指定天数（如 7 天）。SQL Server 备份集是链式结构（Full → Diff → Log），若 Full 备份被覆盖，后续所有增量均失效。

验证备份成功：作业完成后，在 Backup Exec 控制台 →作业历史记录中，找到该作业，双击打开 → 查看“详细信息”页。正常成功的 SQL Server 备份，其“操作”列应显示SQL Server Database，而非File System；“状态”为成功；“消息”中应包含V-79-57344-33024: Successfully backed up database 'OrderDB'。

4. 还原操作：绕过“挂载模式”陷阱，强制指定路径并修复用户映射

还原是比备份更易翻车的环节。Backup Exec 2010 的还原向导默认采用“挂载模式（Mount Mode）”，即先将数据库还原为临时状态，再由 SQL Server Agent 启动并验证。但 SQL Server 2008 R2 在某些补丁级别（如 SP3 之后）对此支持不稳定，极易卡死在“正在挂载…”。必须切换为“原地还原（In-Place Restore）”并手动干预路径与用户。

4.1 还原向导中的三个致命勾选项（必须改）

1. 在 Backup Exec 控制台 →还原→ 选择你的 SQL Server 备份作业 → 右键 →还原
2. 在“选择要还原的数据”页面，勾选目标数据库（如OrderDB）
3. 点击下一步，进入“还原选项”页面 →点击“高级”按钮

关键设置在此页：

• 还原类型：选择“原地还原（In-Place Restore）”（不是“挂载还原”）
• 还原数据库文件到：选择“原始位置”（若需还原到新路径，必须手动编辑，见 4.2）
• 还原数据库日志到：选择“原始位置”
• 还原后状态：选择“使数据库可以立即使用（RECOVERY）”（若需后续还原日志，则选 NORECOVERY，但需手动执行RESTORE LOG）

玄学经验：若还原后数据库处于Restoring状态且无法访问，90% 是因为此处选了NORECOVERY但未继续还原日志。生产环境紧急恢复，务必选RECOVERY。

4.2 强制指定还原路径：解决“文件已存在”和“路径不存在”双坑

SQL Server 2008 R2 的.mdf/.ldf文件路径可能与备份时不同（如 D:\Data\ 变为 E:\SQLData\）。Backup Exec 默认尝试还原到原始路径，若目标盘符不存在或权限不足，会报错V-79-57344-34001: Cannot create file 'D:\Data\OrderDB.mdf'。此时必须手动映射：

1. 在“还原选项” → “高级”页，勾选“重定向还原”
2. 点击“重定向”按钮 → 弹出“重定向还原”对话框
3. 左侧列表显示备份中的文件（如OrderDB_Data.mdf,OrderDB_Log.ldf）
4. 在右侧“还原到”列，逐个输入新路径（如E:\SQLData\OrderDB.mdf,E:\SQLLog\OrderDB_log.ldf）
5. 确保目标文件夹（E:\SQLData\,E:\SQLLog\）已存在且 SQL Server 服务账户有完全控制权限

血泪经验：不要依赖 Backup Exec 自动创建文件夹。它没有mkdir -p功能，遇到E:\SQLData\SubFolder\会直接失败。务必提前用icacls "E:\SQLData" /grant "NT SERVICE\MSSQLSERVER":(OI)(CI)F授予权限。

4.3 还原后必做的三件事：孤立用户、排序规则、兼容级别

还原完成 ≠ 数据库可用。SQL Server 2008 R2 还原后常见三大问题：

1. 孤立用户（Orphaned User）：数据库用户存在，但登录名在master中缺失或 SID 不匹配

   -- 在还原后的数据库中执行（如 OrderDB） USE OrderDB; EXEC sp_change_users_login 'Report'; -- 报告所有孤立用户 -- 若发现 user1 孤立，且 master 中有同名登录名： EXEC sp_change_users_login 'Auto_Fix', 'user1';

2. 排序规则冲突：若源库与目标实例排序规则不同（如SQL_Latin1_General_CP1_CI_ASvsChinese_PRC_CI_AS），查询会报错Cannot resolve collation conflict

   -- 检查当前数据库排序规则 SELECT DATABASEPROPERTYEX('OrderDB', 'Collation') AS Collation; -- 若需修改（谨慎！需重建所有索引） ALTER DATABASE OrderDB COLLATE SQL_Latin1_General_CP1_CI_AS;

3. 兼容级别降级：还原后兼容级别可能变为 90（SQL Server 2005），导致新语法报错

   -- 设置为 SQL Server 2008 R2 的 100 级别 ALTER DATABASE OrderDB SET COMPATIBILITY_LEVEL = 100;

5. 避坑指南：Backup Exec 2010 + SQL Server 2008 R2 的五个真实翻车现场

这些不是文档里的警告，而是我在三套不同客户环境里亲手填过的坑，每一条都附带现象、根因和一招毙命的解法。

5.1 现象：还原作业提交后立即失败，日志报V-79-57344-34126: Failed to connect to SQL Server instance 'MSSQLSERVER'

原因：Backup Exec 服务账户（默认Local System）无法通过 Windows 身份验证连接到 SQL Server。Local System在网络中以NT AUTHORITY\SYSTEM身份出现，而 SQL Server 的sysadmin角色通常只授予域账户或本地管理员。
解决：在 SQL Server 中执行CREATE LOGIN [NT AUTHORITY\SYSTEM] FROM WINDOWS; ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT AUTHORITY\SYSTEM];。或者，将 Backup Exec 服务改为使用一个已获sysadmin权限的域账户。

5.2 现象：还原成功，但数据库状态为Recovery Pending，SSMS 中显示“数据库正在恢复…”且无法访问

原因：SQL Server 尝试回滚未提交事务时，日志文件（.ldf）损坏或路径权限不足，导致恢复进程卡死。
解决：

1. 将数据库设为紧急模式：ALTER DATABASE OrderDB SET EMERGENCY;
2. 尝试修复：DBCC CHECKDB ('OrderDB', REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS;（慎用！可能丢数据）
3. 更安全做法：用RESTORE DATABASE ... WITH REPLACE, RECOVERY重新还原，确保.ldf文件路径可写且空间充足。

5.3 现象：还原向导中能看见数据库列表，但勾选后提示No valid backup sets found for this database

原因：备份作业未启用“应用感知处理”，或 SQL Server 实例注册时实例名填写错误（如把DBSRV01\SQLEXPRESS写成DBSRV01\sqlexpress—— SQL Server 实例名区分大小写）。
解决：在 Backup Exec 的 SQL Server 注册列表中删除错误条目，重新添加，严格按 SQL Server 配置管理器中显示的实例名输入（可通过SELECT @@SERVICENAME查询）。

5.4 现象：还原到新路径后，数据库能打开，但所有表都显示“对象名无效”，SELECT * FROM dbo.Orders报错

原因：还原时未正确重定向.mdf/.ldf，导致 SQL Server 加载了旧路径的文件（可能已被其他进程占用），而新路径文件是空的。
解决：

1. 在 SSMS 中执行SELECT physical_name FROM sys.database_files;确认当前文件路径
2. 若路径仍指向旧盘符，用ALTER DATABASE OrderDB MODIFY FILE (NAME = 'OrderDB_Data', FILENAME = 'E:\SQLData\OrderDB.mdf');修改逻辑文件路径
3. 必须先将数据库设为 OFFLINE：ALTER DATABASE OrderDB SET OFFLINE;，再执行ALTER DATABASE ... MODIFY FILE，最后SET ONLINE

5.5 现象：备份作业运行成功，但 Backup Exec 控制台显示“成功”，而 SQL Server 日志里却有Error: 18210, Severity: 16, State: 1. Backup medium is full

原因：Backup Exec 的 B2D 目标文件夹设置了最大大小（如 100GB），但未启用“循环覆盖”，导致备份写满后静默失败。
解决：

1. 进入 Backup Exec →工具→向导与工具→配置备份到磁盘文件夹
2. 选择对应 B2D 目标 →属性→常规标签页
3. 勾选“当磁盘空间不足时，覆盖最旧的备份集”
4. 取消勾选“限制此文件夹的最大大小”（或将其设为远大于预期备份量的值）

6. 进阶技巧：用 T-SQL 脚本验证备份集有效性，绕过 Backup Exec GUI 的黑匣子

Backup Exec 2010 的 GUI 是个黑匣子——它告诉你“成功”，但不告诉你备份集内部是否真能被 SQL Server 识别。最可靠的验证方式，是直接用 SQL Server 自身的RESTORE HEADERONLY命令解析备份文件。这能让你在还原前就确认：备份集是否为 SQL Server 原生格式、是否包含完整日志链、是否加密（Backup Exec 2010 不支持 SQL Server 透明数据加密 TDE 的备份还原）。

6.1 提取 Backup Exec 生成的 B2D 文件路径（定位真实备份文件）

Backup Exec 的 B2D 目标是一个文件夹，但实际备份集被分割为多个.bkf文件（如BE000001.bkf,BE000002.bkf）。你需要找到最新全备对应的.bkf：

1. 在 Backup Exec 控制台 →作业历史记录→ 找到目标全备作业 → 右键 →属性
2. 在“详细信息”页，找到“备份到”字段，其值类似\\BESERVER\D$\BE_Backup\SQL_Full\BE000001.bkf
3. 复制该路径（注意：\\BESERVER\D$\...是 UNC 路径，需确保 SQL Server 能访问）

6.2 用RESTORE HEADERONLY解析备份头（核心验证命令）

在 SSMS 中，连接到目标 SQL Server 实例，执行：

-- 替换为真实的 .bkf 文件路径（UNC 或本地路径） RESTORE HEADERONLY FROM DISK = '\\BESERVER\D$\BE_Backup\SQL_Full\BE000001.bkf';

成功返回的结果集第一行，必须包含以下关键字段：

后悔药：若RESTORE HEADERONLY报错Msg 3201, Level 16, State 2（无法打开备份设备），说明路径错误、权限不足或文件损坏。此时 Backup Exec 的“成功”毫无意义，必须重做备份。

6.3 模拟还原测试：不真正写入磁盘，只校验备份集完整性

对关键业务库，建议每周执行一次“模拟还原”（Restore Verify Only）：

-- 此命令不写入任何文件，只验证备份集能否被 SQL Server 解析 RESTORE VERIFYONLY FROM DISK = '\\BESERVER\D$\BE_Backup\SQL_Full\BE000001.bkf' WITH LOADHISTORY;

若返回The backup set on file 1 is valid.，说明备份集结构完好。这是比 Backup Exec 日志更权威的“健康证明”。

6.4 自动化巡检脚本：每天凌晨检查最近 3 天的 SQL Server 备份

把验证逻辑变成 Windows 任务计划，让机器替你盯梢：

@echo off set BKFPATH=\\BESERVER\D$\BE_Backup\SQL_Full\ set LOGFILE=C:\BE_Check\verify_log_%date:~0,4%%date:~5,2%%date:~8,2%.txt echo [%time%] Starting verify... >> %LOGFILE% sqlcmd -S DBSRV01 -E -Q "RESTORE VERIFYONLY FROM DISK='%BKFPATH%BE000001.bkf'" -o %LOGFILE% -b if %errorlevel% equ 0 ( echo [%time%] Verify SUCCESS >> %LOGFILE% ) else ( echo [%time%] Verify FAILED >> %LOGFILE% powershell -Command "Send-MailMessage -To 'dba@company.com' -Subject 'BE Backup Verify Failed' -Body 'Check %LOGFILE%' -SmtpServer smtp.company.com" )

把它存为be_verify.bat，用任务计划器设为每天 2:00 AM 运行。我用这套脚本在客户现场连续 18 个月没漏过一次备份失效，比盯着 Backup Exec 控制台靠谱十倍。

希望帮到你。

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