我有一个数据库，其中有近1TB的FILESTREAM数据不需要备份（如果删除了该数据，则会在几个小时内自动重新创建，因此并不重要）。大多数数据每两天更改一次，因此差异备份并不能真正帮助减小容量。
我有工作，我需要通过恢复模式设置的方式备份Full，创建一个单独FILEGROUP的FILESTREAM，然后取的只有“主”的备份FILEGROUP。造成的问题是日志文件（也已备份）现在不必要地很大，因为它包含FILESTREAM数据。
SIMPLE恢复模式使我无法执行特定FILEGROUPs的备份，因此我也不认为这是一个选择。
我的想法只是将FILESTREAM数据移到一个单独的数据库中，但是现在我失去了参照完整性，并且肯定还会继承许多其他问题。
有什么方法可以在Simple恢复模式下创建部分备份（无需将FILESTREAM表设置为只读）？如果没有，我的问题是否还有其他合理的解决方案？
Answers:
造成的问题是日志文件（也已备份）现在不必要地大了，因为它包含FILESTREAM数据。
我不确定您是说日志文件本身太大还是日志文件备份太大。
如果是前者，那么您多久备份一次日志？根据应用程序设计，您可以通过更频繁地备份来减少大小（并且每5分钟不太频繁）。但是，如果您已经在这样做，并且它还在膨胀，那么您可能不走运。为什么大型日志文件又是一个问题？
如果是后者-听起来您很高兴继续使用简单的恢复模型，并且如果备份较小，则不会及时恢复；在这种情况下，请保持完整模式，并丢弃日志备份。
将数据库设置为恢复模式SIMPLE的一种解决方案是将FILESTREAM数据放在一个只读文件组中（这不是您的理想选择），然后仅使用DIFFERENTIAL备份读/写文件组，如下所示：
BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;它将获取任何读/写文件组中已更改的任何数据。这是最简单的即用型方法，您可以在不获取FILESTREAM数据的情况下使部分备份可管理。然而，将需要用于前述数据的加载过程将需要修改文件组以进行读取/写入，加载任何其他数据，然后设置为仅再次读取。当然不理想。
我觉得这很脏，但是如果您选择将FILESTREAM数据隔离到其自己的数据库中，则可以通过触发器来维护单独数据库中表之间的RI ：
触发器->注释->限制：
仅在当前数据库中创建触发器；但是，触发器可以引用当前数据库之外的对象。
预期会出现性能问题，并且在沮丧地拉出头皮毛簇之后，头皮的一部分会变得无毛，但是从理论上讲，您可以这样做。我不建议在任何级别使用此方法，相反，我强烈建议您增加日志备份的频率和/或切换到大容量日志恢复模型，并查看可以节省多少空间，但是这是一种可能的解决方案。确实，您需要权衡分离这些数据和处理Frankensteinian数据库设计的好处，但这是一个选择。
我现在要去洗个澡