Amazon S3のデータをバックアップする必要がありますか？
S3で200 GBの製品イメージをホストしています（これは私のプライマリファイルホストです）。
そのデータを別の場所にバックアップする必要がありますか、それともS3はそのまま安全ですか？
S3バケットをEC2インスタンスにマウントして、毎晩rsyncバックアップを作成する実験を行っています。問題は、約300万ファイルであるため、さまざまなrsyncのニーズを生成するのに時間がかかることです。バックアップの完了には、実際には約3日かかります。
これをより良くするためのアイデアはありますか？ （それが必要な場合でも？）
私はこれについて十分に面白い研究をしてきました。
S3へのバックアップは、結果整合性のために、地域によっては失敗する可能性があります。基本的な警告は、これを十分に行うと、Amazonがサーバー間で同期するバックグラウンドでのファイルシステムの魔法が原因でファイルを開いたり検索したりするときにエラーが発生し、バックアップが信頼できない可能性があるということです。
それらを別の方法で保存する必要があるかどうかについては、これはリスク管理に依存します。 Amazonがデータを保持することを信頼していますか？
ストレージシステムで何かが失われたり、大きな障害が発生したりする可能性があります。彼らは間違いなく彼らの契約に条項があり、彼らがあなたのデータを失った場合、それはyour問題であると明記しています。彼らのものではない。また、データが別の場所に格納されているため、データがどのように処理されるかがわかりません。法執行機関はあなたのデータを求めていますか？他の誰かがそれにアクセスしたことさえ知らないかもしれません。
信用できますか？データがビジネスにとって重要ではなく、このリスクを受け入れる用意がある場合は、オフサイトストレージにデータをダウンロードする必要はありません。 Amazonのストレージサーバーでデータが安全であるというリスクを冒したくない場合は、定期的にデータを自分のストレージにダンプするように準備する必要があります。
言い換えれば、あなたのリスク許容度とビジネスニーズに依存するので、これに対する正解はないと思います。多くの人々はクラウドでのストレージだけで収入を完全に信頼することはないでしょう、個人的には私はそれに対して少し警戒を感じます...
これをよりよく行うために、ディスカッションと研究では、データを格納するのに十分な大きさのEBSボリュームを作成し、それをEC2インスタンスに接続し、そこにデータを保存してから、ボリュームをアンマウントして、そのデータをS3に保存することを検討する必要があります。 。ボリュームファイル自体をS3に保存するのか、コンテンツに保存するのかを調査中ですが、完了したらEBSインスタンスを削除してストレージコストを節約できます。
[〜＃〜] edit [〜＃〜]読み直しで、S3からEC2インスタンスに保存していることを確認しました。その逆ではありません（ただし、最終的なものかどうかはわかりません）一貫性の問題はまだそこに問題を引き起こす可能性があります）。バックアップとしてEC2インスタンスにデータを保存しようとしていますか？コスト的にはそれは健全な戦術ではないと思います。その種類のデータをVM時間と共に）長期保存することを考慮に入れると、ローカルドライブに物をバックアップする方が安くなる可能性があります。ドライブコストを使用すると、データをバックアップとしてのローカルディスク。
アマゾンとそのストレージを信頼することについては、私はまだ警告を続けます。 Amazon S3にすべてを保持したいが、冗長性を高めたい場合は、リージョン間でS3バケットを複製します。1つのリージョンに影響する停止があったとしても、それらすべてを無効にするべきではありません。あなたが望むでしょう。しかし、何でも可能です。
それは、データをどれだけ重視するか、どれだけの金額を支払う意思があるか、そしてどれだけのリスクを許容したいかにかかっています。
私は s3cmd'ss3cmd syncを使用してこれを行いました。操作は少しrsyncに似ており、S3と選択した別のLinuxシステムの間でディレクトリ全体をプッシュおよびプルできます。
実行中のEC2インスタンス、または独自の開発用ワークステーション（またはストレージサーバー）にs3cmd syncできなかった理由はわかりません。
VPCインスタンスを設定し、VPC内の小さなノードにバックアップサーバーの役割を割り当て、Amazonのネットワーク内のIPとローカルサブネット内の両方にIPを割り当てることができます。
私のアドバイスは、あなたのデータはあなたの責任であり、Amazonの責任ではないということです。データの損失がそれほど大きな問題ではない場合は、独自のバックアップを行わないでください。そうであれば、私と同じように（少なくとも）安価なJBODに（そして定期的に確認して）自分のバックアップを取ってください。
Amazonがデータを失ったその日について、Amazonがデータに対してどの程度の責任を負うかを知ることができます。
これは古いスレッドですが、S3のバックアップをGooglingするときに最初に出てくるものなので、追加したいと思いました...
これについて自分で調査したところ、Rcloneを発見しました https://rclone.org/ -これは、クラウドファイルストレージサービス間でコピーするように設計されたrsync風のソフトウェアであり、それらのほとんどをサポートしています。所属がなく、まだ使っていないので、良いか悪いかはわかりませんが、誰かの役に立つかもしれないと思いました。
クラウドでホストされたファイル（S3、Googleストレージ、Rackspaceクラウドファイルなど）の「オフサイト」バックアップを行うホストされたサービスの機会があるように思えます...
余裕があれば（これを行うと）、すべてのデータがサーバーに保存されますが、Amazon s3からデータを取得します。そのため、Amazonが何らかの理由（木材に触れる）でダウンした場合、すべてのデータをサーバーから即座に即座に取得できます。サーバーからローカルドライブに毎月バックアップを作成します。私のウェブサイトはサイトで2TBを超えるので。