Estratégias de backup para bucket AWS S3


94

Estou procurando algum conselho ou prática recomendada para fazer backup do bucket S3.
O objetivo de fazer backup dos dados do S3 é evitar a perda de dados devido ao seguinte:

  1. Problema S3
  2. problema em que excluo acidentalmente esses dados do S3

Após alguma investigação, vejo as seguintes opções:

  1. Use versionamento http://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
  2. Copie de um bucket S3 para outro usando AWS SDK
  3. Backup para Amazon Glacier http://aws.amazon.com/en/glacier/
  4. Backup para o servidor de produção, que é o próprio backup

Que opção devo escolher e quão seguro seria armazenar dados apenas no S3? Quer ouvir suas opiniões.
Alguns links úteis:


Respostas:


65

Postado originalmente em meu blog: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

Sincronize seu Bucket S3 com um servidor EC2 periodicamente

Isso pode ser feito facilmente utilizando vários utilitários de linha de comando que tornam possível sincronizar um depósito S3 remoto com o sistema de arquivos local.

s3cmd
No início, s3cmdparecia extremamente promissor. No entanto, depois de experimentá-lo em meu enorme balde S3 - não conseguiu escalar, apresentando um erro Segmentation fault. Funcionou bem em baldes pequenos, no entanto. Como não funcionava para baldes enormes, decidi encontrar uma alternativa.

