Originalmente publicado no meu blog: http://eladnava.com/backing-up-your-amazon-s3-buckets-to-ec2/

Sincronizar o seu balde S3 para um servidor EC2 periodicamente

Isto pode ser facilmente conseguido utilizando vários utilitários de linha de comandos que permitem sincronizar um balde S3 remoto ao sistema de ficheiros local.

S3cmd
No início, parecia extremamente promissor. No entanto, depois de experimentá-lo no meu enorme balde S3 ... falhou a escala, errando com um Segmentation fault. Mas funcionou bem em baldes pequenos. Uma vez que não funcionou para baldes enormes, eu me propus encontrar uma alternativa.

S4cmd
A alternativa mais recente e multi-roscada para s3cmd. Parecia ainda mais promissor, no entanto, eu notei que ele continuou a baixar arquivos que já estavam presentes no sistema de arquivos local. Esse não é o tipo de comportamento que esperava do comando sync. Deverá verificar se o ficheiro remoto já existe localmente (a verificação do 'hash/filesize' seria simples) e ignorá-la na próxima sincronização, executada na mesma pasta de destino. Eu abri uma edição (bloomreach/s4cmd/ # 46 ) para relatar este comportamento estranho. Entretanto, decidi encontrar outra alternativa.

Awscli
E depois encontrei awscli Esta é a interface oficial de linha de comando da Amazon para interagir com seus diferentes serviços na nuvem, incluindo o S3.

Ele fornece uma sincronização útil comando que rápida e facilmente transfere os ficheiros de balde remotos para o seu sistema de ficheiros local .

$ aws s3 sync s3://your-bucket-name /home/ubuntu/s3/your-bucket-name/

Prestações:

• escalável-suporta enormes baldes S3
• multi - threaded-syncs the files faster by utilizing multiple threads
• só Smart sincroniza ficheiros novos ou actualizados
Rápido-graças à sua natureza multi-roscada e ao algoritmo de sincronização inteligente

Eliminação Acidental

Convenientemente, o comando não vai apagar os ficheiros na pasta de destino (Sistema de ficheiros local) se estiverem em falta na fonte (balde S3), e vice-versa. Isto é perfeito para fazer backup de S3 -- no caso de arquivos serem apagados do balde, re-sincronizando ele não irá apagá-los localmente. E no caso de você excluir um arquivo local, ele não será excluído do balde fonte também.

Instalação de awscli na Ubuntu 14.04 LTS

Vamos começar por instalar. Há várias maneiras de fazer isso, no entanto, descobri é mais fácil instalá-lo via apt-get.

$ sudo apt-get install awscli

Configuração

A seguir, precisamos de configurar awscli com a nossa chave de acesso ID & chave secreta, que você deve obter de IAM, criando um utilizador e anexando a Política de AmazonS3ReadOnlyAccess. Isso também irá impedir que você ou qualquer um que ganha acesso a estas credenciais de apagar seus arquivos S3. Certifique-se de entrar na sua região S3, como us-east-1.

$ aws configure

Preparação

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

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

Sincronização Inicial Vamos sincronizar o balde pela primeira vez com o seguinte comando:

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

Assumindo que o balde existe, as credenciais e a região do AWS estão correctas, e a pasta de destino é válida, awscli irá começar a transferir o balde inteiro para o sistema de ficheiros local.

Dependendo do tamanho do balde e da sua ligação à Internet, pode levar de alguns segundos a horas. Quando isso estiver feito, vamos em frente e configurar um trabalho de cron automático para manter a cópia local do balde atualizado.

A criar um posto de Cron

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

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

Copiar e colar o seguinte código para sync.sh:

#!/bin/sh

# Echo the current date and time

echo '-----------------------------'
date
echo '-----------------------------'
echo ''

# Echo script initialization
echo 'Syncing remote S3 bucket...'

# Actually run the sync command (replace {BUCKET_NAME} with your S3 bucket name)
/usr/bin/aws s3 sync s3://{BUCKET_NAME} /home/ubuntu/s3/{BUCKET_NAME}/

# Echo script completion
echo 'Sync complete'

Certifique-se que substitui {BUCKET_NAME} por o teu nome de balde S3, duas vezes no guião.

Dica Pro: deverá usar /usr/bin/aws para se ligar ao binário aws, dado que crontab executa comandos num ambiente de shell limitado e não será capaz de encontrar o executável sozinho.

A seguir, certifique-se de chmod o script para que possa ser executado por crontab.

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

Vamos tentar executar o script para garantir que ele realmente funciona.

$ /home/ubuntu/s3/sync.sh

A saída deve ser semelhante à isto:

A seguir, vamos editar o crontab do utilizador actual executando o seguinte comando:

$ crontab -e

Se esta for a sua primeira vez a executar crontab -e, terá de seleccionar um editor preferido. Eu recomendaria selecionar nano porque é o mais fácil para iniciantes trabalhar com.

Sincronia Frequência

Temos de dizer crontab com que frequência executamos o nosso script e onde o script reside no sistema de ficheiros local, escrevendo um comando. O formato para este comando é como se segue:

m h  dom mon dow   command

O comando a seguir configura crontab para executar o sync.sh script a cada hora (especificada através do minuto:0 e hora:* parâmetros) e canalizar a saída do script para um sync.log arquivo em nossas s3 diretório:

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

Deve adicionar esta linha ao fundo do ficheiro crontab que está a editar. Em seguida, vá em frente e salve o arquivo para o disco, pressionando Ctrl + W e depois Enter . Poderá então sair nano carregando em Ctrl + X . Agora vai executar a tarefa de sincronização a cada hora.

Dica Pro: poderá verificar se a tarefa horária cron está a ser executada com sucesso, inspeccionando /home/ubuntu/s3/sync.log, verificando o seu conteúdo para a data e hora de execução, e inspeccionando os registos para ver quais os ficheiros novos que foram sincronizados.

Tudo pronto! Seu balde S3 vai agora ser sincronizado para o seu servidor EC2 a cada hora automaticamente, e você deve estar pronto para ir. Observe que com o tempo, à medida que o seu balde S3 fica maior, você pode ter que aumentar o volume de EBS do seu servidor EC2 para acomodar novos arquivos. Pode sempre aumentar o seu volume de EBS seguindo este guia.

Tendo em conta a ligação relacionada, que explica que o S3 tem uma durabilidade de 99.999999999%, eu descartaria a tua preocupação #1. Seriamente.

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

• precisa de mais alguma das características de versionamento ou é apenas para evitar sobreposições/apagamentos acidentais?
• é o custo adicional imposto pela versão acessível?
• Pode ser assim?

A não ser que o teu armazenamento seja enorme, eu ficava-me pela versionação do balde. Desta forma, você não vai precisar de nenhum código/fluxo de trabalho extra para backup de dados para geleira, para outros baldes, ou até mesmo para qualquer outro servidor (o que é realmente uma má escolha IMHO, por favor esqueça isso).

Seria de esperar que houvesse uma forma mais fácil de manter algum tipo de backups incrementais numa região de diferenças.

Todas as sugestões acima não são realmente soluções simples ou elegantes. Eu realmente não considero geleira uma opção, pois eu acho que isso é mais de uma solução de arquivo, em seguida, uma solução de backup. Quando eu penso backup eu acho que a recuperação de desastre de um desenvolvedor júnior recursivamente excluir um balde ou talvez um exploit ou bug em seu aplicativo que apaga coisas de s3.

Para mim, a melhor solução seria um script que apenas faz um balde para outra região, um diário e um semanal para que, se algo terrível acontecer, você possa simplesmente mudar de regiões. Eu não tenho uma configuração como esta, eu olhei apenas para não ter chegado em torno de fazê-lo, porque seria necessário um pouco de esforço para fazer isso, e é por isso que eu gostaria que houvesse alguma solução de estoque para usar.

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

1. Escalonar o processo de cópia de segurança usando a linha de dados AWS, pode ser feito de duas formas mencionadas abaixo:

   A. Usando a copyActivity of datapipeline usando a qual pode copiar de um balde s3 para outro balde s3.

   B. Usando a ShellActivity dos comandos datapipeline e "S3distcp" para fazer a cópia recursiva das pastas recursivas S3 do balde para outro (em paralelo).

2. Usar o versionamento dentro do balde S3 para manter uma versão diferente de dados

3. Use glacier backup de seus dados ( use-a quando você não precisa restaurar a cópia de segurança rápida para o original baldes(demora algum tempo para voltar os dados da geleira como os dados são armazenados em formato comprimido) ou quando você quiser economizar algum custo, evitando usar outro bucket s3 fro cópia de segurança), esta opção pode ser facilmente definida usando a regra de ciclo de vida sobre o bucket s3 fro que você deseja utilizar copia.

A Opção 1 pode dar-lhe mais segurança, digamos que, no caso de apagar acidentalmente o seu balde s3 original e outro benefício é que você pode armazenar o seu backup em pastas de trechos de dados em outro balde s3, desta forma você sabe quais os dados que você tinha em uma determinada data e pode restaurar uma cópia de segurança de data específica . Tudo depende do caso de uso.

Que tal usar a replicação de região cruzada Disponível nos próprios baldes S3? Aqui estão alguns artigos úteis sobre a funcionalidade

• https://aws.amazon.com/blogs/aws/new-cross-region-replication-for-amazon-s3/
• http://docs.aws.amazon.com/AmazonS3/latest/UG/cross-region-replication.html

Enquanto esta questão foi publicada há algum tempo, achei importante mencionar a protecção MFA delete com as outras soluções. O OP está tentando resolver para a eliminação acidental de dados . A autenticação multi-factor (MFA) manifesta - se em dois cenários diferentes aqui -

1. Apagar permanentemente as versões do objecto-activar a remoção MFA no versionamento do balde.

2. Apagar acidentalmente o balde em si-configurar uma política de balde negar a remoção sem autenticação MFA.

Par com replicação interregional e versionamento para reduzir o risco de perda de dados e melhorar os cenários de recuperação.

Aqui está um post no blog sobre este tópico com mais detalhes.