Planejamento de Recuperação de Desastres
RPO, RTO e manuais de procedimentos.
Planejamento de Recuperação de Desastres é uma aula grátis de SQL Academy no CoddyKit. Esta é a aula 4 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.
O que é recuperação de desastres
A recuperação de desastres (DR) é o conjunto de políticas, ferramentas e procedimentos projetados para possibilitar a recuperação da infraestrutura e dos sistemas de tecnologia essenciais após um desastre natural ou causado por ação humana.
No contexto dos bancos de dados, o planejamento de DR garante que seus dados permaneçam seguros e que seus sistemas possam voltar a ficar disponíveis dentro de limites de tempo aceitáveis após eventos como falha de equipamento, exclusão acidental de dados, ataques de malware de resgate ou interrupções no centro de dados.
Objetivo do ponto de recuperação (RPO)
RPO define a quantidade máxima aceitável de perda de dados, medida em tempo. Se seu RPO for de 1 hora, você deverá conseguir recuperar dados de um momento situado no máximo 1 hora antes do desastre.
Um RPO menor exige cópias de segurança mais frequentes ou replicação contínua. Você pode consultar seu histórico de cópias de segurança para verificar se está cumprindo sua meta de RPO.
-- Check the last backup time and calculate data loss window
SELECT
backup_id,
backup_type,
started_at,
finished_at,
EXTRACT(EPOCH FROM (NOW() - finished_at)) / 3600 AS hours_since_backup
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at DESC
LIMIT 5;Objetivo de tempo de recuperação (RTO)
RTO define o período máximo aceitável em que seu sistema pode ficar indisponível após um desastre. Se seu RTO for de 4 horas, seu banco de dados deverá estar totalmente operacional em até 4 horas após uma falha.
O RTO orienta decisões sobre servidores de espera, automação de comutação e procedimentos de restauração. Acompanhar os tempos de restauração ao longo do tempo ajuda a prever se você conseguirá cumprir seu RTO.
-- Track restore durations to validate RTO compliance
SELECT
restore_id,
triggered_at,
completed_at,
EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 60 AS restore_minutes,
CASE
WHEN EXTRACT(EPOCH FROM (completed_at - triggered_at)) / 3600 <= 4
THEN 'WITHIN RTO'
ELSE 'RTO BREACHED'
END AS rto_status
FROM restore_log
ORDER BY triggered_at DESC;RPO versus RTO — a principal diferença
Essas duas métricas costumam ser confundidas. Veja a maneira mais simples de lembrá-las:
- RPO = Quanto de dados você pode perder? (olhando para trás, medido no tempo anterior ao desastre)
- RTO = Por quanto tempo você pode ficar indisponível? (olhando para frente, medido no tempo posterior ao desastre)
Juntos, eles definem sua janela de recuperação e influenciam diretamente a frequência das cópias de segurança, a estratégia de replicação e o orçamento de infraestrutura.
-- Store RPO and RTO targets per database in a DR configuration table
CREATE TABLE dr_config (
db_name VARCHAR(100) PRIMARY KEY,
rpo_minutes INT NOT NULL,
rto_minutes INT NOT NULL,
tier VARCHAR(20) CHECK (tier IN ('CRITICAL', 'HIGH', 'MEDIUM', 'LOW')),
updated_at TIMESTAMP DEFAULT NOW()
);
INSERT INTO dr_config (db_name, rpo_minutes, rto_minutes, tier) VALUES
('orders_db', 15, 60, 'CRITICAL'),
('analytics_db', 120, 240, 'MEDIUM'),
('archive_db', 480, 480, 'LOW');Tipos de cópias de segurança
Há três estratégias principais de cópia de segurança, cada uma equilibrando velocidade e armazenamento:
- Cópia de segurança completa: Um instantâneo completo de todo o banco de dados. É a mais lenta para criar e a mais rápida para restaurar.
- Cópia diferencial: Apenas as alterações desde a última cópia de segurança completa. Tem velocidade moderada nas duas operações.
- Cópia incremental: Apenas as alterações desde a última cópia de segurança de qualquer tipo. É a mais rápida para criar e a mais lenta para restaurar (são necessários vários arquivos).
A maioria das estratégias de DR combina cópias completas semanais com cópias incrementais diárias para equilibrar o RPO e o custo de armazenamento.
-- Log each backup with its type for audit and recovery planning
CREATE TABLE backup_log (
backup_id SERIAL PRIMARY KEY,
db_name VARCHAR(100) NOT NULL,
backup_type VARCHAR(20) CHECK (backup_type IN ('FULL', 'DIFFERENTIAL', 'INCREMENTAL')),
started_at TIMESTAMP NOT NULL,
finished_at TIMESTAMP,
size_mb NUMERIC(12, 2),
status VARCHAR(20) DEFAULT 'IN_PROGRESS'
);
INSERT INTO backup_log (db_name, backup_type, started_at, finished_at, size_mb, status) VALUES
('orders_db', 'FULL', '2024-06-01 01:00:00', '2024-06-01 02:15:00', 45200, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-02 01:00:00', '2024-06-02 01:08:00', 320, 'SUCCESS'),
('orders_db', 'INCREMENTAL', '2024-06-03 01:00:00', '2024-06-03 01:07:00', 290, 'SUCCESS');Recuperação em um ponto no tempo (PITR)
A recuperação em um ponto no tempo permite restaurar um banco de dados para qualquer momento específico, não apenas para o momento da última cópia de segurança. Isso é obtido reproduzindo registros de transações (WAL no PostgreSQL) sobre uma cópia de segurança de base.
O PITR é essencial quando você precisa se recuperar de corrupção ou exclusão acidental de dados ocorrida em um momento conhecido. Você pode restaurar para imediatamente antes da ocorrência do evento prejudicial.
-- Record WAL archive events for PITR tracking
CREATE TABLE wal_archive_log (
segment_name VARCHAR(200) PRIMARY KEY,
archived_at TIMESTAMP DEFAULT NOW(),
size_bytes BIGINT,
storage_path TEXT
);
-- Find all WAL segments archived within a recovery window
SELECT
segment_name,
archived_at,
ROUND(size_bytes / 1024.0 / 1024.0, 2) AS size_mb
FROM wal_archive_log
WHERE archived_at BETWEEN '2024-06-03 09:00:00' AND '2024-06-03 11:00:00'
ORDER BY archived_at;Bancos de dados de espera e replicação
Um banco de dados de espera (réplica) é uma cópia continuamente atualizada do banco de dados principal, executada em equipamento separado. Ele atende a duas finalidades de DR:
- Espera ativa: Pode aceitar consultas de leitura e assumir o controle em segundos (RTO quase zero).
- Espera em prontidão: É mantida sincronizada, mas não atende tráfego; a comutação leva minutos.
Monitorar o atraso da replicação é essencial — uma réplica atrasada significa que seu RPO real é pior que o esperado.
-- Monitor replication lag on a PostgreSQL primary
SELECT
client_addr,
application_name,
state,
sent_lsn,
replay_lsn,
(sent_lsn - replay_lsn) AS lag_bytes,
EXTRACT(EPOCH FROM (NOW() - reply_time)) AS seconds_since_reply
FROM pg_stat_replication
ORDER BY lag_bytes DESC;Manuais operacionais: documentando procedimentos de recuperação
Um manual operacional é um conjunto documentado de instruções passo a passo que um operador segue durante um evento de recuperação de desastres. Sem um manual operacional, até mesmo administradores de banco de dados experientes cometem erros dispendiosos sob pressão.
Um bom manual operacional de DR inclui: quem contatar, quais sistemas são afetados, os comandos exatos a executar, as saídas esperadas em cada etapa e procedimentos de reversão caso a recuperação falhe. Armazenar os metadados do manual operacional em um banco de dados ajuda a acompanhar o controle de versões e auditar o uso.
-- Store runbook metadata in the database for audit tracking
CREATE TABLE runbook (
runbook_id SERIAL PRIMARY KEY,
title VARCHAR(200) NOT NULL,
scenario VARCHAR(100),
version VARCHAR(20) DEFAULT '1.0',
last_tested DATE,
owner VARCHAR(100),
doc_url TEXT
);
INSERT INTO runbook (title, scenario, version, last_tested, owner, doc_url) VALUES
('Full Database Restore from S3', 'total_loss', '2.1', '2024-05-15', 'dba_team', 'https://wiki.internal/dr/full-restore'),
('Failover to Hot Standby', 'primary_down', '1.4', '2024-04-20', 'dba_team', 'https://wiki.internal/dr/failover'),
('PITR to Specific Timestamp', 'data_corruption','1.2', '2024-03-10', 'dba_team', 'https://wiki.internal/dr/pitr');Registro da execução de manuais operacionais
Cada vez que um manual operacional é executado — seja em um desastre real ou em um exercício — isso deve ser registrado. Os registros de execução permitem medir quanto tempo a recuperação realmente leva (validando seu RTO), identificar etapas lentas ou propensas a erros e demonstrar conformidade perante os auditores.
-- Log each runbook execution for RTO validation and audit
CREATE TABLE runbook_execution (
execution_id SERIAL PRIMARY KEY,
runbook_id INT REFERENCES runbook(runbook_id),
triggered_by VARCHAR(100),
is_drill BOOLEAN DEFAULT FALSE,
started_at TIMESTAMP NOT NULL,
completed_at TIMESTAMP,
outcome VARCHAR(20) CHECK (outcome IN ('SUCCESS', 'PARTIAL', 'FAILED'))
);
-- Report average restore time per runbook
SELECT
r.title,
COUNT(*) AS executions,
ROUND(AVG(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60), 1) AS avg_minutes,
MAX(EXTRACT(EPOCH FROM (e.completed_at - e.started_at)) / 60) AS max_minutes
FROM runbook_execution e
JOIN runbook r ON r.runbook_id = e.runbook_id
WHERE e.outcome = 'SUCCESS'
GROUP BY r.title;Testes de DR: exercícios regulares
Um plano de DR que nunca foi testado não é um plano — é um desejo. Exercícios regulares são obrigatórios para garantir que sua equipe consiga realmente executar os manuais operacionais dentro do RTO definido e que as cópias de segurança possam de fato ser restauradas.
Agendar e acompanhar exercícios no banco de dados cria uma trilha de auditoria e ajuda a identificar manuais operacionais cujo teste está atrasado.
-- Find runbooks that have not been drilled in over 90 days
SELECT
r.runbook_id,
r.title,
r.scenario,
MAX(e.completed_at) AS last_drill,
CURRENT_DATE - MAX(e.completed_at::DATE) AS days_since_drill
FROM runbook r
LEFT JOIN runbook_execution e
ON e.runbook_id = r.runbook_id
AND e.is_drill = TRUE
AND e.outcome = 'SUCCESS'
GROUP BY r.runbook_id, r.title, r.scenario
HAVING MAX(e.completed_at) IS NULL
OR CURRENT_DATE - MAX(e.completed_at::DATE) > 90
ORDER BY days_since_drill DESC NULLS FIRST;Políticas de retenção de cópias de segurança
As políticas de retenção definem por quanto tempo as cópias de segurança são mantidas. Manter cada cópia para sempre desperdiça armazenamento; excluí-las rápido demais viola seu RPO e os requisitos de conformidade.
Uma política comum é: cópias incrementais diárias por 7 dias, cópias completas semanais por 4 semanas e cópias completas mensais por 12 meses. Você pode aplicar e auditar a retenção com consultas SQL ao seu registro de cópias de segurança.
-- Identify backups that are outside their retention window and ready to purge
SELECT
backup_id,
db_name,
backup_type,
finished_at,
CURRENT_DATE - finished_at::DATE AS age_days,
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END AS retention_days,
CASE
WHEN (CURRENT_DATE - finished_at::DATE) >
CASE backup_type
WHEN 'INCREMENTAL' THEN 7
WHEN 'DIFFERENTIAL' THEN 28
WHEN 'FULL' THEN 365
END
THEN 'PURGE'
ELSE 'KEEP'
END AS action
FROM backup_log
WHERE status = 'SUCCESS'
ORDER BY finished_at;Verificação rápida
Verifique sua compreensão das definições de RPO e RTO.
Recapitulação: planejamento de recuperação de desastres
Nesta lição, você explorou os fundamentos do planejamento de recuperação de desastres de bancos de dados:
- RPO define a perda máxima de dados tolerável ao longo do tempo; um RPO mais curto exige cópias de segurança mais frequentes ou replicação contínua.
- RTO define em quanto tempo o sistema deve ser restaurado; um RTO mais curto exige servidores em espera a quente e comutação automática para contingência.
- Os tipos de cópia de segurança — completa, diferencial e incremental — oferecem diferentes compromissos entre espaço de armazenamento, velocidade de criação e velocidade de restauração.
- PITR (recuperação em um ponto no tempo) usa registros de transações para restaurar os dados a qualquer momento preciso, protegendo contra alterações acidentais.
- Manuais operacionais documentam cada etapa de um procedimento de recuperação; registrar as execuções valida se o seu RTO é alcançável na prática.
- Exercícios regulares de DR são a única forma de confirmar que as cópias de segurança podem ser restauradas e que sua equipe consegue cumprir as metas de RPO e RTO sob pressão real.
- Políticas de retenção equilibram o custo de armazenamento com os requisitos de conformidade e recuperação.
Um plano de DR bem testado é um dos investimentos mais valiosos que uma equipe de banco de dados pode fazer.
Perguntas Frequentes
A aula “Planejamento de Recuperação de Desastres” é grátis?
Sim — o texto completo de “Planejamento de Recuperação de Desastres” é 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 “Planejamento de Recuperação de Desastres”?
RPO, RTO e manuais de procedimentos. 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 4 de 4.
Quanto tempo leva a aula “Planejamento de Recuperação de Desastres”?
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