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