S3バケットをバックアップするためのアドバイスやベストプラクティスを探しています。
S3からデータをバックアップする目的は、次の理由によるデータの損失を防ぐことです。
調査の結果、次のオプションが表示されます。
どのオプションを選択する必要があり、S3にのみデータを保存するのはどれほど安全ですか？あなたの意見を聞きたい。
いくつかの便利なリンク：
回答:
もともと私のブログに投稿されました：http：//eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/
これは、リモートS3バケットをローカルファイルシステムに同期できるようにする複数のコマンドラインユーティリティを利用することで簡単に実現できます。
s3cmd
最初は、s3cmd非常に有望に見えました。しかし、私の巨大なS3バケットで試してみたところ、スケーリングに失敗し、エラーが発生しましたSegmentation fault。ただし、小さなバケットでは問題なく機能しました。巨大なバケツではうまくいかなかったので、私は別の方法を探し始めました。
s4cmd
。の新しいマルチスレッド代替s3cmd。さらに有望に見えましたが、ローカルファイルシステムにすでに存在するファイルを再ダウンロードし続けていることに気付きました。これは、syncコマンドに期待していたような動作ではありません。リモートファイルがすでにローカルに存在するかどうかをチェックし（ハッシュ/ファイルサイズのチェックは適切です）、同じターゲットディレクトリでの次の同期実行でスキップする必要があります。この奇妙な動作を報告するために、問題（bloomreach / s4cmd /＃46）を開きました。その間に、私は別の選択肢を見つけることに着手しました。
awscli
そして私は見つけましたawscli。これは、S3を含むさまざまなクラウドサービスとやり取りするためのAmazonの公式コマンドラインインターフェースです。
これは、リモートバケットファイルをローカルファイルシステムにすばやく簡単にダウンロードする便利な同期コマンドを提供します。
$ aws s3 sync s3：// your-bucket-name / home / ubuntu / s3 / your-bucket-name /
便利なことに、syncソース（S3バケット）にファイルがない場合、コマンドは宛先フォルダー（ローカルファイルシステム）内のファイルを削除しません。その逆も同様です。これはS3のバックアップに最適です。ファイルがバケットから削除された場合、ファイルを再同期してもローカルでは削除されません。また、ローカルファイルを削除しても、ソースバケットからは削除されません。
をインストールすることから始めましょうawscli。これを行うにはいくつかの方法がありますが、を介してインストールするのが最も簡単であることがわかりましたapt-get。
$ sudo apt-get install awscli
次に、ユーザーを作成し、AmazonS3ReadOnlyAccessポリシーを添付して、IAMawscliから取得する必要があるアクセスキーIDとシークレットキーを使用して構成する必要があります。これにより、あなたやこれらの認証情報にアクセスできる人がS3ファイルを削除することもできなくなります。必ず、などのS3リージョンを入力してください。us-east-1
$ aws configure
ローカルのS3バックアップディレクトリを、できればで準備しましょう/home/ubuntu/s3/{BUCKET_NAME}。必ず{BUCKET_NAME}実際のバケット名に置き換えてください。
$ mkdir -p / home / ubuntu / s3 / {BUCKET_NAME}
次のコマンドを使用して、バケットを初めて同期してみましょう。
$ aws s3 sync s3：// {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /
バケットが存在し、AWS認証情報とリージョンが正しく、宛先フォルダーが有効であるawscliと仮定すると、バケット全体のローカルファイルシステムへのダウンロードが開始されます。
バケットのサイズとインターネット接続によっては、数秒から数時間かかる場合があります。それが完了したら、先に進み、バケットのローカルコピーを最新の状態に保つための自動cronジョブを設定します。
先に進み、sync.shファイルを作成します/home/ubuntu/s3：
$ nano /home/ubuntu/s3/sync.sh
次のコードをコピーして貼り付けますsync.sh。
＃！/ bin / sh
＃現在の日付と時刻をエコーする
エコー ' - - - - - - - - - - - - - - -'
日付
エコー ' - - - - - - - - - - - - - - -'
エコー ''
＃エコースクリプトの初期化
echo 'リモートS3バケットを同期しています...'
＃実際にsyncコマンドを実行します（{BUCKET_NAME}をS3バケット名に置き換えます）
/ usr / bin / aws s3 sync s3：// {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /
＃エコースクリプトの完了
エコー「同期完了」
スクリプト全体で2回、{BUCKET_NAME}をS3バケット名に置き換えてください。
上級者向けのヒント：限られたシェル環境でコマンドを実行し、実行可能ファイルを単独で見つけることができない
/usr/bin/awsため、awsバイナリへのリンクに使用する必要crontabがあります。
次に、chmodスクリプトを確認して、によって実行できるようにしcrontabます。
$ sudo chmod + x /home/ubuntu/s3/sync.sh
スクリプトを実行して、実際に機能することを確認してみましょう。
$ /home/ubuntu/s3/sync.sh
出力は次のようになります。
次に、crontab次のコマンドを実行して、現在のユーザーを編集しましょう。
$ crontab -e
初めて実行するcrontab -e場合は、優先するエディターを選択する必要があります。nano初心者にとって最も扱いやすいので、選択することをお勧めします。
crontabコマンドを作成して、スクリプトを実行する頻度と、スクリプトがローカルファイルシステムのどこにあるかを指定する必要があります。このコマンドの形式は次のとおりです。
mh dom mondowコマンド
次のコマンドcrontabは、sync.shスクリプトを1時間ごとに実行し（minute：0およびhour：*パラメーターで指定）、スクリプトの出力をディレクトリsync.log内のファイルにパイプするように構成しますs3。
0 * * * * /home/ubuntu/s3/sync.sh> /home/ubuntu/s3/sync.log
crontab編集しているファイルの最後にこの行を追加する必要があります。次に、Ctrl + Wを押してからEnterキーを押して、ファイルをディスクに保存します。その後、Ctrl + Xをnano押して終了できます。これで、同期タスクが1時間ごとに実行されます。crontab
上級者向けのヒント：毎時cronジョブが正常に実行されていることを確認するには、
/home/ubuntu/s3/sync.logその内容を調べて実行日時を確認し、ログを調べて同期された新しいファイルを確認します。
準備完了！これで、S3バケットがEC2サーバーに1時間ごとに自動的に同期されるようになり、準備が整いました。時間の経過とともに、S3バケットが大きくなると、新しいファイルに対応するためにEC2サーバーのEBSボリュームサイズを増やす必要がある場合があることに注意してください。このガイドに従うことで、いつでもEBSボリュームサイズを増やすことができます。
awscli、aws s3 syncコマンドでこれを自動的に同期することをサポートしているようには見えません。これを手動で実装する必要があるようです。
S3の耐久性が99.999999999％であることを説明している関連リンクを考慮して、私はあなたの懸念＃1を破棄します。真剣に。
さて、＃2が有効なユースケースであり、あなたにとって本当に懸念事項である場合、私は間違いなくオプション＃1または＃3に固執します。それらのどれですか？それは本当にいくつかの質問に依存します：
Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. これでよろしいですか？ ストレージの使用量が非常に多い場合を除いて、バケットのバージョン管理を使用します。このように、Glacier、他のバケット、または他のサーバーにデータをバックアップするために追加のコード/ワークフローは必要ありません（これは本当に悪い選択です。忘れてください）。
次の方法を使用してS3データをバックアップできます
AWSデータパイプラインを使用してバックアッププロセスをスケジュールします。これは、以下の2つの方法で実行できます。
a。あるs3バケットから別のs3バケットにコピーできるdatapipelineのcopyActivityを使用します。
b。datapipelineのShellActivityと「S3distcp」コマンドを使用して、バケットから別のバケットへの再帰的なs3フォルダーの再帰的なコピーを（並行して）実行します。
S3バケット内のバージョニングを使用して、異なるバージョンのデータを維持します
データのバックアップに氷河を使用する（バックアップを元のバケットにすばやく復元する必要がない場合（データは圧縮形式で保存されるため、氷河からデータを取得するのに時間がかかる）、または保存する場合に使用します。別のs3バケットをバックアップに使用しないようにすることである程度のコストがかかります）、このオプションは、バックアップを取りたいs3バケットのライフサイクルルールを使用して簡単に設定できます。
オプション1は、元のs3バケットを誤って削除した場合に備えて、セキュリティを強化できます。別の利点は、バックアップを別のs3バケットの日付ごとのフォルダーに保存できることです。これにより、特定の日付にどのデータがあったかを知ることができます。特定の日付のバックアップを復元します。それはすべてあなたのユースケースに依存します。
S3バケット自体ですぐに利用できるクロスリージョンレプリケーション機能を使用するのはどうですか？この機能に関するいくつかの役立つ記事があります
今では、diff領域である種の増分バックアップを保持するより簡単な方法があると思います。
上記のすべての提案は、実際には単純またはエレガントな解決策ではありません。氷河はバックアップソリューションというよりもアーカイブソリューションの方が多いと思うので、私は氷河を選択肢とは考えていません。バックアップを考えるとき、ジュニア開発者からのディザスタリカバリは、バケットを再帰的に削除するか、アプリのエクスプロイトやバグがs3からのものを削除すると思います。
私にとって最善の解決策は、1つのバケットを別のリージョンにバックアップするスクリプトです。1日1回、1週間に1回、何かひどいことが起こった場合にリージョンを切り替えることができます。私はこのような設定を持っていません、私はそれを行うのに少し手間がかかるのでそれを行うことに慣れていないことを調べました。それが私が使用するストックソリューションがあればいいのにと思います。
の場合、データが多すぎます。すでにバケットをお持ちの場合は、初めて同期に時間がかかりすぎます。私の場合、400GBでした。初めて3時間かかりました。したがって、レプリカを作成できるのは、S3バケットバックアップの優れたソリューションだと思います。