我们在多台服务器上安装了一个Web应用程序，我们希望通过将关键数据备份到S3来增加一个额外的冗余层。 关键数据是MySQL数据库和一个包含dynamic创build的站点资源的文件夹 – 主要是图像。 某种基于rsync的解决scheme最初似乎是最好的计划。 几年前，我们使用S3cmd （特别是s3cmd同步）进行了一些成功，但是我们没有发现它特别可靠，尽pipe这可能从那以后就改变了。 它发生在我身上，尽pipe一个rsync解决scheme可能不适用于使用mysqldump创build的单个db.sql文件，我认为这意味着整个数据库每次都被传输，多个数据库超过1GB，这将加起来很多stream量（和$ s）很快。 有了图像文件，我可以简单地传输在最后一天内修改的文件，这将更加简单。 我应该看什么方法？
它看起来是opendedup的完美工作。 试一试。 让我们知道，如果它解决了你的问题。
正如你猜测s3cmd几年前更可靠，很多人使用它，包括我没有任何问题。 另外亚马逊S3不收取上传数据的费用，所以金钱因素不是问题，但明确地说，您希望避免不必要的传输，而大部分时间都是在数据库备份的情况下进行的。
我有与MySQL相同的问题，因为不幸的是不支持增量备份。 这就是为什么我写了一个bash脚本，为每个数据库转储不同的文件中的表。 之后，我压缩它和zdiff以前的副本，忽略最后2-3行（其中mysqldump写入当前date）。 如果文件之间没有差异，我不会同步云中的内容。 这种方法的缺点是解决scheme的复杂性，在恢复数据时增加了额外的步骤。
另外，如果您在服务器上运行的软件的开发中有任何词汇，则可以为每个表添加一个额外的参数，以便跟踪更改。 所以基于此，您指示备份脚本只转储自上次备份以来更改的表。
普通的Rsync是备份文件的一个很好的select，因为它很简单并且性能良好。 但是，如果在Rsync-ed文件被修改时，副本可能已损坏。 所以确保所有文件都closures是非常重要的。 在你的情况下，如果有一些图像文件被改变和更正，下一个Rsync会覆盖它们，因为Rsync只复制修改的文件，这就像一个自我修复的过程。 所以我认为Rsync和S3保存是一个很好的select。