Olá a todos!

Conforme havia prometido na semana passada, hoje vou abordar o tema de testes de restore de dados que estejam em providers publicos de cloud.
Não apenas quando se implementa, mas sempre e em intervalos regulares.

Como os que seguem o meu blog sabem, tenho no meu homelab diferentes versões de diferentes plataformas, onde teste ideias e procedimentos antes de os propor a Clientes finais.
Este tipo de procedimento faz que consiga sempre propor ao Cliente as soluções que  comprovadamente melhor se adequam a sua situação de uma forma testada e documentada.

O problema com isto, é que se geram TB e TB de ambientes que são usados 4 ou 5 vezes por ano, e que em boa da verdade são pesos mortos enquanto não estão a ser usados.

Para sanar este meu problema de ocupação, utilizo a Amazon Cloud Drive.

Sim, podem-me perguntar desde os últimos posts porque não utilizo o spacewalk para construir os laboratórios quando necessito deles, e a resposta é simples: Existem muitas nuances em cada um para que seja prático construir um script que os provisione automaticamente a todos, alem das configurações e instalações de firewalls e balanceadores por software que não conseguem ser provisionados desde um spacewalk.

Voltando ao tema do post, para manter todos estes laboratórios seguros e privados, os backups são feitos de forma fortemente encriptada utilizado para isso o duplicity.

O duplicity é um software que se descreve como:

Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.

The duplicity package also includes the rdiffdir utility. Rdiffdir is an extension of librsync’s rdiff to directories—it can be used to produce signatures and deltas of directories as well as regular files. These signatures and deltas are in GNU tar format.

Em si, o duplicity efetua a gestão de backups, encriptando eles em tempo real e enviado para o cloud provider que tenhamos (e que seja suportado).
Nota: O duplicity utiliza backends para cada um dos serviços. Para o serviço em questão o backup é efetuado usado as API’s da Amazon em conjunto com o cliente acd_cli.

… o que nos trás de novo ao tópico do artigo de hoje.

Um dos meus laboratórios, chamado RCLONE009, composto por 8 vm’s, 1 firewall, 1 loadbalancer, 4 LXC containers e uma vsan é dos mais usados.
Embora não tenha uma utilização muito intensiva em termos de processos, é das que mais atualizações de software leva, por replicar um site/app de CRM exposto a internet.

Todo o laboratório (com dados fictícios para simular a utilização do produto) anda perto dos 2TB em espaço útil, mas se fizermos delta dos pacotes atualizados em 6 meses, temos uma utilização de perto de 3,5TB.

Pior, todas estas atualizações são atómicas por intenção, ou seja, em cada backup diferencial que o duplicity faça, ele gera um novo delta de diferenças que guarda indexado a data.
Todas estas diferenças são armazenadas, por já ter existido alturas em que me perguntaram como seria o comportamento se fosse com o patch de versão anterior, ou se o problema se manifestava ANTES do patch de um mês atrás.

Infelizmente, isto criou um problema para o duplicity que eu nunca me havia apercebido até ter tentado fazer um full restore do ambiente e do seu diferencial.
Todos os testes de restore que foram feitos, foram na altura do full e nunca houve necessidade de testar diferenciais com mais de 1 mês de diferença do full – não esquecer que para todos os efeitos o comportamento que pretendo é de arquivo.

E eis que a dor começou:

Com todas as alterações que o ambiente sofreu, os deltas totalizavam 2407.
O duplicity a tentar extrair dados, só a ler o catalogo, num storage que dá mais de 300MB/S em sustained rate de leitura, com um X5670, a funcionar com 16 cores para o processo, demorou perto de 86 horas só para concluir.

Em seguida, o processo de duplicity estranhamente morre.

Tenho estado a tentar junto da mailing list do duplicity entender o que se está a passar, mas pelo que já entendi é um problema recorrente quando estão envolvidos muitos diffs versus poucos full backups (que é o meu caso).
Existe ainda a séria suspeita (vide reddit/r/datahoarder e reddit/r/homelab) que possam ocorrer corrupções (bit rot) de dados na Amazon.

O que já eliminei:

• Versões desatualizadas: Tanto o acd_cli como o duplicity estão nas ultimas versões de produção existentes.
• Corrupção no transporte: Existem reportados casos onde o transporte da amazon para o cliente é corrompido. Para eliminar esta variável da equação, fiz uma copia integral do backup da Amazon para um diretório numa LUN da minha SAN, comparei os MD5SUM’s dos ficheiros que enviei, para o MD5SUM dos ficheiros que descarreguei (vi que coincidiam) e comecei de novo a reprocessar os dados.

Estou neste momento a meio do reprocessamento e assim que tiver mais informações reportarei, mas tudo aponta que a complexidade do processo, versus estar a ser corrido em stream de uma public cloud, pode ter algo a ver com a dificuldade.
No pior dos casos irei ter uma reconstrução de laboratório 🙂

O que já conclui com este processo?

• Que não posso confiar no duplicity para restores rápidos quando o que vai ser restaurado é demasiado complexo. Vou testar após esta crise o rlcone (que suporta igualmente encriptação) e tem uma comunidade de desenvolvimento e suporte bem mais ativa, e pelo que tenho visto é extremamente mais rápido.
• Que tenho de testar de 6 em 6 meses um full restore a tudo que esteja em cloud que lá tenho sob pena de ter que fazer novo post a lamentar-me 🙂
• Que backups de DRP para aplicações criticas de negócio não podem estar em clouds publicas.

Para a semana, irei efetuar um novo post sobre considerações de segurança para quem tem um homelab / SOHO office em casa.

Até lá! Se tiverem duvidas já sabem onde me encontrar.
Abraço!

Nuno