如何从SQL Server 2008中的备份中排除索引

每晚的完整（和定期差异）备份正变得非常大，这主要是由于表上的索引数量所致。大约一半的备份大小由索引组成。

我们正在使用简单恢复模型进行备份。

有没有办法通过使用FileGroups或其他文件分区方法从备份中排除索引？

如果也可以将其扩展到全文目录，那就太好了。

如果切换到完全恢复模式，则可以使用文件组来执行此操作，但这确实非常笨拙。您将数据保留在主文件组中，并将索引放在一个单独的（非默认值，这是关键）文件组中。

然后，您将备份错开，以便每晚进行一次主数据库的文件组备份，每隔X分钟执行一次事务日志备份。

灾难发生时，您可以自行还原主文件组。数据突然联机，但索引不联机。但是，要恢复正常状态，您需要将该数据导出到新的干净数据库中并从那里添加索引。您不能在不恢复所有文件组的情况下使数据库完全联机，也不能说“我不再需要其他文件组了”。

有关其工作原理的更多信息，请查看我有关文件组还原的视频教程。

老实说，即使您克服了其他人在这里提出的其他问题，您也确实不想这样做。

当您在紧急情况下还原备份时，您不想等待索引重建，而在这样做之前，您将遭受可恶的性能。

我想不出要还原没有索引的备份的情况，因此，在所有情况下，您实际上都想同时备份它们。

您可能需要寻找该问题的其他解决方案...

-亚当

听起来好像不支持。从此错误报告信息：

对此有很多兴趣，所以我将对幕后发生的事情以及实现此功能的含义进行更详细的介绍。某些类型的索引页被分离到单独的分配单元中，而另一些类型则与数据页混合在一起。当前我们仅查看分配位图以查看是否分配了扩展区，现在我们必须进入并解释存储在每个分配单元中的内容。此外，我们现在将不能仅对复制数据的数据文件进行线性扫描，而要在文件中四处跳过。所有这些对数据结构的解释都会极大地减慢备份速度。还原变得更加有趣，因为必须修复许多结构来解决备份中的漏洞。否则，您将拥有指向未备份页面的分配映射，因此其中包含垃圾等。因此，实施此操作意味着我们将节省更少的数据，花费更长的时间，并且要花很多时间。恢复更长的时间。要考虑的另一个方面是，要使其完全正常，将需要大量的工程工作。尽管这不是表面上的问题，但请考虑这意味着您可能想看到的其他功能将无法构建。

可能是个疯狂的主意，但这是可行的。

1. 删除占用大量空间的非聚集索引
2. 做一个备份
3. 重新创建您删除的索引

当然，只有在数据库允许一天中有一些停机时间的情况下，您才能真正做到这一点。

另外，不要删除群集索引，因为SQL Server将浪费大量时间将它们转换为堆。

购买额外的磁盘空间似乎更容易解决吗？

您是否考虑过进行压缩备份？这是2008年的新功能，可能是您的选择。