SQL Server备份还原必须由SQL Server引擎执行，C#仅传递RESTORE DATABASE命令；需确保服务账户对备份路径有读取权限、显式重定位文件、数据库处于单用户模式，并正确处理路径、权限及状态要求。
SQL Server 备份文件还原必须用 RESTORE DATABASE，C# 本身不提供“数据库还原 API”
不少开发者容易陷入一个误区，以为C#会像提供SqlBackup那样，也封装一个现成的SqlRestore类。其实不然。虽然Microsoft.SqlServer.Management.Smo（SMO）库确实包含了还原相关的封装，但它的底层逻辑，本质上还是在拼接并执行T-SQL的RESTORE DATABASE命令。所以，直接调用SQL Server引擎自身的能力，才是唯一可靠的正途。
一个典型的错误场景是：构造好SqlRestore对象后，调用SqlRestore.SqlRestore(server)却抛出System.Data.SqlClient.SqlException: Cannot open backup device ... Operating system error 5(Access is denied.)。这问题往往不是C#代码写错了，而是SQL Server服务账户压根没有权限访问你指定的备份文件路径。
- 还原操作必须在SQL Server实例的上下文中执行，C#程序仅仅是客户端的指令发起者。
- 备份文件的路径，必须对SQL Server服务账户（而不是你当前登录的Windows用户）具有读取权限。
- 如果使用UNC网络路径（例如
\\fileserver\backups\mydb.bak），那么SQL Server服务必须以域账户身份运行，并且该账户同时拥有共享文件夹和NTFS文件系统的访问权限。 - 即便是本地路径（比如
D:\backup\mydb.bak），也要确保SQL Server服务账户对该磁盘分区有读取权限（默认的Local System账户通常无法访问大部分用户目录）。
SMO 还原时必须显式设置 RelocateFiles，否则大概率报错 File 'xxx' cannot be restored to 'xxx.mdf'
即使目标数据库不存在，SMO默认也会尝试将数据文件和日志文件还原到备份时记录的原始物理路径。如果这个原始路径在目标服务器上不存在（例如备份来自另一台机器的C:\OldServer\Data），或者权限不足，操作就会直接失败。这可不是警告，而是硬性的执行错误。
正确的做法是，先通过SqlRestore.ReadFileList(server)获取备份文件内的逻辑文件名列表，然后为每个文件创建一个RelocateFile实例，指定新的物理路径：
var dbFiles = restore.ReadFileList(server);
foreach (DataRow row in dbFiles.Rows)
{
string logicalName = row["LogicalName"].ToString();
string physicalName = row["PhysicalName"].ToString();
string ext = Path.GetExtension(physicalName).ToLower();
string newPath = ext == ".mdf"
? @"D:\SQLData\MyDb.mdf"
: @"D:\SQLLog\MyDb.ldf";
restore.RelocateFiles.Add(new RelocateFile(logicalName, newPath));
}
RelocateFile中指定的logicalName必须与ReadFileList()返回的结果完全一致（注意大小写敏感）。- 目标文件夹（例如
D:\SQLData）必须预先存在，SQL Server不会自动创建目录。 - 即使你还原时使用了新的数据库名（通过设置
restore.Database = "NewDbName"），仍然需要重定位文件，因为逻辑文件名来源于原始备份，不会自动随之改变。
还原前必须确保数据库处于单用户模式或已离线，否则报错 Exclusive access could not be obtained because the database is in use
SQL Server不允许在数据库被其他活动连接占用时执行还原操作。在C#代码里，不能指望“等待几秒再重试”这种策略来解决问题——必须主动清理现有连接。
- 推荐的标准流程是：先执行
ALTER DATABASE [MyDb] SET SINGLE_USER WITH ROLLBACK IMMEDIATE强制切换到单用户模式并回滚现有事务，然后执行还原，最后再执行SET MULTI_USER恢复多用户模式。 - 如果目标数据库尚不存在（例如首次还原），这一步可以跳过。但如果库已存在且正在被使用，缺少这一步几乎必然导致失败。
- SMO中
SqlRestore.NoRecovery = false（默认值）表示还原完成后数据库立即处于可用状态；若设为true，则数据库会保持在RESTORING状态，适用于后续还要还原事务日志链的场景，但此时数据库不可连接。 - 注意事务一致性：
SET SINGLE_USER和RESTORE命令最好放在同一个数据库连接中执行，以避免命令执行间隙被其他连接意外抢占。
用 SqlConnection + SqlCommand 执行 RESTORE 更轻量，但需手动处理路径转义和权限校验
不依赖SMO库同样可以实现还原——核心是拼接出合法的T-SQL RESTORE DATABASE语句并通过SqlCommand执行。这种方式部署更简单（无需引用SMO程序集），但劣势是错误反馈更原始，所有文件路径和参数都需要手动处理。
一个典型的T-SQL还原语句结构如下：
RESTORE DATABASE [MyDb] FROM DISK = N'D:\backup\mydb.bak' WITH FILE = 1, MOVE N'MyDb_Data' TO N'D:\SQLData\MyDb.mdf', MOVE N'MyDb_Log' TO N'D:\SQLLog\MyDb.ldf', REPLACE, RECOVERY;
N''前缀必须加上，否则包含中文或特殊字符的路径可能导致错误。REPLACE选项用于强制覆盖已存在的同名数据库（否则会报错“database already exists”）。FILE = 1指定了备份集序号，因为一个.bak文件可能包含多个备份（例如完整备份加日志备份），可以通过RESTORE HEADERONLY命令查看具体信息。- 在执行正式还原前，建议先用
RESTORE VERIFYONLY命令校验备份文件的完整性，避免还原到一半才发现备份已损坏。
说到底，底层原理可以归结为一句话：所有的还原动作，最终都是由SQL Server引擎自己完成的，C#只是负责传递指令和参数。真正的难点从来不是写哪一行C#代码，而是彻底搞清楚SQL Server对于文件路径、账户权限和数据库状态的硬性要求——这些地方但凡错一点，整个还原流程就会卡住。
