Mudanças entre as edições de "Backup PostgreSQL Grande Porte"
De VRWiki
| Linha 1: | Linha 1: | ||
= Backups de Bancos PostgreSQL (Grande Porte) = | = Backups de Bancos PostgreSQL (Grande Porte) = | ||
| − | Este documento descreve estratégias comuns para realizar | + | Este documento descreve estratégias comuns para realizar <b>backup de bancos de dados PostgreSQL de grande porte</b>, abordando vantagens, desvantagens e boas práticas. O foco é minimizar impacto em produção, garantir consistência dos dados e facilitar a recuperação em caso de desastre. |
== Objetivos de um bom backup == | == Objetivos de um bom backup == | ||
| − | * Garantir | + | * Garantir <b>recuperação de dados</b> em caso de falha, erro humano ou ataque |
| − | * Minimizar | + | * Minimizar <b>impacto no banco principal (produção)</b> |
| − | * Possibilitar | + | * Possibilitar <b>restauração parcial ou total</b> |
| − | * Manter cópias | + | * Manter cópias <b>fora do servidor de origem</b> |
== 1. Backup lógico via replicação (pg_dump em réplica) == | == 1. Backup lógico via replicação (pg_dump em réplica) == | ||
| − | Nesta abordagem, utiliza-se uma | + | Nesta abordagem, utiliza-se uma <b>réplica de leitura</b> (streaming replication) para executar o backup lógico com `pg_dump`, evitando carga adicional no banco principal. |
=== Funcionamento === | === Funcionamento === | ||
* Banco primário replica dados continuamente para um ou mais nós secundários | * Banco primário replica dados continuamente para um ou mais nós secundários | ||
| − | * O `pg_dump` é executado | + | * O `pg_dump` é executado <b>no banco replicado</b> |
* O backup é gerado em formato lógico (custom format) | * O backup é gerado em formato lógico (custom format) | ||
| Linha 44: | Linha 44: | ||
== 2. Backup físico da pasta de dados (data directory) == | == 2. Backup físico da pasta de dados (data directory) == | ||
| − | O backup físico consiste em copiar diretamente o | + | O backup físico consiste em copiar diretamente o <b>diretório de dados do PostgreSQL</b> (`PGDATA`). |
=== Abordagem tradicional === | === Abordagem tradicional === | ||
| Linha 60: | Linha 60: | ||
=== Desvantagens === | === Desvantagens === | ||
| − | * Necessita | + | * Necessita <b>parada do banco</b> (downtime) |
* Risco operacional se scripts não forem bem controlados | * Risco operacional se scripts não forem bem controlados | ||
* Pouca flexibilidade para restaurações parciais | * Pouca flexibilidade para restaurações parciais | ||
| Linha 66: | Linha 66: | ||
=== Alternativas mais seguras === | === Alternativas mais seguras === | ||
| − | * `pg_basebackup`: permite backup físico | + | * `pg_basebackup`: permite backup físico <b>sem parar o banco</b> |
| − | * Uso de WALs para | + | * Uso de WALs para <b>PITR (Point-In-Time Recovery)</b> |
=== Boas práticas === | === Boas práticas === | ||
| Linha 99: | Linha 99: | ||
=== Observações === | === Observações === | ||
| − | * Verificar se a solução é | + | * Verificar se a solução é <b>application-aware</b> para PostgreSQL |
* Garantir suporte a WAL e restauração consistente | * Garantir suporte a WAL e restauração consistente | ||
| Linha 105: | Linha 105: | ||
== 4. RAID == | == 4. RAID == | ||
| − | RAID | + | RAID <b>não é backup</b>, mas pode fazer parte da estratégia de disponibilidade. |
=== O que o RAID oferece === | === O que o RAID oferece === | ||
| Linha 123: | Linha 123: | ||
=== Conclusão === | === Conclusão === | ||
| − | RAID deve ser visto apenas como | + | RAID deve ser visto apenas como <b>camada de alta disponibilidade</b>, nunca como substituto de backup. |
| Linha 130: | Linha 130: | ||
Mesmo com backups configurados, é fundamental: | Mesmo com backups configurados, é fundamental: | ||
| − | * Manter cópias | + | * Manter cópias <b>fora do servidor de origem</b> |
* Utilizar outro datacenter, storage remoto ou cloud (VRBackup) | * Utilizar outro datacenter, storage remoto ou cloud (VRBackup) | ||
* Implementar política de retenção (diário, semanal, mensal) | * Implementar política de retenção (diário, semanal, mensal) | ||
Edição atual tal como às 13h25min de 13 de janeiro de 2026
Índice
- 1 Backups de Bancos PostgreSQL (Grande Porte)
- 1.1 Objetivos de um bom backup
- 1.2 1. Backup lógico via replicação (pg_dump em réplica)
- 1.3 2. Backup físico da pasta de dados (data directory)
- 1.4 3. Soluções de backup de mercado (ex: Veeam Backup)
- 1.5 4. RAID
- 1.6 Observação importante: backups fora da máquina
- 1.7 Informações adicionais e boas práticas gerais
Backups de Bancos PostgreSQL (Grande Porte)
Este documento descreve estratégias comuns para realizar backup de bancos de dados PostgreSQL de grande porte, abordando vantagens, desvantagens e boas práticas. O foco é minimizar impacto em produção, garantir consistência dos dados e facilitar a recuperação em caso de desastre.
Objetivos de um bom backup
- Garantir recuperação de dados em caso de falha, erro humano ou ataque
- Minimizar impacto no banco principal (produção)
- Possibilitar restauração parcial ou total
- Manter cópias fora do servidor de origem
1. Backup lógico via replicação (pg_dump em réplica)
Nesta abordagem, utiliza-se uma réplica de leitura (streaming replication) para executar o backup lógico com `pg_dump`, evitando carga adicional no banco principal.
Funcionamento
- Banco primário replica dados continuamente para um ou mais nós secundários
- O `pg_dump` é executado no banco replicado
- O backup é gerado em formato lógico (custom format)
Vantagens
- Não impacta significativamente o banco de produção
- Permite backup por banco
- Não exige parada do banco
Desvantagens
- Processo pode ser lento para bancos muito grandes
- Consome CPU, memória e I/O do servidor réplica
- Não preserva estatísticas internas e configurações físicas
- Restauração pode ser demorada
Boas práticas
- Utilizar formato `custom` (`pg_dump -Fc`) para permitir paralelismo na restauração
- Garantir que a réplica esteja sincronizada
- Automatizar via cron ou ferramentas de orquestração
2. Backup físico da pasta de dados (data directory)
O backup físico consiste em copiar diretamente o diretório de dados do PostgreSQL (`PGDATA`).
Abordagem tradicional
- Parar o serviço PostgreSQL
- Copiar o diretório de dados via script (`rsync`, `tar`, etc.)
- Reiniciar o serviço
Vantagens
- Backup rápido, especialmente para bancos muito grandes
- Preserva estrutura física, índices e estatísticas
- Restauração geralmente mais rápida
Desvantagens
- Necessita parada do banco (downtime)
- Risco operacional se scripts não forem bem controlados
- Pouca flexibilidade para restaurações parciais
Alternativas mais seguras
- `pg_basebackup`: permite backup físico sem parar o banco
- Uso de WALs para PITR (Point-In-Time Recovery)
Boas práticas
- Sempre validar consistência após restore
- Testar restauração regularmente
3. Soluções de backup de mercado (ex: Veeam Backup)
Ferramentas comerciais oferecem integração com PostgreSQL e infraestrutura.
Características
- Interface gráfica e gerenciamento centralizado
- Automação de políticas de retenção
- Integração com snapshots de storage e virtualização
Vantagens
- Reduz complexidade operacional
- Suporte técnico através do fornecedor da ferramenta
- Integração com ambientes VMware, Hyper-V e cloud
Desvantagens
- Custo de licenciamento
- Dependência de fornecedor
- Menor controle sobre detalhes internos do backup
Observações
- Verificar se a solução é application-aware para PostgreSQL
- Garantir suporte a WAL e restauração consistente
4. RAID
RAID não é backup, mas pode fazer parte da estratégia de disponibilidade.
O que o RAID oferece
- Redundância de discos
- Proteção contra falha física de hardware
- Melhor desempenho de leitura/escrita (dependendo do nível)
Limitações
- Não protege contra:
* Exclusão acidental de dados * Corrupção lógica * Ataques (ex: ransomware)
- Erros são replicados imediatamente
Conclusão
RAID deve ser visto apenas como camada de alta disponibilidade, nunca como substituto de backup.
Observação importante: backups fora da máquina
Mesmo com backups configurados, é fundamental:
- Manter cópias fora do servidor de origem
- Utilizar outro datacenter, storage remoto ou cloud (VRBackup)
- Implementar política de retenção (diário, semanal, mensal)
Informações adicionais e boas práticas gerais
- Documentar claramente o processo de backup e restore
- Monitorar falhas de backup
- Testar restores periodicamente (disaster recovery test)
- Utilizar compressão e paralelismo quando possível
Estratégia recomendada
Uma estratégia robusta geralmente combina:
- Replicação + `pg_dump` para restores lógicos
- Backup físico (`pg_basebackup` + WAL) para recuperação rápida
- Cópia externa (offsite)
- RAID para resiliência de hardware
Backups só são confiáveis quando a restauração foi testada com sucesso.
