我正在考虑使用 S3 作为我的 Subversion 数据库的异地备份存储库。当我转储我的 SVN 数据库时，它大约有 10 GB。我想避免重复上传这些数据的费用。
这个大文件的结构是，对 Subversion 的新更改会修改文件的尾部，而其他所有内容保持不变。由于 Amazon S3 不允许您“修补”有更改的文件，因此每次在向 Subversion 进行简单提交后实例化备份时，我都必须上传 10 GB 的数据。
以下是我所看到的选项：
选项1
我正在研究 duplicity，它可以--volsize将数据拆分为兆字节数。是否可以使用它来拆分 Subversion 转储，以便进一步的增量备份以兆字节为单位进行测量？
选项 2 我可以只备份热的 Subversion 存储库吗？如果正在编写提交，这似乎是个坏主意。但是，我可以选择在午夜至凌晨 4 点之间将存储库脱机。我的 Berkeley DB 中的每个修订都使用一个文件作为其记录。
答案1
为什么不转换你的仓库来使用FSFS 格式而不是 BDB？
这样，每个修订版本将存储为单独的文件，因此增量备份只会发送自上次备份以来提交的修订版本。
答案2
您可以建立一个小型 Amazon EC2 实例，并通过 rsync 或您喜欢的任何工具备份到 Elastic Block Store (EBS) 卷。备份完成后，拍摄快照，该快照将保存到 S3。
从某些方面来看，这是一个更复杂的解决方案，但弥补了 S3 的一些限制/复杂性。
答案3
我知道这不是真正的答案，但为什么不使用 SVN 提供程序而不用担心这些事情呢？
另一个解决方案是使用 git，其中每个用户都有所有增量的完整副本，这样您就可以从服务器故障中恢复（因为所有增量都是相同的）。
答案4
由于我最近不得不这样做，我想补充一下，备份管理器可以解决这个问题。它可以压缩转储并将其轮换到 s3 上。我使用了这以供参考。