我有一个运行 Web 服务器的 EC2 实例，该服务器将用户上传的文件存储到 S3。这些文件被写入一次并且永远不会更改，但用户偶尔会检索到这些文件。我们每年可能会积累大约 200-500GB 的数据。我们希望确保这些数据是安全的，尤其是防止意外删除，并且希望能够恢复无论出于何种原因而被删除的文件。
我已经阅读了 S3 存储桶的版本控制功能，但我似乎无法找到没有修改历史记录的文件是否可以恢复。有关版本控制，请参阅此处的 AWS 文档：
http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html
在这些示例中，它们没有显示上传数据但从未修改然后删除的场景。在这种情况下删除的文件是否可以恢复？
然后，我们认为我们可以使用对象生命周期管理将 S3 文件备份到 Glacier：
http://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html
但是，这似乎对我们不起作用，因为文件对象没有复制到 Glacier 而是移动到 Glacier（更准确地说，它似乎是一个被更改的对象属性，但无论如何......）。
因此，似乎没有直接的方法来备份 S3 数据，并且将数据从 S3 传输到本地服务器可能很耗时，并且随着时间的推移可能会产生大量的传输成本。
最后，我们认为我们会每月创建一个新存储桶作为每月完整备份，并在第 1 天将原始存储桶的数据复制到新存储桶。然后使用类似 duplicity（http://duplicity.nongnu.org/ ) 我们将每晚同步备份存储桶。在月底，我们会将备份存储桶的内容放入 Glacier 存储中，并使用原始存储桶的新当前副本创建一个新的备份存储桶……并重复此过程。这似乎可以工作并最大限度地减少存储/传输成本，但我不确定重复性是否允许直接进行桶到桶传输，而无需先将数据带到控制客户端。
所以，我想这里有几个问题。首先，S3 版本控制是否允许恢复从未修改过的文件？有什么方法可以将我错过的 S3 文件“复制”到 Glacier？重复性或任何其他工具可以直接在 S3 存储桶之间传输文件以避免传输成本吗？最后，我在备份 S3 数据的方法上是否偏离了标准？
提前感谢您提供的任何见解！
我刚试过这个。是的，您可以从原始版本恢复。当您删除文件时，它会生成一个删除标记，您可以恢复之前的版本，即：单一的、唯一的修订版。
Glacier 真正意味着长期存储，这是非常不经常访问的。一次性检索大部分数据也会变得非常昂贵，因为它不适用于大量数据的时间点恢复（按百分比计算）。
不要这样做，每个帐户只能有 100 个存储桶，因此在 3 年内，仅备份就会占用三分之一的存储桶限额。
是的
从来没听说过
我不喜欢安装 s3，因为它很慢并且可以挂起并且像老式 nfs 一样执行。最好根据需要向上/向下。
它很容易编写脚本...不要忘记您的 ~/.s3cfg 文件
听起来您可能需要 S3FS，它基本上可以像安装本地文件系统一样安装您的 S3 存储桶：
http://code.google.com/p/s3fs/wiki/FuseOverAmazon
我更喜欢使用这个分叉版本，因为它保留了与在 Amazon S3 的 Web 控制面板中创建的相同的文件夹结构：
https://github.com/tongwang/s3fs-c
然后我有一些 shell 脚本，它们基本上用于
rsync将数据同步到我的本地设置。一般来说，我发现 S3FS 最适合阅读放置在 Amazon S3 存储桶中的内容。写作不是那么一致。但出于备份 S3 存储桶的目的，S3FS 的 Tony Wang 分支运行良好。