我们的主数据库的大小已经减少了大约 8 GB。这反映在备份以及我们查看可用空间和可用空间时。
一切似乎都在工作，我们找不到任何数据丢失的迹象，但我们以前从未见过这种情况。我们有点担心可能会发生一些不愉快的事情。
谁能告诉我们 8 GB 的数据是如何消失的？如果这是一件正常的事情，我们想了解它是如何发生的，因为能够将数据库备份的大小减半实际上有点有用。
我们在 Windows Server 2019 上运行 SQL Server Enterprise 版本 14.0.3391.2
我们的主数据库每天午夜后备份。备份目标是本地磁盘。每次备份运行时，都会为每个数据库创建一个新文件。我们的恢复模式很简单。备份不会被压缩。至少在过去几年中，每个备份大约为 15 GB。自 6 月 11 日以来，文件大小已缩减至略高于 7 GB。
做一些研究，DBA StackExchange 上的一个线程与不小心在单个文件中创建多个备份的人有关。我RESTORE HEADERONLY FROM DISK对 6 月 10 日（15 GB）和 6 月 11 日（7 GB）的备份进行了测试。两者似乎都包含一个备份。我也没有看到任何其他值得注意的差异。
恢复数据库后，我观察到当前和恢复的数据库的总大小约为 30 GB。当前数据库上的可用空间约为 19 GB，而在恢复的数据库上约为 11 GB。8 GB 的差异，就像备份一样。我们的备份未压缩。
我们没有注意到我们的应用程序中缺少任何我们非常依赖的数据。我已经使用 SSDT 来比较当前数据库和恢复数据库中的架构和数据。
使用此数据库的应用程序正在不断开发中，因此在当前数据库中添加了一些列和表以支持新功能，但没有删除。
同样，在当前数据库中也有一些行被编辑或删除，但关联表在恢复的数据库中所占的比例远低于 100 MB，因此即使它们被完全删除，也不会导致大约 8 GB 的数据消失。
我们有一个人来开发应用程序。数据库管理由那个人和我共享。我们都不相信我们做了任何会导致这种变化的事情。
我们使用数据库的方式没有任何重大变化，如果有的话，备份应该变得更大。
我们是一家小公司，不太可能有人进行过数据清理。这也应该在 SSDT 的数据比较中显示出来。
我在日志文件中没有发现任何表明未经授权访问或备份失败的信息。
我目前正在从 6 月 11 日 (7 GB) 恢复备份，看看这是否能告诉我任何信息，尽管我并不期望从中获得太多见解。
我们不会自动删除备份，而是手动删除，这时我们发现了大小差异。
我不相信任何索引已被删除-有人对最佳检查方法有建议吗？碎片整理似乎是一个完全可能的原因 …