Como testar um restore, não só um backup

Todas as consolas de backup do mundo conseguem mostrar uma coluna de vistos verdes. Nenhuma delas consegue dizer se a sua empresa estará a funcionar de novo à hora de almoço depois de uma noite má. Só um restore consegue dizer isso, e o único restore em que pode confiar é aquele que já fez. É assim que se testam restores para que o resultado signifique alguma coisa.

O que um job verde prova de facto

Um backup job bem-sucedido prova que um job correu, leu alguns dados e os escreveu algures sem um erro que o software reconhecesse. Não prova que os dados estão completos, que a máquina que lhe interessa estava no job, que a cópia pode ser lida de volta, ou que a aplicação arranca a partir dela.

Há três coisas a testar: cobertura (tudo o que devia ter backup tem mesmo backup), recuperabilidade (a cópia pode ser lida e arrancada) e tempo (quanto demora realmente uma recuperação). A maioria das organizações não testa nenhuma delas de forma agendada.

Passo um: verifique a cobertura face à realidade

Os backup jobs são definidos num dado momento. A infraestrutura continua a mudar. Uma máquina virtual nova criada ao lado das antigas, uma base de dados movida para um novo host, um servidor renomeado: cada um pode cair fora de todos os jobs sem que um único erro seja levantado.

Por isso, compare a lista do que existe com a lista do que está protegido. Exporte o inventário do sítio que sabe o que está a correr, o hypervisor, a plataforma cloud ou o DCIM, e a lista de objetos protegidos do sistema de backup, e depois compare-as:

sort -u running-inventory.txt > running.sorted
sort -u protected-objects.txt > protected.sorted
comm -23 running.sorted protected.sorted   # running, but not protected
comm -13 running.sorted protected.sorted   # protected, but no longer running

A primeira lista é a perigosa. A segunda é entulho que a esconde. Cada entrada da primeira lista precisa de uma decisão: acrescentá-la a um job, ou escrever que deliberadamente não tem backup e porquê.

Passo dois: restore em mais do que um nível

A recuperabilidade tem níveis, e cada nível apanha problemas que o nível abaixo deixa passar.

Nível de ficheiro. Faça restore de uma amostra de ficheiros para uma localização alternativa e compare-os por checksum com a origem ou com uma cópia conhecida como boa. Isto apanha suportes ilegíveis e cadeias de backups incrementais quebradas.

Nível de máquina. Arranque um servidor ou uma máquina virtual inteira a partir do backup. Isto apanha volumes de arranque em falta, drivers e o disco que foi silenciosamente excluído do job. A maioria das plataformas de backup enterprise, o Veeam entre elas, consegue arrancar uma máquina diretamente a partir do repositório de backup para um lab isolado exatamente com este propósito.

Nível de aplicação. Prove que a aplicação funciona a partir da cópia restaurada. Para uma base de dados, isso significa que arranca, passa a sua própria verificação de consistência, e contém os registos mais recentes que espera para o momento do backup:

# MySQL or MariaDB
mysqlcheck --all-databases --check
mysql -e "SELECT MAX(created_at) FROM orders;"

# PostgreSQL
pg_amcheck --all
psql -c "SELECT max(created_at) FROM orders;"

Para ferramentas de backup ao nível de ficheiro existem verificações de integridade que leem de volta os dados guardados, por exemplo borg check --verify-data num repositório Borg.

Passo três: restore para um lab, não para produção

Uma máquina restaurada é uma cópia da produção, com os endereços, as credenciais, as tarefas agendadas e o mail de saída da produção. Ponha-a a correr na rede real e pode responder a pedidos destinados ao servidor em produção, enviar aos clientes um lote de e-mails duplicados, ou correr o job de faturação de ontem à noite uma segunda vez.

Os testes de restore pertencem, portanto, a uma rede isolada sem rota para a produção e sem rota para a internet. Antes de arrancar qualquer aplicação nesse lab, desative o scheduler e o mail de saída na cópia restaurada. Torne isso um passo escrito do teste, para que ninguém tenha de se lembrar.

Passo quatro: cronometre

O tempo de recuperação no papel é uma estimativa. O que conta é o medido: desde o momento em que alguém decide fazer restore, passando por encontrar o restore point certo, mover os dados, arrancar os serviços e verificar a aplicação, até à primeira transação real bem-sucedida. Os restores grandes são muitas vezes limitados por um throughput que ninguém mediu, ou por um passo que só uma pessoa sabe fazer. Cronometrar toda a sequência encontra ambos.

Passo cinco: escreva

Guarde uma entrada curta para cada um:

• Data, e quem o executou.
• O que foi restaurado, a partir de que restore point.
• Que nível foi testado: ficheiro, máquina ou aplicação.
• Tempo gasto, de ponta a ponta.
• Tudo o que falhou, surpreendeu ou exigiu conhecimento que não está escrito.
• O que mudou em resultado.

O desenho por baixo também conta

Os testes provam que os backups existem e funcionam hoje. O desenho decide se ainda vão existir depois de um dia mau. A regra que mais importa é que os backups são puxados. O sistema de backup entra na produção e leva o que precisa. A produção não tem caminho de rede para o sistema de backup nem credenciais para ele. Assim, um intruso que domine um servidor de produção não consegue chegar aos backups desse mesmo servidor para os apagar. O acesso append-only para ferramentas ao nível de ficheiro acrescenta uma segunda fechadura, e o histórico no repositório significa que uma cópia anterior ao problema continua a existir.

Como o fazemos

Os nossos backups são pull-only por desenho e impostos nos equipamentos de firewall, com apenas a rede de gestão a poder chegar aos sistemas de backup e recuperação. Usamos Veeam para máquinas virtuais, servidores físicos e servidores SQL, e um hub de backup com deduplicação que puxa dados de ficheiros e bases de dados Linux com chaves restritas, append-only. A cobertura é verificada face ao inventário em produção, os horários são definidos a partir de tempos de execução medidos, e restores completos correm com uma frequência que chega a ser semanal.

Se nunca cronometrou um restore completo do seu sistema mais importante, é por esse que deve começar, e teremos todo o gosto em ajudar a planeá-lo.

CTA

Fale com um engenheiro

Related

Relacionados: Disaster recovery e réplicas num segundo site · Storage replication entre Atenas e Amesterdão · Serviços de ficheiros NAS, NFS e SMB