Gyr*_*138 4 sql-server-2008 sql-server backup recovery
好吧，我觉得这是一个糟糕的主意，但我需要一些帮助来理解为什么这很糟糕：
我仍在努力为我们的数据中心实施灾难恢复/业务连续性解决方案。我们正在运行 MSSQL 2008 Enterprise，我们计划在云中运行一个被动实例。目前我建议使用 Log Shipping，但我被要求探索使用 RSync（或类似的东西）将 MDF/LDF 文件增量推送到云，而不是使用内部工具。
目标是减少我们的占用空间，并且由于许可问题，大部分时间不运行云 SQL 实例（我们的被动/DR 许可证已在我们当前的数据中心中使用，但如果该中心出现故障，则该许可证可用） .
我找到了一个使用 VSS 创建和推送增量的解决方案，即使文件被锁定，但我想知道会出现什么样的问题。我可以得到一些见解吗？我们将每 15 分钟推送一次增量，有问题的数据库大约为 2GB，在 15 分钟的窗口中可能会生成 10 MB 的 T-Log。
我不相信 rsync 为用户或系统数据库复制 ldf 和 mdf 文件，也不相信我在生产环境中一起破解的任何东西（VSS 或其他方式）。SQL Server 对何时（以及是否）将内容写入 ldf 和 mdf 文件非常挑剔。未考虑到这一点而设计的软件 (rsync) 可能无法正确处理，尤其是当它不了解 ldf 文件和 mdf 文件需要被视为相互关联的文件系统时。如果该软件无法正常工作，则在您进行故障转移之前可能不会注意到任何事情，尝试上线并将您的数据库标记为可疑，因为 SQL Server 将其视为数据损坏。更糟糕的是，“正确处理”可能取决于系统上有多少负载，您可能无法在负载较轻的测试环境中发现问题。
我已经看到很多人认为他们正在复制他们的文件但实际上没有的例子。他们在恢复站点上留下了损坏的文件，在主站点上留下了无法访问的备份文件。所以，这意味着他们没有数据库。
简而言之，您正在预约麻烦。
如果您拥有某种块级复制技术，例如 EMC 的 SRDF，或者正在考虑无共享集群，那可能会有所不同。这些技术与 SQL Server 和 Windows 提供的群集服务接口，以确保您的写入安全并且您的文件将/应该保持一致。
如果我唯一的灾难恢复选项是通常关闭的远程站点，我会使用日志传送并确保我拥有所有部分来恢复远程站点上的数据库。如果您不能让内置的日志传送做到这一点，那么编写自己的日志并没有那么难。在过去的 14 年里，我可能已经从头开始编写了三四个（简单的）日志传送系统。
至少，您需要的关键事项是： 需要进行完整备份并将其复制到远程站点。您需要进行 tlog 备份并将其复制到远程站点。您需要一种自动方法来恢复该完整备份和任何相关的 tlog 备份。理想情况下，这应该足够简单以供其他人执行和/或足够简单以供您在凌晨 3 点弄清楚您的主服务器出现故障并且您半睡半醒。
当您有活动时，启动另一台服务器将需要更长的时间，因为您将有很多手动操作要做。这意味着这不如简单地实现常规日志传送。您还需要定期对此进行测试。
（当然，您还需要担心其他事情，例如作业，包，登录和用户同步，在发生故障时更改 Web 服务器上的 DSN 等。如果您有一个大型环境和严重灾难，例如丢失您的主要数据中心，当 IIS 人员、文件服务器人员、网络人员和其他任何人也试图将他们的东西提出来时，您将尝试这样做。）
如果是我，我会为远程站点的热备用服务器而激动。这将使（标准的、开箱即用的）日志传送变得更容易，并使数据库镜像成为可能。听起来你已经尝试过了。