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