web-dev-qa-db-ja.com

AWS S3バケットのバックアップ戦略

S3バケットをバックアップするためのアドバイスやベストプラクティスを探しています。
S3からデータをバックアップする目的は、次の理由によりデータの損失を防ぐことです。

  1. S3の問題
  2. このデータを誤ってS3から削除する問題

いくつかの調査の後、次のオプションが表示されます。

  1. バージョン管理を使用 http://docs.aws.Amazon.com/AmazonS3/latest/dev/Versioning.html
  2. AWS SDKを使用して1つのS3バケットから別のバケットにコピーする
  3. Amazon Glacierへのバックアップ http://aws.Amazon.com/en/glacier/
  4. 運用サーバーへのバックアップ（それ自体がバックアップされます）

どのオプションを選択する必要があり、S3にのみデータを保存することはどれくらい安全ですか？あなたの意見を聞きたいです。
便利なリンク：

amazon-web-servicesamazon-s3backupamazon-glacier
55
Sergey Alekseev

もともと私のブログに投稿した： http://eladnava.com/backing-up-your-Amazon-s3-buckets-to-ec2/

S3バケットを定期的にEC2サーバーに同期する

これは、リモートS3バケットをローカルファイルシステムに同期できるようにする複数のコマンドラインユーティリティを使用することで簡単に実現できます。

s3cmd
最初、s3cmdは非常に有望に見えました。しかし、巨大なS3バケットで試してみたところ、スケーリングに失敗し、Segmentation faultでエラーが発生しました。ただし、小さなバケツでは問題なく動作しました。巨大なバケツでは機能しなかったため、別の方法を探し始めました。

s4cmd
s3cmdの新しいマルチスレッドの代替。さらに有望に見えましたが、ローカルファイルシステムに既に存在するファイルを再ダウンロードし続けていることに気付きました。それは、syncコマンドに期待していた種類の動作ではありません。リモートファイルが既にローカルに存在するかどうかをチェックし（ハッシュ/ファイルサイズのチェックは適切です）、同じターゲットディレクトリでの次の同期実行でスキップする必要があります。この奇妙な動作を報告する問題（ bloomreach/s4cmd /＃46 ）を開きました。それまでの間、私は別の選択肢を見つけようとしました。

awscli
そして、私はawscliを見つけました。これは、異なるクラウドサービス（S3を含む）と対話するためのAmazonの公式コマンドラインインターフェイスです。

AWSCLI

迅速かつ簡単にリモートバケットファイルをローカルファイルシステムにダウンロードする便利な同期コマンドを提供します。

$ aws s3 sync s3：// your-bucket-name/home/ubuntu/s3/your-bucket-name /

利点：

  • スケーラブル-巨大なS3バケットをサポート
  • マルチスレッド-複数のスレッドを利用して、ファイルをより速く同期します
  • スマート-新規または更新されたファイルのみを同期します
  • 高速-マルチスレッドの性質とスマート同期アルゴリズムのおかげ

偶発的な削除

便利なことに、syncコマンドは、ソース（S3バケット）から欠落している場合、宛先フォルダー（ローカルファイルシステム）のファイルを削除しません。逆も同様です。これはS3のバックアップに最適です。ファイルがバケットから削除された場合、再同期してもローカルで削除されません。また、ローカルファイルを削除した場合、ソースバケットからも削除されません。

Ubuntu 14.04 LTSでのawscliのセットアップ

awscliをインストールすることから始めましょう。これを行うには いくつかの方法があります が、apt-get経由でインストールするのが最も簡単であることがわかりました。

$ Sudo apt-get install awscli

設定

次に、 [〜＃〜] iam [〜＃〜] から取得する必要があるアクセスキーIDと秘密キーでawscliを構成する必要があります。ユーザーを作成し、AmazonS3ReadOnlyAccessポリシーをアタッチします。これにより、これらの資格情報にアクセスするユーザーまたはユーザーがS3ファイルを削除することもできなくなります。 us-east-1などのS3リージョンを入力してください。

$ aws configure

aws configure

準備

できれば/home/ubuntu/s3/{BUCKET_NAME}にローカルS3バックアップディレクトリを準備しましょう。 {BUCKET_NAME}を実際のバケット名に置き換えてください。

$ mkdir -p/home/ubuntu/s3/{BUCKET_NAME}

初期同期

次のコマンドを使用して、バケットを初めて同期してみましょう。

$ aws s3 sync s3：// {BUCKET_NAME}/home/ubuntu/s3/{BUCKET_NAME} /

バケットが存在し、AWSの認証情報とリージョンが正しく、宛先フォルダーが有効であると仮定すると、awscliはバケット全体のローカルファイルシステムへのダウンロードを開始します。

バケットのサイズとインターネット接続に応じて、数秒から数時間かかることがあります。それが完了したら、自動cronジョブを設定して、バケットのローカルコピーを最新の状態に保ちます。

Cronジョブのセットアップ

先に進み、sync.shに/home/ubuntu/s3ファイルを作成します。

$ nano /home/ubuntu/s3/sync.sh

次のコードをコピーしてsync.shに貼り付けます。

＃！/ bin/sh 
 
＃現在の日付と時刻をエコーする
 
 echo '--------------- -------------- '
 date 
 echo' ---------------------- ------- '
 echo' '
 
