Replicação, backup, alta disponibilidade e governança de dados

Do zero

Imagine o livro de protocolos de um tribunal, onde cada processo que entra é anotado. Três perigos rondam esse livro, e cada um tem um remédio:

• O livro pode pegar fogo. Remédio: uma secretária copia cada anotação, na mesma hora, num segundo livro, em outra sala. Isso é replicação: outro servidor recebe cada mudança do banco principal e mantém uma cópia viva.
• Alguém pode riscar uma página por engano. A secretária copiaria o risco também. Remédio: fotografias do livro guardadas no cofre, mais o registro de tudo o que foi anotado desde a foto. Isso é backup: com ele dá para voltar ao livro como estava antes do erro.
• O protocolo não pode parar. Se a sala principal fechar, a outra sala assume na hora. Isso é alta disponibilidade: o serviço continua mesmo com falha de um servidor.

E alguém precisa decidir quem pode ler o livro, quem responde pelo que está escrito e como garantir que as anotações estejam certas. Isso é governança e segurança de dados.

Frase para guardar: a réplica protege contra a perda do servidor; o backup protege contra o erro, que a réplica copia; governança diz quem responde pelo dado.

Em 1 minuto

• Replicação síncrona: o COMMIT só termina depois que a réplica confirma; não se perde transação confirmada, mas cada gravação fica mais lenta. Assíncrona: o primário confirma sem esperar; é mais rápida, mas as últimas transações podem se perder numa falha.
• Primário e réplicas (antes chamados mestre e escravos): só o primário aceita escrita; as réplicas de leitura aliviam relatórios e consultas. Failover é a réplica assumir quando o primário cai. No PostgreSQL, a promoção é um comando (pg_ctl promote ou a função pg_promote()), e o failover automático exige uma ferramenta externa, como o Patroni; no Oracle, o Data Guard faz o failover automático com o Fast-Start Failover.
• Backup lógico exporta os objetos e dados (pg_dump, Data Pump); físico copia os arquivos do banco (pg_basebackup, RMAN). Quente é feito com o banco no ar; frio, com o banco parado.
• Recuperação até um ponto no tempo (PITR): backup físico mais o arquivo contínuo do log de transações (WAL no PostgreSQL, archived redo logs no Oracle) permitem voltar a um instante exato, como um minuto antes de um DELETE errado.
• Alta disponibilidade se mede em “noves”: 99,9% de disponibilidade admite cerca de 8,76 horas paradas por ano; 99,99%, cerca de 52,6 minutos.
• Governança de dados: papéis (proprietário, curador e custodiante), qualidade, catálogo e metadados. Segurança: menor privilégio, criptografia em repouso e em trânsito, mascaramento e auditoria.

Exemplo concreto: o DELETE sem WHERE das 14h10

O sistema de protocolo roda num PostgreSQL com uma réplica síncrona em outro prédio. Às 14h10, um técnico executa, por engano:

DELETE FROM processo;   -- faltou o WHERE

A réplica apaga tudo também, em milissegundos: ela copia fielmente o que o primário faz. A replicação não ajuda aqui. O que salva é o backup:

1. Toda madrugada, um backup físico completo (pg_basebackup).
2. O tempo todo, o arquivamento do WAL, o registro de cada mudança, num local separado.
3. Para recuperar, restaura-se o backup da madrugada e se reaplicam as mudanças do WAL até as 14h09 (no PostgreSQL, com o parâmetro recovery_target_time).

Resultado: o banco volta como estava às 14h09, sem perder o trabalho da manhã. Só com o backup lógico da noite anterior (pg_dump), a manhã inteira estaria perdida.

Agora a falha física: às 16h, o servidor principal queima. A réplica síncrona é promovida a primária, e o sistema volta em poucos minutos, sem perder nenhuma transação confirmada. Aqui a replicação é que resolve.

Comparação: replicação, backup e segurança dos dados

Nos dois SGBDs: no PostgreSQL, a replicação física é por streaming do WAL, e a lógica usa publicações e assinaturas. No Oracle, o Data Guard mantém um banco standby, que assume em caso de falha; o RAC (Real Application Clusters) põe várias instâncias, em servidores diferentes, sobre o mesmo banco, protegendo contra a queda de um servidor, mas não contra a perda do armazenamento.

Governança de dados: quem responde pelo dado

Governança de dados é decidir quem manda em cada dado e com que regras, não só guardar bem. Os papéis mais cobrados:

• Proprietário (owner): a área de negócio que responde pelo dado e decide quem pode usá-lo. Exemplo: a Secretaria de Gestão de Pessoas, pelo cadastro de servidores.
• Curador ou administrador de dados (data steward): cuida, no dia a dia, da definição, da qualidade e do uso correto do dado, em nome do proprietário.
• Custodiante: a TI, que guarda, protege e faz backup, sem decidir sobre o conteúdo.

Qualidade de dados se mede por dimensões: completude (o campo está preenchido?), unicidade (o mesmo servidor não aparece duas vezes?), exatidão (o valor corresponde à realidade?), consistência (dois sistemas dizem o mesmo?), atualidade ou tempestividade (o dado está em dia?) e validade (o valor obedece ao formato e às regras?).

O catálogo de dados lista as bases que existem, o significado de cada campo (metadados), o proprietário e a linhagem: de onde o dado veio e por quais transformações passou. A referência mais citada é o DAMA-DMBOK, o guia de conhecimento em gestão de dados da DAMA International.

Como a FCC cobra

• Failover, réplica de leitura, Data Guard e RAC.
• Backup quente × frio; pg_dump × pg_basebackup; RMAN.
• Disponibilidade em “noves” e tempo parado por ano.
• Papéis da governança (proprietário, curador, custodiante) e dimensões da qualidade de dados.

Pegadinhas

Explique com suas palavras

Explique a um gestor por que ter uma réplica do banco em outro prédio não dispensa o backup, e o que é recuperar o banco até um ponto no tempo.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

A réplica é uma cópia viva: tudo o que acontece no banco principal acontece nela logo em seguida. Se o servidor principal queimar, a réplica assume e o sistema continua. Mas, se alguém apagar dados por engano, a réplica apaga também, porque ela copia tudo, inclusive o erro.

O backup é diferente: é uma foto do banco num momento, guardada à parte. Somando a foto da madrugada ao registro de cada mudança feita depois, dá para reconstruir o banco exatamente como estava em qualquer minuto, por exemplo, um minuto antes do erro. Isso é a recuperação até um ponto no tempo. A réplica cuida da falha do equipamento; o backup cuida do erro.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso sobre o banco de um sistema crítico, separe as duas ameaças: contra a falha do servidor, réplica (síncrona, se não se pode perder transação) com failover; contra o erro e o ransomware, backup físico com arquivamento do log de transações, uma cópia fora do local e outra offline ou imutável (que o atacante não consiga cifrar nem apagar), e testes de restauração. Feche com a segurança (menor privilégio, criptografia, mascaramento dos dados sensíveis nos ambientes de teste, auditoria) e com os papéis da governança: quem é o proprietário de cada base.

Fontes da lição

• Edital nº 01/2026, Anexo II, Banco de Dados (fontes/edital-01-2026.txt).
• Documentação do PostgreSQL: alta disponibilidade e replicação e backup contínuo e recuperação até um ponto no tempo.
• Documentação do Oracle Database: Data Guard e RMAN.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2ª ed. (governança, papéis e qualidade de dados).