Melhores Práticas de DR

A região de DR deve executar restaurações antes que você precise delas. Estas regras transformam o DR de um deck de slides em uma capacidade de recuperação testada.

Como Usar Esta Lista

• Aplique durante a revisão anual de arquitetura e a preparação para SOC2.
• Pontue cada item após a aprovação/reprovação do dia de jogo de DR.
• Emparelhe com o registro de nível Noções Básicas de DR.
• Revisões legais/de conformidade das seções de retenção e comunicação.

A - Planejamento

• Documente RPO/RTO por nível de serviço com aprovação executiva. Sem aceitação implícita de perda de dados.
• Separe HA (AZ/nó) de DR (região) em diagramas de arquitetura. Ferramentas e RTO diferentes.
• A região de DR atende aos requisitos de residência de dados. Jurisdição aprovada antes de replicar PII.
• O nome do runbook indica quem declara o desastre. Autoridade IC documentada.
• Modelos de comunicação com o cliente pré-aprovados pelo jurídico. Sem promessas improvisadas de perda de dados.

B - Postura Técnica

• Arquivo WAL entre regiões ou backup gerenciado entre regiões. A perda da região primária não significa a perda da única cópia.
• Réplica assíncrona aquecida entre regiões ou stanza de DR restaurável. Backup frio apenas para nível 2+.
• A região de DR executou restauração ou promoção bem-sucedida nos últimos 12 meses. Evidência arquivada.
• Escopo independente de Patroni/etcd por região para auto-hospedado. Evite split-brain através de WAN.
• Cópia de backup imutável (S3 Object Lock, WORM). Ransomware não pode excluir a única cópia de backup.

C - Operações

• Dia de jogo de DR anual com teste de fumaça de DNS e aplicativo. Não apenas psql no host de DR.
• Revisão trimestral de lag entre regiões em relação ao nível de RPO. Alerte sobre lag de replay p99.
• Procedimento de fail-back de DR documentado. O exercício não deixa o DR como primário acidental.
• Credenciais de break-glass armazenadas com segurança para promoção de DR. Acessível durante a interrupção da região.
• Postmortem após qualquer DR real ou dia de jogo falho. Rastreie a lacuna de RTO até a remediação.

D - Medição

• Registre DR_GAME_DAY_RTO e compare com o registro de nível. A liderança vê o RTO medido, não teórico.
• Rastreie a divergência de dados no momento da promoção. Relatórios honestos de RPO.
• Playbook de página de status vinculado ao PagerDuty. Latência de comunicação medida.
• Verificação de backup extrai da cópia da região de DR. A cópia primária local não é suficiente.
• Trilha de auditoria: quem promoveu, quando, qual ID de backup. Evidência de conformidade.

E - Custo e Escopo

• Dimensionamento correto da instância de DR; documente o procedimento de escalonamento. Controle de custo de DR frio com runbook para escalonamento.
• Nível 2+ pode usar DR apenas de backup com RTO mais longo. Não crie excesso de dimensionamento para análise com custo de DR de nível 0.
• Revise os recursos de DR em nuvem versus Patroni auto-hospedado anualmente. Evite pagar por ambos não intencionalmente.
• Exclua bancos de dados não críticos dos gastos de DR de nível 0. Limite explícito de escopo.

FAQs

Relacionados

• Noções Básicas de DR - Framework RPO/RTO
• Réplicas entre Regiões - DR quente
• Dias de Jogo de DR - calendário de exercícios
• Melhores Práticas de Backup - cópias off-site

Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.