＃Echoスクリプトの初期化
 echo'リモートS3バケットの同期... '
 
＃実際に同期コマンドを実行します（{BUCKET_NAME}をS3バケット名に置き換えます）
/usr/bin/aws s3 sync s3：// {BUCKET_NAME}/home/ubuntu/s3/{ BUCKET_NAME}/
 
＃Echoスクリプトの完了
 echo 'Sync complete'

スクリプト全体で2回、{BUCKET_NAME}をS3バケット名に置き換えてください。

プロのヒント：awsは限られたシェル環境でコマンドを実行し、crontabバイナリにリンクするには/usr/bin/awsを使用する必要があります実行可能ファイルを単独で見つけることができません。

次に、chmodで実行できるように、スクリプトをcrontabにしてください。

$ Sudo chmod + x /home/ubuntu/s3/sync.sh

スクリプトを実行して、実際に機能することを確認してみましょう。

$ /home/ubuntu/s3/sync.sh

出力は次のようになります。

sync.sh output

次に、次のコマンドを実行して、現在のユーザーのcrontabを編集しましょう。

$ crontab -e

crontab -eを初めて実行する場合は、好みのエディターを選択する必要があります。 nanoを選択することをお勧めします。初心者にとって最も使いやすい方法です。

同期頻度

コマンドを記述することにより、スクリプトを実行する頻度とローカルファイルシステム上のスクリプトの場所をcrontabに伝える必要があります。このコマンドの形式は次のとおりです。

m h dom mon dowコマンド

次のコマンドは、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を終了できます。 crontabは現在、同期タスクを1時間ごとに実行します。

プロのヒント：/home/ubuntu/s3/sync.logを検査し、その内容の実行日時を確認し、ログに記録して、同期された新しいファイルを確認します。

準備完了！これで、S3バケットがEC2サーバーに1時間ごとに自動的に同期され、すぐに使用できるようになります。 S3バケットが大きくなるにつれて、新しいファイルに対応するためにEC2サーバーのEBSボリュームサイズを増やす必要がある場合があることに注意してください。 このガイド に従って、EBSボリュームサイズをいつでも増やすことができます。

39
Elad Nava

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、他のバケット、または他のサーバーにデータをバックアップするのに余分なコード/ワークフローは必要ありません（これは本当に悪い選択です、忘れてください）。

23
Viccari

差分領域にある種の増分バックアップを保持するだけの簡単な方法があると思います。

上記のすべての提案は、実際には単純またはエレガントなソリューションではありません。バックアップソリューションよりもアーカイブソリューションの方が多いと思うので、氷河をオプションとは本当に考えていません。バックアップを考えるとき、ジュニア開発者からの災害復旧は、バケットを再帰的に削除するか、おそらくアプリのエクスプロイトまたはバグで、s3からデータを削除します。

私にとって最良の解決策は、あるバケットを別のリージョンにバックアップするスクリプトであり、毎日1週間と1週間に1回バックアップすることで、何かひどいことが起こった場合にリージョンを切り替えることができます。私はこのようなセットアップを持っていません、私はそれをやるのに少し手間がかかるので、私はそれをやろうとしていませんでした。

8
David

次の方法を使用してS3データをバックアップできます

  1. AWS datapipelineを使用してバックアッププロセスをスケジュールします。以下の2つの方法で実行できます。

    a。 1つのs3バケットから別のs3バケットにコピーできるdatapipelineのcopyActivityを使用します。

    b。 datapipelineのShellActivityおよび「S3distcp」コマンドを使用して、バケットから別のバケットに再帰的なs3フォルダーの再帰的なコピーを実行します（並行して）。

  2. S3バケット内でバージョン管理を使用して、異なるバージョンのデータを維持します

  3. データのバックアップに氷河を使用する（バックアップを元のバケットに高速に復元する必要がない場合（データが圧縮形式で保存されているため、氷河からデータを取得するのに時間がかかる）または保存する場合に使用します）バックアップ用の別のs3バケットの使用を回避することでいくらかコストがかかります）、このオプションは、バックアップするs3バケットのライフサイクルルールを使用して簡単に設定できます。

オプション1を使用すると、元のs3バケットを誤って削除した場合のセキュリティを強化できます。別の利点は、別のs3バケットの日付ごとのフォルダーにバックアップを保存できることです。特定の日付のバックアップを復元します。それはすべてユースケースに依存します。

8
Varun

S3バケット自体ですぐに利用可能なクロスリージョンレプリケーション機能を使用してはどうですか？この機能に関する役立つ記事をいくつか紹介します

8
Adrian Teh

この質問は少し前に投稿されましたが、他のソリューションで MFA delete 保護について言及することが重要だと思いました。 OPは、データの偶発的削除を解決しようとしています。多要素認証（MFA）は、2つの異なるシナリオでここに現れます-

  1. オブジェクトバージョンの完全な削除-バケットのバージョン管理でMFA削除を有効にします。

  2. バケット自体を誤って削除する-MFA認証なしで削除を拒否するバケットポリシーを設定します。

クロスリージョンレプリケーション および バージョン管理 と組み合わせて、データ損失のリスクを減らし、リカバリシナリオを改善します。

詳細はこのトピックの ブログ投稿 です。

1
user1590603