У меня есть сервер Ubuntu, размещенный на Digital Ocean, который вырос из существующего решения для резервного копирования.
Соответствующие части стека, которые я использую, - это Node.js, MongoDB и Elasticsearch.
До сих пор резервное копирование выполнялось путем сброса всей базы данных MongoDB, сохранения конфигурации ES и копирования всех других файлов (журналов, самого кода и т. Д.) В каталог приложения. Если это первое число месяца, также копируются все пользовательские файлы, в противном случае добавляются только файлы, измененные с первого числа месяца. Затем все они архивируются в один файл и загружаются в Amazon S3.
Размер данных достиг точки, когда этот процесс занимает слишком много места на диске, и файл не может быть загружен в S3 за один раз.
Каков следующий уровень для приложения такого размера (8 ГБ пользовательских файлов, 125 000 пользователей, 3 000 других документов, все с возможностью поиска в ES)?
Я понимаю, что вопросы, основанные на мнении, не подходят для Server Fault. Я не спрашиваю мнения, просто какое решение является нормальным и экономичным для приложения такого размера.
ОБНОВИТЬ: Это соответствующие части скрипта и конфигурации, с которыми я пытаюсь использовать Duplicity. Я использую Node для управления резервным копированием, поскольку он подходит для моего существующего решения для ведения журнала, уже запланирован для согласования со всем остальным в период низкой активности и может переноситься между ОС.
Скрипт узла, ведение журнала, конечно, требует улучшения:
// 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 ---
У меня есть хороший опыт резервного копирования с помощью двуличие. Если вы можете создать моментальный снимок и подключить его только для чтения, то это очень хороший вариант для согласованного инкрементного резервного копирования.
Обычно проблема с резервным копированием баз данных (MongoDB, ElasticSearch, MySQL, вы называете это) - это согласованность. То же самое применимо и к резервному копированию общих файлов, но с базами данных риски повреждения данных, вероятно, самые высокие.
У вас есть несколько вариантов (надеюсь, другие добавят больше)
Сделайте дамп базы данных и сделайте резервную копию дампа. Это самый простой, безопасный и простой способ.
Остановите базу данных (или воспользуйтесь другим методом для согласования данных на диске) и сделайте резервную копию. (таким образом это приводит к длительному простою, что не всегда возможно)
Остановите базу данных (как в №2), сделайте снимок (том или fs, убедитесь, что fs согласован в этой точке), запустите базу данных, смонтируйте снимок только для чтения и сделайте резервную копию. Но не все настройки подходят для этого.
Остановите базу данных (как в №2), сделайте снимок (на этот раз он работает только для томов, убедитесь, что fs согласован в этой точке), запустите базу данных, сделайте резервную копию снимка как блочного устройства. Это может увеличить размер резервной копии и, опять же, не во всех конфигурациях.
Сделайте резервную копию файлов живой базы данных и надейтесь, что она будет работать после восстановления. (Вы здесь играете с огнем.) Если возможно, держись подальше от этого.
Если у вашей технологии есть особый способ резервного копирования, воспользуйтесь им. (Как прямое резервное копирование моментального снимка с 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
Размер данных достиг точки, когда этот процесс занимает слишком много места на диске, и файл не может быть загружен в S3 за один раз.
Загрузите их каждый как отдельный файл. Вероятно, это не тот случай, когда вы выполняете какую-то причудливую дедупликацию, и если вы измените ее, чтобы она была основана на ссылке, это было бы полезно.
До сих пор резервные копии делались путем сброса всей базы данных MongoDB.
Есть инструменты инкрементного резервного копирования (https://github.com/EqualExperts/Tayra) для MongoDB. Я бы посмотрел на их использование, если ваша загрузка обновлений относительно низкая.
Поскольку вы находитесь в Digital Ocean, локальное резервное копирование невозможно. Однако об этом нужно думать стратегически. Если бы вы были размещены непосредственно на Amazon, моментальные снимки файловой системы на S3, вероятно, были бы вам полезны.