我们每晚的完整（和周期性差异）备份正在变得相当大，主要是由于我们桌上的索引数量太多; 大约一半的备份大小是由索引组成的。
我们正在使用简单恢复模式进行备份。
有没有办法通过使用FileGroups或其他文件分区方法从备份中排除索引？
如果这可以扩展到全文目录，这将是很好的。
如果你切换到完全恢复模式，你可以用文件组来做到这一点，但是确实很笨拙。 您将数据保留在主文件组中，并将索引放在单独的（非默认值，即密钥）文件组中。
然后交错备份，以便每晚进行主服务器的文件组备份，每X分钟备份一次事务日志备份。
当发生灾难时，您自己恢复主文件组。 数据突然在线，但索引不是。 但是，要恢复正常状态，您需要将这些数据导出到一个新的干净的数据库中，并从那里添加索引。 如果不恢复所有的文件组，就无法使数据库完全联机，而且不能说“我不再需要其他文件组了”。
有关如何工作的更多信息，请查看关于文件组还原的video教程。
老实说，即使你克服别人在这里提出的其他问题，你也不想这样做。
当您在紧急情况下恢复备份时，您不希望等待索引重build，并且在这之前您将遭受可怕的性能损失。
我想不出有什么情况可以在没有索引的情况下恢复备份，所以在任何情况下，你都要真正的备份它们。
您可能需要寻找其他解决scheme来解决这个问题
-亚当
这听起来好像这不被支持。 从这个错误报告信息 ：
对这个问题有很多兴趣，所以我会详细介绍幕后发生的事情，以及实现这个function的意义。 某些types的索引页面被分隔成不同的分配单元，而其他types则与数据页面混合在一起。 如果我们现在只查看分配位图来查看是否分配了范围，那么现在我们将不得不进入并解释每个分配单元中存储的内容。 此外，我们现在不能仅仅对数据文件进行线性扫描来复制数据，我们会在文件中跳过。 所有这些数据结构的解释都会大大减慢备份的速度。 还原变得更加有趣，因为有很多结构必须修复，以弥补备份漏洞。 否则，你会有分配地图指向没有备份的页面，所以垃圾在其中，等等等等。所以，执行这将意味着我们会节省更less的数据，花更长的时间做，并采取多更长的时间恢复它。 另一个方面要考虑的是，这需要大量的工程努力才能完成。 虽然这不是表面上的问题，但请考虑这意味着您可能希望看到的其他function无法build立。
可能是一个疯狂的想法，但在这里。
当然，如果你的数据库允许在一天中停顿一段时间，你只能真正做到这一点。
另外，不要放弃你的聚簇索引，因为SQL Server会浪费很多时间把它们转换成堆。
购买额外的磁盘空间似乎是一个更简单的解决scheme吗？
你有没有考虑做压缩备份 ？ 这是2008年的一个新function，它可能是您的一个select。