112

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

  1. S3号
  2. このデータを誤って S3 から削除してしまう問題

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

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

どのオプションを選択すればよいですか? また、データを S3 のみに保存する場合の安全性は? あなたの意見を聞きたいです。
いくつかの便利なリンク:

4

8 に答える 8

72

私のブログに最初に投稿されたもの: 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た。これは、Amazon のさまざまなクラウド サービス (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

構成

次に、ユーザーを作成してAmazonS3ReadOnlyAccessポリシーをアタッチすることにより、 IAMawscliから取得する必要があるアクセス キー ID とシークレット キーを使用して構成する必要があります。これにより、これらの認証情報にアクセスできるユーザーが S3 ファイルを削除することも防止できます。などの S3 リージョンを入力してください。us-east-1

$ aws構成

aws 構成

準備

できればローカルの 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 ジョブを設定して、バケットのローカル コピーを最新の状態に保ちます。

Cron ジョブの設定

sync.sh次の場所にファイルを作成し/home/ubuntu/s3ます。

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

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

#!/ビン/sh

# 現在の日付と時刻をエコーする

エコー ' -  -  -  -  -  -  -  -  -  -  -  -  -  - -'
日にち
エコー ' -  -  -  -  -  -  -  -  -  -  -  -  -  - -'
エコー ''

# エコー スクリプトの初期化
echo 'リモート S3 バケットを同期しています...'

# 実際に同期コマンドを実行します ({BUCKET_NAME} を S3 バケット名に置き換えます)
/usr/bin/aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

# エコースクリプトの補完
echo '同期完了'

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

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

次に、chmodスクリプトを で実行できるようにしcrontabます。

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

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

$ /home/ubuntu/s3/sync.sh

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

sync.sh の出力

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

$ crontab -e

を初めて実行するcrontab -e場合は、優先エディターを選択する必要があります。nano初心者でも扱いやすいのでオススメです。

同期頻度

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

mh dom mon dow コマンド

次のコマンドは、1 時間ごとにスクリプトcrontabを実行しsync.sh(minute:0 および hour:* パラメーターで指定)、スクリプトの出力をディレクトリ内のsync.logファイルにパイプするように構成します。s3

0 * * * * /home/ubuntu/s3/sync.sh > /home/ubuntu/s3/sync.log

crontab編集中のファイルの最後にこの行を追加する必要があります。次に、 Ctrl + Wを押してからEnterを押して、ファイルをディスクに保存します。その後、 Ctrl + Xnanoを押して終了できます。1 時間ごとに同期タスクが実行されるようになりました。crontab

プロのヒント: 1 時間ごとの cron ジョブが正常に実行されていることを確認するには、/home/ubuntu/s3/sync.log.

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

于 2015-10-03T20:39:33.900 に答える
8

この質問は少し前に投稿されましたが、他のソリューションでMFA 削除保護について言及することが重要だと思いました。OPは、データの誤った削除を解決しようとしています。多要素認証 (MFA) は、次の 2 つの異なるシナリオで明らかになります -

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

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

クロスリージョン レプリケーションおよびバージョニングと組み合わせて、データ損失のリスクを軽減し、復旧シナリオを改善します

このトピックに関する詳細が記載されたブログ投稿を次に示します。

于 2018-06-16T12:56:28.063 に答える
1

もし、データが多すぎます。すでにバケットがある場合は、初回同期に時間がかかりすぎます。私の場合は 400GB でした。初回で3時間かかりました。したがって、レプリカは S3 バケットのバックアップに適したソリューションになると思います。

于 2019-11-23T06:52:24.530 に答える