我们有一个在 SQL Server 2008 R2 上运行的生产数据库，其中存储了文件。我们担心数据库的大小，所以我们选择启用 FILESTREAM，这样文件就会存储在磁盘上，我们希望可以减少备份的大小。我发现我们可以从备份中排除 FILESTREAM 文件组，但是我们在恢复时查询这些表时遇到问题（因为这些字段缺少数据，这是预期的）。我们的下一个想法是可能使用自动 FTP 或 Dropbox 或类似的东西从磁盘同步文件。不过，我还没有完全探索过这一点。
我们在这里试图解决的真正问题是让我们的开发人员与生产数据库保持同步。随着我们的数据库规模不断扩大，进行完整备份和下载数据库变得越来越繁琐，最终会变得令人望而却步。我想知道其他人正在做什么来使远程开发人员保持最新状态。
我快速浏览了 SQL Server 的日志传送，但似乎需要大量自定义自动化（安排 FTP 和恢复脚本）才能使其与不同地理位置的一些开发人员可靠地工作，而我不是确定如何使用辅助数据库进行开发，因为它可能是只读的。我愿意接受任何建议，如果我能提供有关我们情况的更多信息以帮助提出建议，请告诉我。
更新：开发人员只需要一个合理的当前生产数据副本。这有助于重现问题，以便解决问题。我们可以接受数据有点陈旧，但将传输时间保持在最低限度会建议频繁备份。
感谢到目前为止的建议，只是为了增加一点，我们的数据库目前是 12GB 左右，我们希望在不久的将来随着更多客户的签约而增加一倍。我已经运行了几个启用压缩的测试备份，这为我们节省了大约 1-2GB 的空间，但我认为由于大部分是存储文件（现在在 FILESTREAM 中），我们不会大幅减少我们会希望（尽管我们可能仍会压缩以节省我们可以节省的空间）。我认为我们希望能够每周恢复一次或两次本地副本，以便密切关注事物。我不确定我们的托管服务器的带宽上限是多少，但似乎有几个人每月多次下载 20GB 文件不会很好地利用我们拥有的任何带宽。我不
小智 2
我认为提供完整的数据库副本不是一个好主意，因为随着数据库的增长，这会变得痛苦。我们有相同的设置，但没有文件流选项。我们使用 powershell 生成数据库模式脚本，并每天晚上将其邮寄给开发人员。开发人员使用该脚本在自己的计算机上创建数据库外壳（我们有单独的开发数据库，其中包含他们可以用来查询和加载应用程序特定数据的数据）。此数据库外壳用于使用 SSDT 进行开发和单元测试数据库代码。为了调试实时问题，我们在备用服务器上记录了实时数据库的副本，该副本大部分仅落后 10-13 分钟。我们对这个设置几乎没有任何问题，但一切都取决于具体情况。祝你好运