Windows Server 2012 R2上MSSQL 2012备份突然缩小的技术咨询

我来帮你拆解这个场景里的核心问题，结合你描述的环境和操作，咱们一步步理清楚：

一、备份大小从33MB降到11MB的原因 #

首先要明确：SQL Server的完整备份只备份数据库中实际使用的数据页，而非整个数据库文件的体积。结合你的低活跃度数据库场景，大概率是这两种情况导致的：

• 幽灵记录页被清理：哪怕只有每日十几条插入，数据库运行过程中可能产生过隐性的“幽灵记录”（比如系统自动清理的过期事务痕迹、或者早期测试时的删除操作残留），当SQL Server完成事务一致性校验后，这些空白的旧数据页会被标记为可重用，后续完整备份就会跳过它们，直接缩小备份体积。
• 预分配空白页被标记为未使用：数据库创建时默认会预分配一定量的空白数据页，虽然你禁用了自动收缩，但系统后台的页整理操作可能把部分未被使用的预分配页重新标记为“未分配”，备份时自然不会包含这些空白内容。

你可以用这两个SQL命令验证：

-- 查看数据库文件的已使用空间与总空间对比
EXEC sp_spaceused;

-- 查看备份文件包含的实际数据内容
RESTORE FILELISTONLY FROM DISK = '你的备份文件完整路径.bak';

二、恢复昨日备份的具体影响 #

如果你恢复昨日的完整备份，会出现这些明确的结果：

• 数据库状态回滚至昨日备份时刻：你会得到截至昨天备份完成时的所有数据，包括当天插入的十余条记录。
• 今日的数据变更会永久丢失：因为你用的是完整恢复模式，但只配置了每日完整备份、没有做日志备份——完整恢复模式下要恢复到最新状态，必须依赖“完整备份+后续日志备份”的组合，所以今天插入的那十几条数据无法找回，除非你保留了今日的备份文件。
• 恢复后的数据库直接可用：SQL Server在恢复过程中会自动回滚备份时未完成的事务，确保数据库处于一致性状态，不需要额外的手动修复操作。

另外补充：SQL Server 2012 SP4 Express的备份/恢复逻辑和标准版完全一致，只是有10GB的数据库大小限制，这个场景下的所有表现都是正常的，不用过度担心备份文件的体积波动。

内容的提问来源于stack exchange，提问作者0xFF