s4cmd
A alternativa multi-threaded mais recente para s3cmd. Parecia ainda mais promissor, no entanto, notei que ele continuou baixando arquivos que já estavam presentes no sistema de arquivos local. Esse não é o tipo de comportamento que eu esperava do comando sync. Ele deve verificar se o arquivo remoto já existe localmente (a verificação de hash / tamanho do arquivo seria legal) e ignorá-lo na próxima execução de sincronização no mesmo diretório de destino. Abri um problema ( bloomreach / s4cmd / # 46 ) para relatar esse comportamento estranho. Nesse ínterim, comecei a encontrar outra alternativa.

awscli
E então eu encontrei awscli. Esta é a interface de linha de comando oficial da Amazon para interagir com seus diferentes serviços em nuvem, S3 incluído.

AWSCLI

Ele fornece um comando de sincronização útil que baixa de forma rápida e fácil os arquivos de bucket remoto para seu sistema de arquivos local .

$ aws s3 sync s3: // nome-do-seu-balde / home / ubuntu / s3 / nome-do-seu-balde /

Benefícios:

  • Escalável - suporta enormes baldes S3
  • Multi-threaded - sincroniza os arquivos mais rápido, utilizando vários threads
  • Inteligente - sincroniza apenas arquivos novos ou atualizados
  • Rápido - graças à sua natureza multithread e algoritmo de sincronização inteligente

Exclusão acidental

Convenientemente, o synccomando não excluirá os arquivos da pasta de destino (sistema de arquivos local) se eles estiverem faltando na origem (depósito S3) e vice-versa. Isso é perfeito para fazer backup do S3 - no caso de arquivos serem excluídos do depósito, sincronizá-los novamente não os excluirá localmente. E, no caso de você excluir um arquivo local, ele também não será excluído do intervalo de origem.

Configurando o awscli no Ubuntu 14.04 LTS

Vamos começar instalando awscli. Existem várias maneiras de fazer isso, no entanto, achei mais fácil instalá-lo via apt-get.

$ sudo apt-get install awscli

Configuração

Em seguida, precisamos configurar awsclicom nosso ID de chave de acesso e chave secreta, que você deve obter do IAM , criando um usuário e anexando a política AmazonS3ReadOnlyAccess . Isso também impedirá que você ou qualquer pessoa que tenha acesso a essas credenciais exclua seus arquivos S3. Certifique-se de inserir sua região S3, como us-east-1.

$ aws configurar

aws configure

Preparação

Vamos preparar o diretório de backup local do S3, de preferência em /home/ubuntu/s3/{BUCKET_NAME}. Certifique-se de substituir {BUCKET_NAME}pelo nome real do seu intervalo.

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

Sincronização inicial

Vamos sincronizar o intervalo pela primeira vez com o seguinte comando:

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

Supondo que o depósito exista, as credenciais e a região da AWS estão corretas e a pasta de destino válida, awsclio download de todo o depósito será iniciado no sistema de arquivos local.

Dependendo do tamanho do balde e de sua conexão com a Internet, pode levar de alguns segundos a horas. Quando isso for feito, iremos em frente e configuraremos um cron job automático para manter a cópia local do bucket atualizada.

Configurando um Cron Job

Vá em frente e crie um sync.sharquivo em /home/ubuntu/s3:

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

Copie e cole o seguinte código em sync.sh:

#! / bin / sh

# Ecoar a data e hora atuais

echo '-----------------------------'
encontro
echo '-----------------------------'
echo ''

# Inicialização de script de eco
echo 'Sincronizando bucket S3 remoto ...'

# Realmente execute o comando de sincronização (substitua {BUCKET_NAME} pelo nome do seu intervalo S3)
/ usr / bin / aws s3 sync s3: // {BUCKET_NAME} / home / ubuntu / s3 / {BUCKET_NAME} /

# Conclusão do script de eco
echo 'Sincronização completa'

Certifique-se de substituir {BUCKET_NAME} pelo nome do seu intervalo S3, duas vezes ao longo do script.

Dica profissional: você deve usar o /usr/bin/awslink para o awsbinário, pois crontabexecuta comandos em um ambiente de shell limitado e não será capaz de encontrar o executável por conta própria.

Em seguida, verifique chmodo script para que ele possa ser executado por crontab.

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

Vamos tentar executar o script para verificar se ele realmente funciona:

$ /home/ubuntu/s3/sync.sh

A saída deve ser semelhante a esta:

saída sync.sh

A seguir, vamos editar o usuário atual crontabexecutando o seguinte comando:

$ crontab -e

Se esta for sua primeira execução crontab -e, você precisará selecionar um editor de sua preferência. Eu recomendo selecionar nanoporque é o mais fácil para iniciantes trabalharem.

Frequência de Sincronização

Precisamos dizer com crontabque freqüência executar nosso script e onde o script reside no sistema de arquivos local, escrevendo um comando. O formato deste comando é o seguinte:

mh dom mon dow comando

O comando a seguir é configurado crontabpara executar o sync.shscript a cada hora (especificado por meio dos parâmetros minuto: 0 e hora: *) e para que ele canalize a saída do script para um sync.logarquivo em nosso s3diretório:

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

Você deve adicionar esta linha ao final do crontabarquivo que está editando. Em seguida, salve o arquivo no disco pressionando Ctrl + W e depois Enter . Você pode então sair nanopressionando Ctrl + X . crontabirá agora executar a tarefa de sincronização a cada hora.

Dica profissional: você pode verificar se o cron job de hora em hora está sendo executado com sucesso inspecionando /home/ubuntu/s3/sync.log, verificando seu conteúdo para a data e hora de execução e inspecionando os logs para ver quais novos arquivos foram sincronizados.

Tudo pronto! Seu bucket S3 agora será sincronizado com seu servidor EC2 a cada hora automaticamente e você deve estar pronto para ir. Observe que, com o tempo, conforme seu balde S3 fica maior, pode ser necessário aumentar o tamanho do volume EBS do servidor EC2 para acomodar novos arquivos. Você sempre pode aumentar o tamanho do volume EBS seguindo este guia .


Deixei uma pergunta no seu blog, mas gostaria de saber se existe uma maneira de sincronizar os metadados também.
Devology Ltd de

@Devology Ltd, Infelizmente não tive a chance de trabalhar com metadados de objetos S3. A partir de uma rápida pesquisa no Google, não parece que o awsclisuporte sincronizar isso automaticamente no aws s3 synccomando. Parece que você precisa implementar isso manualmente.
Elad Nava de

Obrigado @Ekad Nava - Agradeço a confirmação do que eu acreditava ser o caso.
Devology Ltd de

1
Isso é fantástico, @EladNava, obrigado por compartilhar, ainda relevante em 2020!
user1130176

esta resposta não se encaixa, quando você tem milhões de arquivos nela. Torna-se muito caro, lento e às vezes impossível - por causa dos limites do sistema de arquivos.
Psicozóico

31

Levando em consideração o link relacionado, que explica que o S3 tem durabilidade de 99,999999999%, descartaria sua preocupação nº 1. A sério.

Agora, se o # 2 é um caso de uso válido e uma preocupação real para você, eu definitivamente ficaria com as opções # 1 ou # 3. Qual deles? Realmente depende de algumas questões:

  • Você precisa de algum outro recurso de controle de versão ou é apenas para evitar sobrescrições / exclusões acidentais?
  • O custo extra imposto pelo controle de versão é acessível?
  • Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. Isso é bom para você?

A menos que seu uso de armazenamento seja realmente grande, eu continuaria com o controle de versão do balde. Dessa forma, você não precisará de nenhum código / fluxo de trabalho extra para fazer backup dos dados no Glacier, em outros baldes ou mesmo em qualquer outro servidor (o que é realmente uma má escolha, IMHO, por favor, esqueça).


4
@SergeyAlekseev Se o Glacier for algo que funcionará para você, é muito rápido configurar uma regra de ciclo de vida em um balde que arquiva automaticamente seus arquivos no glacier. Eles ainda aparecerão em um balde (na IU da web), mas a classe de armazenamento mudará de padrão para geleira. Eu movo os arquivos processados ​​do meu intervalo principal para um intervalo "concluído", e o intervalo concluído tem a regra de ciclo de vida que arquiva qualquer coisa com mais de 1 dia. Esses são arquivos de dados que provavelmente nunca tocarei novamente, mas preciso manter para o cliente.
Dan

28
Não acho que 99,999999999% seja uma razão boa o suficiente para estar totalmente cheio de erros de armazenamento / backup. Não estou falando sobre 0,0000000001% restante, mas mais se algo altamente inesperado acontecer, será estranho ter todo o seu negócio em algum lugar. De forma inesperada, poderia ser EUA entrando em guerra com um país específico, Amazon sendo completamente hackeado (cf. Sony), etc. etc.
Augustin Riedinger

11
Voltarei a @AugustinRiedinger neste caso: "Problema S3" pode ser, por definição, algo que você não conhece (por exemplo, questões governamentais) que podem invalidar as hipóteses nas quais os números SLA S3 como 99,99 ... são baseados. Ao fazer qualquer coisa de longo prazo, incluindo backup de seus dados, a diversificação é uma boa prática, se não deveria ser um pré
lajarre

2
Eu definitivamente concordo que seus pontos são válidos. Mas, com base nas opções fornecidas pelo OP (quase todas incluindo alternativas AWS para o problema), não acho que o "problema S3" seria tão amplo quanto vocês estão expandindo. É bom ver alguns pensamentos mais amplos, no entanto.
Viccari

4
Resposta antiga, mas sinto que preciso mencionar eventos recentes (-ish). "No dia em que a Amazon quebrou a web", um técnico excluiu acidentalmente uma grande parte de seus servidores S3. Mesmo nessas 24 horas, o problema era a acessibilidade. Não perda de dados. Não houve absolutamente nenhuma perda de dados, mesmo considerando a grande quantidade de servidores sendo removidos, e eles ainda conseguiram cumprir seu SLA
Oberst

14

Você pode fazer backup de seus dados S3 usando os seguintes métodos

  1. Agende o processo de backup usando o datapipeline da AWS, ele pode ser feito das 2 maneiras mencionadas abaixo:

    uma. Usando copyActivity de datapipeline usando o qual você pode copiar de um balde s3 para outro balde s3.

    b. Usando ShellActivity de datapipeline e comandos "S3distcp" para fazer a cópia recursiva de pastas s3 recursivas de um depósito para outro (em paralelo).

  2. Use o controle de versão dentro do intervalo S3 para manter versões diferentes dos dados

  3. Use o glacier para fazer backup de seus dados (use-o quando não precisar restaurar o backup rapidamente para os baldes originais (leva algum tempo para recuperar os dados do glacier, pois os dados são armazenados em formato compactado) ou quando quiser salvar algum custo, evitando o uso de outro depósito s3 para backup), esta opção pode ser facilmente definida usando a regra de ciclo de vida no depósito s3 para o qual você deseja fazer backup.

A opção 1 pode dar a você mais segurança, digamos, no caso de você excluir acidentalmente seu bucket s3 original e outro benefício é que você pode armazenar seu backup em pastas de data e hora em outro bucket s3, desta forma você sabe quais dados tinha em uma data específica e pode restaurar um backup de data específica. Tudo depende do seu caso de uso.


@David: Como David sugeriu em sua solução abaixo, que poderia haver um script que faz backup do balde s3 diariamente ou semanalmente. Isso pode ser facilmente alcançado pelo meu primeiro ponto (linha de dados AWS - que dá a você a capacidade de agendar o processo de backup - diariamente , semanalmente etc.). Eu recomendaria dar uma olhada na linha de dados do aws.
Varun

Isso é promissor, porque não depende de abordagens obsoletas que não se destacam em aproveitar ao máximo a nuvem (leia: crons). O Data Pipeline também tem novas tentativas automatizadas e é um serviço gerenciado (sem servidor).
Felipe Alvarez

13

Que tal usar o recurso de replicação entre regiões prontamente disponível nos próprios buckets S3? Aqui estão alguns artigos úteis sobre o recurso


E se você excluir um arquivo em uma região e não puder ser replicado na outra?
michelem

S3 não replica exclusões, verifique este link docs.aws.amazon.com/AmazonS3/latest/dev/… .
ᐅ devrimbaris

9

Você pensaria que haveria uma maneira mais fácil agora de apenas manter algum tipo de backups incrementais em uma região diff.

Todas as sugestões acima não são soluções realmente simples ou elegantes. Eu realmente não considero o glacier uma opção, pois acho que é mais uma solução de arquivamento do que uma solução de backup. Quando penso em backup, penso em recuperação de desastre de um desenvolvedor júnior excluindo recursivamente um balde ou talvez um exploit ou bug em seu aplicativo que exclui coisas do s3.

Para mim, a melhor solução seria um script que apenas faça backup de um balde para outra região, um diário e um semanal para que, se algo terrível acontecer, você possa apenas trocar de região. Eu não tenho uma configuração como esta, eu pesquisei apenas não consegui fazer isso porque seria um pouco de esforço para fazer isso, é por isso que eu gostaria que houvesse alguma solução padrão para usar.


Acordado. É interessante quando você se aprofunda no S3 (mesmo no CRR - replicação embutida), há grandes buracos para a recuperação de desastres. Você não pode, por exemplo, jamais restaurar um depósito, os históricos de versão de arquivo, os metadados (esp as datas da última modificação), etc. Todos os cenários de recuperação disponíveis atualmente são recuperações parciais.
Paul Jowett

7

Embora essa pergunta tenha sido postada há algum tempo, achei importante mencionar a proteção contra exclusão do MFA com as outras soluções. O OP está tentando solucionar a exclusão acidental de dados. A autenticação multifator (MFA) se manifesta em dois cenários diferentes aqui -

  1. Excluindo versões de objeto permanentemente - Habilite a exclusão de MFA no controle de versão do bucket.

  2. Excluindo acidentalmente o próprio balde - Configure uma política de balde negando a exclusão sem autenticação MFA.

Casal com -se a replicação e controle de versão entre regiões para reduzir o risco de perda de dados e melhorar os cenários de recuperação.

Aqui está uma postagem de blog sobre este tópico com mais detalhes.


0

Se, temos muitos dados. Se você já tem um balde, então da primeira vez A sincronização vai demorar muito, no meu caso, eu tinha 400GB. Demorou 3 horas na primeira vez. Portanto, acho que podemos fazer a réplica é uma boa solução para backup do S3 Bucket.


Estou prestes a mover cerca de 7 TB para um balde e estou tentando descobrir a melhor opção ... Estou pensando que preciso de algo melhor do que sincronizar. Estou me perguntando se usar um pipeline para copiar dados para a versão GCS do glacier pode oferecer a melhor segurança geral?
Brendon Whateley

O AWS DataSync pode ser uma opção aqui.
Felipe Alvarez
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.