我目前有一个设置，其中有一个本地网站、一个临时网站和一个生产网站。我使用暂存数据库在我的本地开发，然后一旦进行更改，它就会移动到暂存，配置明智，应该与生产相匹配。如果它在舞台上工作，我几乎知道它会在现场工作，然后我将它转移到生产中。
截至目前，暂存数据库已经过时，因为我们的用户在生产中所做的更改。
我希望完成的是有某种方式可以使登台数据库每晚自动更新。这将允许 staging 是最新的，但允许我们对测试新更改可能需要的 staging 进行更改，而不会立即被生产更新覆盖。
Microsoft SQL Server 如果有帮助的话。相信这是2008年。
总而言之，我如何能够每晚自动将生产数据库镜像到临时数据库？
如果您可以确保在 24 小时内将架构更改从暂存转移到生产。然后实际上您的任务很容易完成，只需备份生产数据库并在登台时恢复。
日志传送和数据库镜像只能给你一个只读数据库。复制没有只读限制，但如果在更新暂存数据库上的架构和数据时发生冲突，复制将失败。
您的 prod db 压缩后大约 25G，我认为它太大而无法每天传输。如果它的增量变化不大，比如说一天压缩不到500M，我建议你可以使用周全备份和日差异备份的策略。这样，您只需要在 prod 上设置 2 个备份作业，在 staging 上设置一个还原作业，它始终只是还原本周的完整备份和新的差异备份。
请注意，您需要在恢复之前终止 staging db 上的所有连接，更改数据库以单用户模型来执行此操作。
完整备份和日志备份策略也应该有效，并且需要更少的数据来传输，但是设置恢复作业会有点复杂。
（免责声明 - 我本质上熟悉@SolidSnake4444 的设置和目标）
@jmoreno 正确地观察到了矛盾。
大数据库大小是不利于依赖计划完整还原的解决方案的另一个因素。
我觉得最好的解决方案是混合@JohnyWeil 和@SteveStedman 的建议，如下所示： 1. 创建第二个“真实”暂存本地数据库——这将是生产数据和模式的镜像。2. 开始将您当前的“暂存”称为“测试”或“开发”。3. 设置从生产到新阶段的日志传送，但延迟应用日志。
注意，3. 是必需的，因为隐含的要求是这个“登台”数据库必须是可操作的，以允许“登台”或“部署前测试”本地活动。“操作”要求排除了任何类型的“实时”同步——镜像或复制，因为日常“本地”活动肯定会生成大量数据，与生产中生成的数据相冲突；架构更改也是可能的。（如果我错了，请有人纠正我）。
此外，每周或每两周（基本上是当所需的事务日志备份恢复的数量变得不切实际时），从生产环境中删除完整备份并删除旧的累积事务日志备份以重置周期。
所有这些都可以完全自动化。
你提出了两个相互矛盾的目标。
这些目标相互冲突，因为数据和模式可能不再兼容。简单的例子是添加或删除列，稍微复杂一点的例子是添加到暂存数据库的表约束......如果您正在修复一些不良数据并确保它不会再次发生，您的生产数据库仍然会里面有坏数据。
我建议您每天备份恢复到登台（又名测试）的生产数据，然后运行您将用于修改生产的脚本，当时间到了测试时。除非您有一些非常重要的数据和更改，否则这应该相当快。可能足够快以至于你不想让它自动化（更容易看到它失败时会发生什么）。
如果您愿意，可以使用 sql 代理自动执行这两个步骤。
好问题。我在我的开发环境中做了与此非常相似的事情。
我所做的是拥有多个暂存数据库。一个是活动的，一个可用于从生产系统恢复备份。随着事情的进展，我最终使用登台服务器从一个登台数据库切换到另一个。
为了移动架构，我使用了 RedGate 的 2 个工具。第一个 SQL 源代码控制允许我签入所有数据库架构，以便将其保存在源代码控制中。其次是 SQL 比较，它允许我比较 2 个数据库之间的模式，然后将一个迁移到另一个。
该过程涉及将生产备份带入开发，然后使用 SQL 比较将架构更改从旧的暂存数据库迁移到新的暂存数据库。然后将所有开发和登台服务器切换为指向新的登台数据库。
随着时间的推移，在两台登台服务器之间来回切换，您始终拥有一台处于活动状态的开发服务器，以及一台可以恢复的服务器。
当您想将架构更改移动到生产环境时，只需使用 RedGate 中的 SQL 比较来创建更改脚本。
我已经使用这个过程将近 4 年了（SQL Source Control for 2），它适用于多个开发人员，以及将更改推送到生产环境。
查看 RedGate 的 SQL 比较和 SQL 源代码控制。如果您有任何问题，请告诉我。