web-dev-qa-db-ja.com

AmazonS3への完全なデータバックアップ

Digital OceanでホストされているUbuntuサーバーがあり、既存のバックアップソリューションを超えています。

私が使用するスタックの関連部分は、Node.js、MongoDB、Elasticsearchです。

これまでのところ、バックアップは、MongoDBデータベース全体をダンプし、ES構成を保存し、他のすべてのファイル（ログ、コード自体など）をアプリケーションディレクトリにコピーすることによって実行されてきました。月の最初の場合は、すべてのユーザーファイルもコピーされます。それ以外の場合は、月の最初以降に変更されたファイルのみが追加されます。これらはすべて1つのファイルに圧縮され、AmazonS3にアップロードされます。

データサイズが、このプロセスで必要なディスク容量が多すぎて、ファイルをS3に一度にアップロードできないレベルに達しました。

このサイズのアプリケーションの次のレベルは何ですか（8 GBのユーザーファイル、125,000ユーザー、3,000の他のドキュメント、すべてESで検索可能）？

サーバー障害については、意見に基づく質問は問題ないことを理解しています。私は意見を求めているのではなく、このサイズのアプリケーションに対する通常の費用効果の高いソリューションが何であるかを尋ねています。

PDATE：これらは、Duplicityを使用しようとしているスクリプトと構成の関連部分です。 Nodeを使用してバックアップを管理しています。これは、既存のロギングソリューションに適合し、アクティビティの少ない時間に他のすべてと連携するようにスケジュールされており、OS間で移植可能であるためです。

ノードスクリプト、もちろんロギングには改善が必要です：

// Walks a directory recursively and returns a flat list of files
function walkDir() {};

// Node based rm -rf
function rmrf() {};

exec("mongodump --out dump", { cwd: process.cwd() }, function(err, dta) {
    if (err) return log("Error backing up: couldn't dump MongoDB!");

    exec("Sudo duply ats backup", function(err) {
        if (err) log("Error running Duplicity");
        else rmrf("dump");

        log("Exiting.");

        process.exit();
    });
});

重複構成：

GPG_PW='GPG password'

TARGET='s3://s3-us-east-1.amazonaws.com/bucket'

TARGET_USER='Known working AWS credentials'
TARGET_PASS='AWS secret key'

SOURCE='/var/appdir'

MAX_AGE=6M

