Como escolher um serviço de nuvem para backups

Estou pensando em usar um serviço de nuvem para fazer backup de um site do meu cliente.

Minhas principais preocupações (clientes) são (em ordem decrescente de importância)

1. Proteção de IP (segredos comerciais, código fonte), detalhes da conta do usuário etc.
2. Garantia de tempo de atividade oferecida pelo provedor de serviços (para minimizar os tempos de inatividade do servidor da web)
3. Custo
4. Velocidades de upload / download

Idealmente, eu gostaria de um serviço que não tenha uma longa ligação (ou seja, eu preferiria um tipo de serviço "pré-pago")

Eu também gostaria de evitar o bloqueio do fornecedor, onde é quase impossível mudar para outro serviço.

Eu gostaria de algumas diretrizes gerais sobre:

1. Como escolher um provedor de serviços
2. Quem são os principais jogadores em campo
3. recomendação de software a ser usado para: backup / restauração / e upload / download dos arquivos salvos / restaurados

O software para servidor será o Ubuntu ou o Debian (provavelmente postarei uma pergunta em qual SO usar como servidor - eu já estou familiarizado com o Ubuntu)

Qualquer solução que não inclua criptografia no lado do cliente com chaves mantidas pelo proprietário não atenderá ao primeiro requisito declarado (proteção / segurança IP) - qualquer invasão no lado do servidor divulga dados não criptografados. Isso exclui sistemas de sincronização em nuvem, como o Dropbox, que possui as chaves.

Para evitar a hospedagem das chaves de criptografia importantes no servidor do site, que provavelmente também serão invadidas em algum momento, eis o que eu faria:

1. Servidor de backup interno no site do cliente - possui chaves de criptografia e chaves SSH para os outros dois servidores
2. Servidor que hospeda o site - pode ser um host
3. Servidor ou serviço de backup em nuvem

Etapa 1: o servidor (1) obtém o backup de (2), para que a maioria dos hacks do servidor do site não comprometa os backups. A criptografia ocorre neste momento.

• Eu usaria o rsnapshot sobre SSH usando login baseado em chave, pois isso tem requisitos mínimos no host da web e no servidor de backup interno - a menos que você tenha um banco de dados grande para fazer backup, ele é muito eficiente na largura de banda e armazena várias versões do site, e também lida com a remoção de backups antigos.
• A criptografia pode ser feita por qualquer ferramenta de arquivo para arquivo, como GPG, copiando a árvore rsnapshot para outra árvore - ou você pode usar a duplicidade na etapa 2, economizando espaço em disco.
• O "pull" do servidor de backup é importante - se o servidor principal (2) tiver as senhas / chaves do servidor de backup, os hackers poderão e algumas vezes excluirão os backups após invadir o servidor principal (veja abaixo). Os hacks realmente avançados podem instalar binários SSH trojanados que podem comprometer o servidor de backup, mas isso é menos provável para a maioria das empresas.

Etapa 2: o servidor (1) envia os backups criptografados para (3) para que haja um backup externo. Se os backups foram criptografados na etapa 1, você pode usar apenas um espelho rsync da árvore rsnapshot local no sistema remoto.

• A duplicidade seria uma boa opção para criptografar e fazer backup diretamente da árvore rsnapshot não criptografada no servidor remoto. Os recursos do Duplicity são um pouco diferentes do rsnapshot, usando arquivos tar criptografados por GPG, mas fornece criptografia de backup no host remoto e requer apenas SSH nesse host (ou pode usar o Amazon S3). A duplicidade não suporta links físicos , portanto, se isso for necessário (por exemplo, para um backup completo do servidor), é melhor que um script converta a árvore rsnapshot (que suporta links físicos) em um arquivo tar (talvez apenas os arquivos que possuem> 1 link físico, que será bem pequeno) para que a duplicidade possa fazer backup do arquivo tar.
• Como o servidor remoto é apenas um host SSH, possivelmente com rsync, pode ser um host da web (mas de um provedor de hospedagem diferente e em uma parte diferente do país) ou um serviço em nuvem que fornece rsync e / ou SSH - consulte esta resposta em backups rsync na nuvem por sua recomendação de bqbackup e rsync.net, embora eu não concorde com a configuração de backup mencionada.
• Você pode usar o Amazon S3 como servidor remoto com duplicidade, o que forneceria uma disponibilidade realmente boa, embora talvez custasse mais para backups grandes.
• Outras opções para backups criptografados remotos são Boxbackup (não tão maduro, alguns recursos interessantes) e Tarsnap (serviço de nuvem comercial baseado no Amazon S3 com interface de linha de comando simples, boa desduplicação e criptografia completa).
  • O JungleDisk pode ser uma opção, mas eu não tive uma grande experiência com eles no passado e sua criptografia tem alguns problemas (do autor do Tarsnap).

