Testando suas restaurações
Um backup que não pode ser restaurado é inútil.
Testando suas restaurações é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 3 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de SQL Academy, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de SQL Academy inclui 4 aulas no total.
Uma cópia de segurança que não pode ser restaurada não tem valor
Muitas equipes investem tempo configurando cópias de segurança automatizadas, mas nunca verificam se elas podem realmente ser usadas para recuperar dados. Uma cópia de segurança que falha durante a restauração não é uma cópia de segurança.
Esta lição apresenta a disciplina dos testes de restauração: como verificar se suas cópias de segurança funcionam antes que um desastre real obrigue você a descobrir isso da pior forma.
O que envolve um teste de restauração
Um teste de restauração consiste em pegar um arquivo de cópia de segurança e carregá-lo em um banco de dados — normalmente uma instância de teste separada — e, em seguida, consultar esse banco para confirmar que os dados estão completos e consistentes.
As etapas são: 1) Obtenha o arquivo de cópia de segurança. 2) Restaure-o em um ambiente isolado. 3) Execute consultas de validação. 4) Compare os resultados com o ambiente de produção.
Criando um instantâneo de referência para comparação
Antes de poder verificar uma restauração, é necessário ter uma referência — um conjunto conhecido de contagens e somas de verificação da produção para comparar com a cópia restaurada.
Execute isto no banco de dados de produção e registre os resultados:
SELECT
'orders' AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
'customers' AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
'order_items' AS tbl, COUNT(*) AS row_count FROM order_items;Verificando as contagens de linhas após a restauração
Assim que a cópia de segurança for restaurada em um banco de dados de teste, execute a mesma consulta e compare os números. Se as contagens coincidirem, a estrutura básica da restauração está íntegra.
Uma divergência aqui informa imediatamente que houve perda de dados durante a cópia de segurança ou a restauração — antes mesmo de você tocar no ambiente de produção.
-- Run on the RESTORED test database
SELECT
'orders' AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
'customers' AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
'order_items' AS tbl, COUNT(*) AS row_count FROM order_items;Verificando os dados mais recentes
As contagens de linhas confirmam a quantidade, mas não confirmam a atualidade. Verifique se o banco de dados restaurado contém registros recentes — a cópia de segurança deve refletir os dados até o momento em que foi criada.
SELECT
MAX(created_at) AS latest_order,
MIN(created_at) AS oldest_order,
COUNT(*) AS total_orders
FROM orders;Validando a integridade referencial
Mesmo que as contagens de linhas coincidam, uma restauração pode deixar linhas órfãs — registros filhos cujo registro pai não existe mais. Isso costuma acontecer quando as chaves estrangeiras não são impostas durante a cópia de segurança ou a restauração.
Use um LEFT JOIN para detectar itens de pedido órfãos:
SELECT
oi.id AS orphaned_item_id,
oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;Usando uma soma de verificação para detectar corrupção
Para tabelas críticas, gere uma soma de verificação dos dados para detectar corrupção em nível de bits. No PostgreSQL, você pode combinar MD5 com uma conversão da linha inteira.
Se a soma de verificação da produção e a da cópia restaurada forem diferentes, os dados foram alterados ou corrompidos em algum momento.
SELECT
MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
FROM orders
) sub;Criando uma tabela de validação de restaurações
Para acompanhar o histórico dos seus testes de restauração, crie uma tabela dedicada de registro de validação. Registre cada execução de teste com a data da cópia de segurança, as contagens de linhas restauradas e se a validação foi aprovada.
CREATE TABLE IF NOT EXISTS restore_validation_log (
id SERIAL PRIMARY KEY,
backup_taken_at TIMESTAMP NOT NULL,
restored_at TIMESTAMP NOT NULL DEFAULT NOW(),
table_name VARCHAR(100) NOT NULL,
expected_rows INT NOT NULL,
actual_rows INT NOT NULL,
passed BOOLEAN NOT NULL
);Inserindo um resultado de validação
Após cada teste de restauração, insira uma linha no registro de validação. Isso fornece uma trilha de auditoria que comprova que as cópias de segurança foram testadas e mostra um padrão de aprovação ou reprovação ao longo do tempo.
INSERT INTO restore_validation_log
(backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
('2024-06-09 02:00:00', 'orders', 15482, 15482, TRUE),
('2024-06-09 02:00:00', 'customers', 8201, 8201, TRUE),
('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);Consultando o histórico de validação
Revise regularmente o registro de validação para identificar regressões. Uma cópia de segurança que foi aprovada na semana passada, mas falha nesta semana, sinaliza um problema no fluxo de cópias de segurança que deve ser investigado imediatamente.
SELECT
backup_taken_at,
table_name,
expected_rows,
actual_rows,
passed,
CASE
WHEN passed THEN 'OK'
ELSE 'MISMATCH - investigate!'
END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;Verificação da recuperação em um ponto no tempo (PITR)
Bancos de dados modernos são compatíveis com a recuperação em um ponto no tempo (PITR), que permite restaurar para qualquer momento usando uma cópia de segurança de base e arquivos WAL (registro de gravação antecipada).
Para verificar se o PITR está funcionando, restaure para uma marca temporal conhecida e confirme que um registro criado depois dessa marca NOT apareça no banco de dados restaurado:
-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctlyVerificação rápida
Qual das consultas a seguir é mais útil para detectar registros filhos órfãos após restaurar uma cópia de segurança?
Recapitulação da lição: testando suas restaurações
Nesta lição, você aprendeu por que os testes de restauração são uma parte obrigatória de qualquer estratégia de cópia de segurança e como implementá-los com SQL:
- Instantâneos de referência — registre as contagens de linhas da produção antes do teste.
- Comparação das contagens de linhas — execute a mesma consulta no banco de dados restaurado e compare os resultados.
- Verificação da atualidade — confirme se os registros mais recentes correspondem à janela esperada da cópia de segurança.
- Integridade referencial — use LEFT JOIN para encontrar linhas filhas órfãs.
- Validação por soma de verificação — detecte corrupção em nível de bits com agregações MD5.
- Tabela de registro de validação — acompanhe cada execução de teste para manter um histórico auditável.
- Verificação do PITR — confirme que a recuperação em um ponto no tempo chega ao momento correto.
Uma cópia de segurança só é tão boa quanto o teste de restauração bem-sucedido mais recente. Agende essas verificações regularmente e trate qualquer falha como um incidente crítico.
Perguntas Frequentes
A aula “Testando suas restaurações” é grátis?
Sim — o texto completo de “Testando suas restaurações” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de SQL Academy, atualize para CoddyKit PRO. O curso de SQL Academy inclui 4 aulas no total.
O que vou aprender em “Testando suas restaurações”?
Um backup que não pode ser restaurado é inútil. Você pratica SQL Academy com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar SQL Academy?
Nenhuma experiência prévia é necessária. SQL Academy no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 3 de 4.
Quanto tempo leva a aula “Testando suas restaurações”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de SQL Academy?
Sim. Cada aula de SQL Academy inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Backups lógicos versus físicos
- Recuperação para um ponto no tempo
- Testando suas restaurações
- Planejamento de Recuperação de Desastres