我读了很多关于为什么这是个坏主意的文章。反对使用分离数据库作为备份的论点很多。但是，我仍然认为在我的情况下，它很有道理。意识到这些通常是那些知之甚少的管理员的话，我想把我的策略交给好人，看看有人能告诉我为什么我正在做的事情会更好地完成内部备份机制。
让我谈谈一些常见问题。
DB的总大小约为1TB。分离和附加而不是使用备份的主要原因是性能。在我的测试中，分离数据库，制作底层文件的副本以及再次附加原始文件要比执行备份要快得多。在恢复期间，附加文件（即使我必须先将它们复制到正确的位置）也要比恢复文件快得多。
我可以通过使用除完整备份之外的其他东西来解决备份性能问题，但这在恢复方面没有帮助。如果发生灾难，我需要快速备份并运行。我的应用程序可以定期处理少量的停机时间，但任何大的停机时间都是灾难性的。恢复1TB的数据库需要的时间比企业希望的应用程序要长。
我经常阅读的最后一项是分离数据库会带来一些风险。就像我们应该执行备份的测试还原一样，我立即将任何复制的MDF / LDF / NDF文件附加到灾难恢复SQL Server，以确保副本良好。我想我在这里曝光的是，我可以分离数据库并破坏一些东西，以便原始的DB文件不能再重新附加。老实说，我从来没有见过这个，所以如果真的有可能，我觉得它很遥远。我每晚都这样做，所以我在这个（不太可能？）的情况下会丢失一天的报告数据。
我错过了什么吗？
使用此方法，您可以选择优先缩短恢复点的恢复时间（恢复时丢失的数据）。这是一个合理的权衡，每个人都必须在某种程度上做出。
每次分离并重新连接以进行备份时，您的数据库将处于脱机状态，而BACKUP命令根本不需要停机。在备份期间更多地关注偶尔恢复期间的停机时间似乎不寻常，但我想这取决于备份的实际时间和恢复的假设时间。
您尚未提及事务日志备份。对于大多数人来说，日志备份可提供最佳的恢复时间和恢复点。您是否考虑过相对不频繁的日志备份作为替代策略？
如果恢复时间是如此优先，那么您可能需要具有可以恢复的热备用硬件。如果您有备用服务器，那么您可以使用标准备份和还原来最大限度地减少停机时间，使用分离方法：只需每天将数据库还原到备用服务器。您甚至可以记录事务日志备份。
与任何备份和还原策略一样，您应该测试它。试运行，看看一天的工作实际损失了多少。也许很容易低估这个成本。
分离并重新连接时，请确保包含日志文件。除了附加的副本之外，还要保留脱机副本。如果附件发生故障（比如因为其中一个文件已经移动），那么在某些情况下，文件可能会被“触摸”，因此无法轻易再次附加。我的建议是永远不要尝试附加您唯一的数据库文件副本。
您仍然需要使用BACKUP来备份Master数据库（如果需要，还可以使用model / msdb）。