1

I've read dozens of articles about why this is a bad idea. The arguments against using a detached database as a backup are legion. However, I still think that in my case, it makes good sense. Realizing that those are often the words of admins who know too little, I'd like to put my strategy to the good folks here to see if someone can tell me why what I'm doing would be more properly done with the internal backup mechanism.

Let me address some of the common issues.

  1. My database files are almost full, so the fact that backups only copy utilized pages isn't relevant to me;
  2. I'm not using any filestream storage;
  3. my application can handle small bursts of downtime when I detach and make a copy;
  4. The various file permission nightmares that accompany detaching databases have already been solved.

The total size of the DB is about 1TB. My main reason for detaching and attaching instead of using backups is performance. In my testing, it is significantly faster to detach the database, make a copy of the underlying files, and attach the original files again than it is to perform a backup. During recovery, it is also significantly faster to attach files (even if I have to copy them to the proper location first) than it is to restore them.

I can get around the backup performance problem by using something other than a full backup, but that doesn't help when it comes to restoration. In the event of a disaster, I need to be back up and running quickly. My application can handle small amounts of downtime periodically, but any large stretch of downtime is disastrous. Restoring 1TB of database takes longer than the business wishes to tolerate for the application.

The last item I've often read is that detaching a database comes with some risk. Just like we ought to perform test restores of backups, I immediately attach any copied MDF/LDF/NDF files to a disaster recovery SQL Server to make sure the copy is good. I suppose my exposure here is that I could detach the database and break something such that the original DB files can no longer be re-attached. Honestly, I've never seen this, so if this is really a possibility, I feel that it's quite remote. I'm doing this nightly, so I'd lose a day's worth of reporting data in this (unlikely?) scenario.

Am I missing anything else?

4

1 回答 1

3

使用这种方法，您选择优先考虑减少恢复时间而不是恢复点（恢复时数据丢失）。这是每个人都必须在某种程度上做出的合理权衡。

每次分离和重新附加以进行备份时，您的数据库都将处于脱机状态，而 BACKUP 命令根本不需要停机时间。与备份期间的每一天相比，在偶尔恢复期间更关注停机时间似乎是不寻常的，但我想这取决于备份的实际时间和假设的恢复时间。

您还没有提到事务日志备份。对于大多数人来说，日志备份提供了最佳的恢复时间和恢复点。您是否考虑过将相对不频繁的日志备份作为替代策略？

如果恢复时间如此重要，那么您可能需要拥有可以恢复到的热备用硬件。如果您确实有备用服务器，那么您可以使用标准备份和恢复来最大限度地减少停机时间，而不是使用分离方法：只需每天将数据库恢复到备用服务器。您甚至可以记录您的事务日志备份。

与任何备份和恢复策略一样，您应该对其进行测试。进行试运行，看看损失一天工作的实际成本是多少。也许很容易低估这个成本。

当您分离并重新连接时，请确保您包含日志文件。除了您附加的副本之外，还保留一份脱机副本。如果附件碰巧失败（比如因为其中一个文件已移动），那么在某些情况下，这些文件可能会被“触及”，因此它们不能轻易地再次附加。我的建议是永远不要尝试从您唯一的数据库文件副本中附加。

您仍然需要使用 BACKUP 来备份 Master 数据库（如果需要，还需要使用 model/msdb）。

于 2018-09-05T06:02:22.857 回答