SQL Server备份失败主因是服务账户权限不足或数据库被占用；应将备份路径设为默认数据路径的Backup子目录，或手动赋予服务账户写入权限；C#中需用QUOTENAME()防注入、设置CommandTimeout=600；还原前须执行SET SINGLE_USER WITH ROLLBACK IMMEDIATE。
SQL Server 备份失败：BACKUP DATABASE 权限不足或路径不可写
直接执行备份命令报错 Cannot open backup device... operating system error 5 (Access is denied)，不是代码问题，是 SQL Server 进程（通常是 NT SERVICE\MSSQLSERVER 或 NT AUTHORITY\SYSTEM）没权限往你指定的目录写文件。
- 别把备份路径设成
C:\Users\YourName\Desktop\—— SQL Server 服务账户根本进不去用户桌面 - 用
sp_configure 'show advanced options', 1; RECONFIGURE;开启高级选项后，查SELECT SERVERPROPERTY('InstanceDefaultDataPath')拿到默认数据路径，备份到同级Backup\子目录最稳妥 - 如果必须存到自定义路径，得在 Windows 中给 SQL Server 服务账户（不是你的登录账户）手动添加该目录的「写入」和「修改」权限
C# 调用 SqlConnection 执行 BACKUP DATABASE 的最小安全写法
别用拼接字符串构造 SQL，也别让前端传入数据库名直接拼进命令——这是典型 SQL 注入入口。SQL Server 不支持参数化 BACKUP 语句，但可以用白名单校验 + QUOTENAME() 防注入。
- 先查系统视图确认库名存在：
SELECT name FROM sys.databases WHERE name = @dbName - 再用
QUOTENAME(@dbName)包裹库名，例如BACKUP DATABASE " + QUOTENAME(dbName) + " TO DISK = ... - 连接字符串里别开
Pooling=false—— 备份可能耗时几十秒，连接池能避免超时重连混乱 - 务必加
CommandTimeout = 600（单位秒），大库备份很容易超默认 30 秒
string sql = $"BACKUP DATABASE {SqlHelper.QuoteName(dbName)} TO DISK = @backupPath WITH INIT, COMPRESSION";
还原时 RESTORE DATABASE 报错：Exclusive access could not be obtained
这不是代码写错了，是目标数据库正被其他连接占用（比如 SSMS 打开着查询窗口、EF Core 的 DbContext 没释放、甚至你自己的另一段代码还在连着）。SQL Server 还原要求数据库处于单用户模式且无活动会话。
- 还原前强制切换数据库并踢掉所有连接：
ALTER DATABASE [{dbName}] SET SINGLE_USER WITH ROLLBACK IMMEDIATE - 还原完成后立刻切回多用户：
ALTER DATABASE [{dbName}] SET MULTI_USER - 别依赖
WITH REPLACE硬覆盖——它不解决连接占用问题，只跳过“目标库已存在”的检查 - 还原语句里的
MOVE子句必须显式指定.mdf和.ldf文件的新物理路径，否则可能和现有库冲突
用 SMO 库比原生 SQL 更稳？看场景
SMO（Microsoft.SqlServer.Smo）封装了备份/还原逻辑，自动处理设备映射、日志链检查、进度回调，但引入额外依赖且部署时需匹配 SQL Server 版本。
- 只做简单全备/全还，原生 T-SQL 更轻量、可控、无需安装 SMO 运行时
- 要做差异备份、日志备份、校验备份集完整性（
RESTORE VERIFYONLY）、或监听进度条，SMO 的Backup/Restore类更省事 - 注意 NuGet 包
Microsoft.SqlServer.SqlManagementObjects有多个版本，.NET 6+ 项目优先选v160+，旧版在 Win11 / SQL Server 2022 上可能报FileLoadException
真正容易卡住的点，往往不在代码怎么写，而在 SQL Server 实例配置、Windows 文件权限、以及还原时有没有人正连着那个库——这些地方一漏，再漂亮的 C# 封装也救不回来。