A segurança de todos os vários hosts é importante, portanto, isso deve ser ajustado para atender ao perfil de segurança do cliente, ou seja, analisar ameaças, riscos, vetores de ataque etc. O Ubuntu Server não é um começo ruim, pois possui atualizações de segurança frequentes para 5 anos, mas é necessária atenção à segurança em todos os servidores.

Essa configuração fornece dois backups independentes, um dos quais pode ser um serviço de armazenamento em nuvem altamente disponível, opera no modo pull, para que a maioria dos ataques no site não possa destruir os backups ao mesmo tempo, e usa ferramentas de código aberto comprovadas que não o fazem requer muita administração.

• Os backups independentes são críticos, porque os hackers às vezes excluem todos os backups ao mesmo tempo que invadiram o site - no caso mais recente, os hackers destruíram 4800 sites, incluindo backups invadindo o ambiente de hospedagem da Web, e não os sites. Veja também esta resposta e esta .
• A restauração é muito fácil com o rsnapshot - há um arquivo em cada árvore de instantâneo para cada arquivo copiado em backup, então encontre os arquivos com as ferramentas do Linux e rsync ou scp-os de volta ao site. Se o servidor de backup no local não estiver disponível por algum motivo, basta usar a duplicidade para restaurá-lo a partir do servidor de backup na nuvem - ou você pode usar ferramentas padrão como GPG, rdiff e tar para restaurar os backups.

Como essa configuração usa SSH e rsync padrão, deve ser mais fácil escolher um provedor adequado com garantias de tempo de atividade, segurança forte etc. Você não precisa se comprometer com um contrato longo e se o serviço de backup for catastrófico falha, você ainda tem um backup local e pode alternar para outro serviço de backup com bastante facilidade.

Em termos de software, considere a duplicidade para backups incrementais com criptografia assimétrica e um receptor estúpido ( instruções não relacionadas à nuvem ).

Eu sempre digo aos meus clientes que a melhor, mais barata e eficiente solução de backup é aquela que você constrói para seus próprios propósitos.

Quando crio um sistema para meus clientes, uso o rsync com chaves SSH para lidar com a autenticação entre o servidorA e o servidorB, onde o servidorA contém os dados a serem copiados. O comando para arquivar e rsync os dados está contido em um script bash em um diretório não acessível pela Web, chamado pelo cron a cada H horas (24 por dia, etc. etc.)

O servidor de backup, serverB, deve ser usado SOMENTE para backups. Eu sempre aconselho meus clientes a usar uma senha extremamente longa com autenticação de chave SSH para permitir o download de backups e o backup. Às vezes, meus clientes precisam que os backups sejam salvos por dias D, então escrevo alguns scripts para lidar com isso (pegue dados do diretório de backup ativo, aplique um carimbo de data e hora, adicione a um arquivo em outro diretório).

Para pequenas empresas / prosumer, eu recomendaria o Serviço de Armazenamento da Amazon .

• Controle de região (ou seja, objetos armazenados em uma UE nunca saem da UE).
• 99,9% de tempo de atividade para qualquer ciclo de cobrança
• US $ 0,150 por GB armazenado por mês
• US $ 0,170 por GB baixado
• Upload gratuito até junho de 2010, US $ 0,10 por GB a partir de então

E a garantia bastante vaga de que "os mecanismos de autenticação são fornecidos para garantir que os dados sejam mantidos protegidos contra acesso não autorizado"

Enquanto bluenovember está no caminho certo com o S3, o sistema da Amazon não é realmente uma solução de backup drop-in, é uma solução de armazenamento de dados brutos que ainda exige que um sistema front-end seja usado para backup, sejam algumas chamadas de API ou um suíte de gerenciamento de backup completo. Algo como o JungleDisk Server Edition , que usa o S3 no back-end, mas fornece uma interface melhor para o uso como solução de backup, provavelmente seria melhor.

Além disso, o JungleDisk oferece criptografia embutida, algo que você precisa adicionar independentemente de como planeja se conectar ao S3 / "nuvem". Eles também têm alguns softwares de cliente bastante agradáveis ​​para Linux.

Gosto de armazenar meu backup no Amazon AWS e uso a ferramenta gratuita s3cmd ( http://s3tools.org/s3cmd )

Pode ser instalado facilmente (Debian: apt-get install s3cmd).

Tudo o que você precisa de uma conta Amazon AWS para armazenar seus arquivos no S3. Então, um comando simples pode executar seu backup, mesmo incremental ou como uma solução de sincronização, por exemplo:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

Certifique-se de executar

s3cms --configure 

primeiro a inserir suas credenciais da AWS.