Método para backup externo de servidores EC2?

Question

Nós executamos cerca de uma dúzia de instâncias de produção de servidores web Ubuntu Linux no Amazon VPC. As instâncias são inicializadas e gerenciadas via Puppet. A maioria dos gerenciamentos é feita por meio do AWS Console.

Nossas credenciais da AWS são bastante seguras. A conta principal quase nunca é necessária, tem uma senha strong e uma autenticação de dois fatores. Alguns administradores confiáveis têm acesso à maioria dos serviços por meio de suas próprias contas do IAM, também com senhas strongs e autenticação de dois fatores. Algumas contas do IAM têm acesso muito limitado para fins específicos, como gravar arquivos no S3. O acesso de outros funcionários a quaisquer credenciais de alto nível é muito limitado. No geral, a chance de alguém ter acesso ao console ou à API parece baixa.

O recente Debacle do , onde alguém ganhou acesso de alto nível ao AWS Console e excluiu instâncias, volumes e EBS Snapshots, impedindo efetivamente que os espaços de código recuperassem seus negócios. investigar métodos de backup de nossos dados off-line / offsite (ou seja, fora do alcance de nossa conta principal da AWS).

Como posso garantir que os dados de nossos clientes não sejam eliminados por alguém que obtenha acesso às nossas credenciais da AWS ou por algum desastre na AWS? Deve ser automático, estável e com preços razoáveis.

Parece que não consigo encontrar um caminho 'fácil' depois de pesquisar por algumas horas. Copiar os instantâneos do EBS para outra conta da AWS não parece possível. Não consigo exportar instantâneos do EBS para objetos do S3. Eu poderia rsync todos os dados importantes, puxando de um servidor de terceiros, mas eu preciso script para lidar com coisas como vários números de servidores, retenção, tratamento de erros, etc. Parece muito trabalho. Não encontrei nenhum software pronto para isso.

Nossa estratégia de backup atual consiste em snapshots automatizados do EBS de todos os volumes, assim como upload de MySQLdumps comprimidos para o S3. Todo o código-fonte e o código Puppet são implantados a partir do controle de versão externo, mas os arquivos de nossos clientes e bancos de dados MySQL são armazenados somente nos volumes do EBS e em seus instantâneos, ou seja, insider o ecossistema da AWS.

    

Answer 1

Muitas pessoas tendem a pensar demais nisso. Basta pensar nesses servidores como se eles fossem implantados em uma colo ou em um datacenter corporativo. Nesse caso, como você os apoiaria?

Provavelmente seria por meio de um produto de backup "legado" (Netbackup, Amanda, BareOS etc.) conectado a uma biblioteca de fitas ou VTL.

Isso é algo que você deve considerar fazer em sua infraestrutura da AWS. Crie um servidor de backup e uma biblioteca de fitas fora do amazon em algum lugar e use isso como seu método de restauração "doomsday".

A fita é um dos mecanismos de armazenamento de dados mais confiáveis e, ao contrário de todos os outros sistemas de backup na nuvem, não é vulnerável ao tipo de coisa que aconteceu com o CodeSpaces. Seus dados de backup são verdadeiramente off-line, e você pode manter as fitas no local mais seguro que você escolher - desde um cofre no escritório até o aluguel de um cofre no banco local. Obter esse tipo de proteção contra um provedor de armazenamento em nuvem é impossível.

Você já tem o gerenciamento de configuração em vigor. (Yay!) Assim, no caso de um desastre, você poderá reconstruir seus servidores de maneira razoavelmente rápida, de modo que o backup em fita (ou VTL) será principalmente para seus dados . Bancos de dados, arquivos enviados, etc. Coisas que não são cobertas pelo seu fantoche manifesta.

Se isso não for uma opção, a melhor coisa a seguir seria criar uma conta da AWS completamente separada para fins de backup. Dentro dessa conta, crie credenciais do IAM para o S3 que tenham permissões somente de upload e, em seguida, use-as no seu ambiente de produção para enviar backups. Certifique-se de que essas credenciais sejam mantidas em um local completamente separado das suas credenciais de produção para limitar a possibilidade de que ambas sejam comprometidas ao mesmo tempo.