我已接近过去几个月我一直致力于客户系统的“让我们活着”的阶段，基本上是一些自治服务，包括面向公众的网站，内联网网站，每小时出口商来自传统的OLTP数据库，基于修改过的标志/触发器等，以及构成系统的其他几个服务，每个服务都有自己的专用数据库等，通过消息（NServiceBus）相互通信。
当我开始时，我试图保持对所有内容的本地复制，但其证明越来越困难，并且反思可能是过去几周的主要摩擦点，我喜欢随着旧数据库的增长而定期更新每天造成数百个事件。具有高延迟＆amp;平庸的带宽（在我自己和客户的网站之间，我在东南亚，带宽通常是垃圾）也是RDP，SQL工具，远程连接字符串等的问题。跟踪整合错误并了解他们在反馈过程中出现的情况/ integration / QA也很难，因为我的数据不能反映客户端数据库的当前状态（客户端的工作人员一直在工作并将数据演化到最终），这意味着再次中断，咖啡和冗长的同步。理想的做法是在本地进行，然后在最后进行部署，但我必须逐步提供部件（以便进行检查），有些部件甚至在使用中（虽然不是关键）因此使用pats中的错误修复需要转向快速，并且它是一个小公司，增量反馈，它有助于清除一些更模糊的要求（诅咒我）。
我认为在环境之间每天进行两次同步会很好（他们的数据库是我的同步），除了旧的SQL服务器数据库之外，我对某些设备有一定的控制权。
SO用户的最佳选择是什么？
我正考虑在我的开发箱上设置Windows 2003轻型VM。并且在此安装中，客户端站点的设置相同（但显然不会分布在多个服务器上）。然后为了同步数据库我正在考虑SQL Server复制？或批处理脚本？或者是否有更好的工具 - 快速和良好的压缩？我不希望我的更改重新投入生产（我有一个单独的CI和部署程序），我只是想（我想我想......告诉我，如果更好的想法）我的数据库每晚或每两次更新一次一天（也许是我在午餐带宽允许的时候）。
每个人如何处理这个问题？
答案 0 :(得分：1)
我建议采用两种方法：
快照复制可能难以实现，但即使在离线情况下也是如此，例如在物理上将快照传送到其他位置。
事务日志方法可用作标准备份过程的一部分。即：每周两次完整备份，更频繁地进行事务日志备份。
请记住，最佳做法是在测试环境中使用数据之前清理数据。至少应该改变所有个人数据，尤其是电子邮件地址，密码和任何其他可能导致某些自动化流程与数据库中的用户联系的方法。