Backup completo de dados para o Amazon S3

Question

Eu tenho um servidor Ubuntu hospedado na Digital Ocean que superou a solução de backup existente.

As partes relevantes da pilha que uso são Node.js, MongoDB e Elasticsearch.

Até agora, foram feitos backups despejando todo o banco de dados MongoDB, salvando a configuração ES e copiando todos os outros arquivos (logs, o código em si, etc.) no diretório do aplicativo. Se for o primeiro dia do mês, todos os arquivos do usuário também serão copiados. Caso contrário, somente os arquivos alterados a partir do primeiro dia do mês serão adicionados. Todos eles são compactados em um arquivo e carregados no Amazon S3.

O tamanho dos dados atingiu o ponto em que este processo ocupa muito espaço em disco e o arquivo não pode ser carregado para o S3 de uma só vez.

Qual é o próximo nível para um aplicativo desse tamanho (8 GB de arquivos do usuário, 125.000 usuários, 3.000 outros documentos, todos pesquisáveis no ES)?

Eu entendo que as perguntas baseadas em opinião não são aceitáveis no Server Fault. Não estou pedindo opiniões, apenas qual é a solução normal e econômica para uma aplicação desse tamanho.

UPDATE: Estas são as partes relevantes do script e da configuração em que estou tentando usar o Duplicity. Estou usando o Node para gerenciar o backup, pois ele se ajusta à minha solução de registro existente, já está programado para se alinhar com todo o restante em um tempo de baixa atividade e é portátil entre sistemas operacionais.

Script do nó, o logging precisa de melhorias:

// 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();
    });
});

Configuração da duplicidade:

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/**" "

Eu tentei --s3-use-new-style , usando s3+http:// e definindo S3_USE_SIGV4 , mas não tive sorte.

Este é o log que estou recebendo da 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 ---

    

Answer 1

Tenho uma boa experiência de backup usando a duplicidade . Se você conseguir fazer um snapshot e montá-lo somente para leitura, é uma boa opção ter um backup incremental consistente.

Normalmente, o problema é fazer o backup de bancos de dados (MongoDB, ElasticSearch, MySQL, o nome dele) é consistente. As mesmas coisas se aplicam ao backup de arquivos comuns, mas com bancos de dados, os riscos de corrupção de dados são provavelmente os mais altos.

Você tem poucas opções (esperamos que outras adicionem mais)

1. Descarregue o banco de dados e faça o backup do dump. Isso é o mais simples, seguro e direto.

2. Pare o banco de dados (ou use outro método para tornar os dados em disco consistentes) e faça o backup. (Desta forma, faz com que um longo tempo de inatividade, nem sempre é possível)

3. Pare o banco de dados (como em # 2), faça um snapshot (volume ou fs, verifique se o fs está consistente nesse ponto), inicie o banco de dados, monte o snapshot readonly e faça o backup. Mas nem todas as configurações são adequadas para isso.

4. Pare o banco de dados (como em # 2), faça um instantâneo (desta vez ele funciona apenas para volumes, verifique se o fs está consistente nesse ponto), inicie o banco de dados, faça backup do instantâneo como um bloco dispositivo. Isso pode aumentar o tamanho do backup e, novamente, pode não ser possível em todas as configurações.

5. Faça backup dos arquivos do banco de dados ao vivo e espere que funcione quando você restaurar. (Você está brincando com fogo aqui.) Se for possível, fique longe disso .

6. Se sua tecnologia tiver um meio especial de backup, use isso. (Como backup de captura instantânea direta de ELB para S3.)

De qualquer forma que você escolher, lembre-se de que você deve testar que você pode restaurar a partir do backup várias vezes, a partir de vários backups diferentes.

#!/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

    

Answer 2

The data size has reached the point where this process takes too much disk space and the file can't be uploaded to S3 in one shot.

Faça o upload de cada um como seus próprios arquivos separados. Provavelmente não é o caso de você estar fazendo algum tipo de desduplicação, e se você está mudando isso para ser baseado em referência seria útil.

So far backups have been done by dumping the entire MongoDB database

Existem ferramentas de backup incremental ( link ) para o MongoDB. Eu procuraria usá-los se sua carga de atualização fosse relativamente baixa.

Como você está no Digital Ocean, um backup local não é uma opção. É algo para se pensar estrategicamente, no entanto. Se você estivesse hospedado diretamente na Amazon, os instantâneos do sistema de arquivos para o S3 provavelmente seriam úteis para você.