我已经阅读了数十篇有关为什么这是一个坏主意的文章。反对使用分离式数据库作为备份的争论不休。但是，我仍然认为这对我来说很有意义。意识到那些通常是对管理员了解甚少的人的话，我想将我的策略介绍给这里的好人，看看是否有人可以告诉我为什么我使用内部备份机制可以更正确地完成我的工作。
让我解决一些常见问题。
数据库的总大小约为1TB。我分离和附加而不是使用备份的主要原因是性能。在我的测试中，与执行备份相比，分离数据库，创建基础文件的副本并再次附加原始文件要快得多。在恢复过程中，附加文件（即使我必须先将它们复制到正确的位置）也比恢复它们快得多。
我可以通过使用完全备份以外的方法来解决备份性能问题，但这对恢复没有帮助。万一发生灾难，我需要快速备份并运行。我的应用程序可以定期处理少量停机，但是任何长时间的停机都是灾难性的。恢复1TB数据库所花费的时间比企业希望为该应用程序容忍的时间长。
我经常阅读的最后一项内容是，分离数据库存在一定的风险。就像我们应该执行备份的测试还原一样，我会立即将所有复制的MDF / LDF / NDF文件附加到灾难恢复SQL Server，以确保副本是正确的。我想在这里暴露的是我可以分离数据库并破坏某些内容，从而使原始DB文件无法再附加。老实说，我从未见过这种情况，因此，如果确实有这种可能，我觉得它很遥远。我每天晚上都要这样做，所以在这种（不太可能？）情况下，我将损失一天的报告数据。
我还有其他东西吗？
使用这种方法，您可以选择优先于减少的恢复时间而不是恢复点（恢复时数据丢失）。这是每个人都必须在某种程度上做出的合理取舍。
每次分离并重新连接以进行备份时，数据库将处于脱机状态，而BACKUP命令完全不需要停机。与在备份期间每天都比在每天备份中更关注停机时间，这似乎很不寻常，但是我想这取决于备份的实际时间和假定的还原时间。
您还没有提到事务日志备份。对于大多数人而言，日志备份可提供最佳的恢复时间和恢复点。您是否考虑过将相对不频繁的日志备份作为替代策略？
如果恢复时间是当务之急，那么您可能需要具有可以恢复到的热备份硬件。如果您有备用服务器，则可以使用标准备份和还原来最大程度地减少停机时间，这比使用分离方法要多得多：只需每天将数据库还原到备用服务器即可。您甚至可以记录运输事务日志备份的日志。
与任何备份和还原策略一样，您应该对其进行测试。进行试运行，看看损失一天的工作实际要花多少钱。可能很容易低估了这笔费用。
分离并重新连接时，请确保包括日志文件。除了附加的副本外，还保留一个脱机副本。如果附件碰巧失败（例如，由于其中一个文件已移动），则在某些情况下，文件可能会被“触摸”，因此无法轻松地再次附加它们。我的建议是永远不要尝试从数据库文件的唯一副本进行附加。
您仍然需要使用BACKUP备份Master数据库（如果需要，还可以备份model / msdb）。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句