DUPL_PARAMS="$DUPL_PARAMS --exclude "/var/appdir/elasticsearch/data/**" "

--s3-use-new-styleを試し、s3+http://を使用し、S3_USE_SIGV4を設定しましたが、うまくいきませんでした。

これは私がDuplicityから取得しているログです：

Start duply v1.5.10, time is 2015-07-05 09:30:13.
Using profile '/root/.duply/ats'.
Using installed duplicity version 0.6.23, python 2.7.6, gpg 1.4.16 (Home: ~/.gnu                                                                     pg), awk 'GNU Awk 4.0.1', bash '4.3.11(1)-release (x86_64-pc-linux-gnu)'.
Signing disabled. Not GPG_KEY entries in config.
Test - Encryption with passphrase (OK)
Test - Decryption with passphrase (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.25562.1436103014_*'(OK)

--- Start running command PRE at 09:30:14.155 ---
Skipping n/a script '/root/.duply/ats/pre'.
--- Finished state OK at 09:30:14.183 - Runtime 00:00:00.027 ---

--- Start running command BKP at 09:30:14.208 ---
Reading globbing filelist /root/.duply/ats/exclude
BackendException: No connection to backend
09:31:27.427 Task 'BKP' failed with exit code '23'.
--- Finished state FAILED 'code 23' at 09:31:27.427 - Runtime 00:01:13.218 ---

--- Start running command POST at 09:31:27.465 ---
Skipping n/a script '/root/.duply/ats/post'.
--- Finished state OK at 09:31:27.491 - Runtime 00:00:00.026 ---
linuxbackupmongodbelasticsearch
3
A.M.K

duplicity を使用してバックアップした経験があります。スナップショットを作成して読み取り専用でマウントできる場合は、一貫性のある増分バックアップを作成することをお勧めします。

通常、問題はデータベース（MongoDB、ElasticSearch、MySQL、名前を付けます）のバックアップにあります。同じことが一般的なファイルのバッキングにも当てはまりますが、データベースでは、データ破損のリスクがおそらく最も高くなります。

オプションはほとんどありません（他の人がさらに追加することを願っています）

  1. データベースをダンプし、ダンプをバックアップします。それは最も単純で、最も安全で、最も簡単です。

  2. データベースを停止し（または他の方法を使用してディスク上のデータの整合性を確保し）、バックアップを実行します。 （このようにすると、長いダウンタイムが発生しますが、常に可能であるとは限りません）

  3. データベースを停止し（＃2のように）、スナップショットを作成し（ボリュームまたはfs、その時点でfsが一貫していることを確認します）、データベースを起動し、スナップショットを読み取り専用でマウントしてバックアップします。ただし、すべての設定がこれに適しているわけではありません。

  4. データベースを停止し（＃2のように）、スナップショットを実行し（今回はボリュームに対してのみ機能し、その時点でfsが一貫していることを確認します）、データベースを起動し、スナップショットをブロックデバイスとしてバックアップします。これにより、バックアップのサイズが大きくなる可能性があり、すべての構成で可能になるとは限りません。

  5. ライブデータベースファイルをバックアップし、復元時に機能することを期待します。 （ここでは火遊びをしています。）可能であれば、これに近づかないでください。

  6. テクノロジーに特別なバックアップ方法がある場合は、それを使用してください。 （ELBからS3への直接スナップショットバックアップのように。）

どの方法を選択する場合でも、必ずすべきことを覚えておいてくださいバックアップから復元できることをテストする数回、いくつかの異なるバックアップから。

#!/bin/bash
BACKUP_BASE="/data/backups/"
DIRNAME="mongo"
BUCKET="mybackups"
ARCHIVE_DIR="/data/backups_duplicity_archives/${DIRNAME}"
VERBOSE="-v 4"
S3_PARAMS="--s3-use-new-style" # --s3-use-multiprocessing" # --s3-use-rrs"
export PASSPHRASE="something"
export AWS_ACCESS_KEY_ID="AN_ID"
export AWS_SECRET_ACCESS_KEY="A_KEY"

cd ${BACKUP_BASE}
rm -rf ${BACKUP_BASE}/${DIRNAME}
/usr/bin/mongodump -h 10.0.0.1 -o ${BACKUP_BASE}/${DIRNAME}/databasename --oplog

/usr/bin/duplicity $S3_PARAMS --asynchronous-upload ${VERBOSE} --archive-dir=${ARCHIVE_DIR} incr --full-if-older-than 14D ${BACKUP_BASE}/${DIRNAME} "s3+http://${BUCKET}/${DIRNAME}"
if [ ! $! ]; then
        /usr/bin/duplicity $S3_PARAMS ${VERBOSE} --archive-dir=${ARCHIVE_DIR} remove-all-but-n-full 12 --force "s3+http://${BUCKET}/${DIRNAME}"
        /usr/bin/duplicity $S3_PARAMS ${VERBOSE} --archive-dir=${ARCHIVE_DIR} remove-all-inc-of-but-n-full 4 --force "s3+http://${BUCKET}/${DIRNAME}"
fi
3
Fox

データサイズが、このプロセスで必要なディスクスペースが多すぎて、ファイルをS3に一度にアップロードできないレベルに達しました。

それらをそれぞれ独自の個別のファイルとしてアップロードします。ある種の派手な重複排除を行っているわけではないでしょう。それを参照ベースに変更する場合は役に立ちます。

これまでのところ、バックアップはMongoDBデータベース全体をダンプすることによって行われてきました

MongoDB用の増分バックアップツール（ https://github.com/EqualExperts/Tayra ）があります。更新の負荷が比較的低い場合は、これらの使用を検討します。

Digital Oceanを使用しているため、ローカルバックアップはオプションではありません。しかし、それは戦略的に考えることです。 Amazonで直接ホストされている場合は、S3へのファイルシステムスナップショットが役立つ可能性があります。

1
Jeff Ferland