我们的夜间完整（和定期差异）备份变得非常大，这主要是由于我们表上的索引数量；大约一半的备份大小由索引组成。
我们正在使用简单的我们的备份的恢复模型。
是否有任何方法，通过使用FileGroups或其他文件分区方法来排除来自备份的索引？
如果这也可以扩展到全文目录，那就太好了。
答案1
如果切换到完整恢复模式，您可以使用文件组执行此操作，但这确实非常笨拙。您将数据保留在主文件组中，并将索引放在单独的（非默认，这是关键）文件组中。
然后，您错开备份，以便每晚对主文件进行文件组备份，并每隔 X 分钟对事务日志进行备份。
当灾难发生时，您可以自行恢复主文件组。数据突然在线，但索引却不在线。但是，要恢复正常，您需要将数据导出到新的干净数据库中，并从那里添加索引。如果不恢复所有文件组，您就无法使数据库完全在线，并且您不能说“我再也不需要那个其他文件组了。”
有关其工作原理的更多信息，请查看我的有关文件组恢复的视频教程。
答案2
老实说，你真的不想这样做，即使你克服了其他人在此提出的其他问题。
当您在紧急情况下恢复备份时，您不想等待索引重建，否则，您将遭受糟糕的性能损失。
我想不出您会想要恢复没有索引的备份的情况，因此在所有情况下您都会真正希望同时备份它们。
您可能需要寻找解决此问题的其他解决方案...
-亚当
答案3
听起来好像不支持。从这个错误报告信息：
人们对这个功能很感兴趣，所以我将更详细地介绍幕后发生的事情以及实现此功能意味着什么。某些类型的索引页被隔离到单独的分配单元中，而其他类型的索引页则与数据页混合在一起。我们目前只查看分配位图以查看是否分配了某个范围，现在我们必须进入并解释每个分配单元中存储的内容。此外，我们现在不能只对复制数据的数据文件进行线性扫描，我们将在文件中跳过。所有这些对数据结构的解释都会大大减慢备份速度。恢复变得更加有趣，因为有很多结构必须修复以解决备份中的漏洞。否则，您将拥有指向未备份页面的分配图，因此其中会有垃圾，等等。因此，实现此功能意味着我们将保存更少的数据，花费更长的时间，并且需要更长的时间来恢复它。需要考虑的另一个方面是，这需要大量的工程努力才能全部完成。虽然表面上这不是你的问题，但请考虑一下，这意味着你可能希望看到的其他功能将无法构建。
答案4
这可能是一个疯狂的想法，但我还是这么做了。
- 删除占用大量空间的非聚集索引
- 做备份
- 重新创建删除的索引
当然，只有当您的数据库允许一天中有一些停机时间时，您才能真正做到这一点。
另外，不要删除聚集索引，因为 SQL Server 会浪费大量时间将它们转换为堆。
购买额外的磁盘空间是否看起来是一个更简单的解决方案？
你考虑过做压缩备份?这是2008年的新功能，它可能是您的一个选择。