Decisão: qual estratégia de backup?

Uma estratégia de backup é escolhida equilibrando três fatores: quanta perda de dados você tolera (RPO), o tamanho dos seus dados e a rapidez com que precisa se recuperar (RTO). Nenhum método serve para todos os cenários. A partir da meta de RPO, esta árvore orienta você entre dumps lógicos, backups físicos + PITR e snapshots, e lembra que 3-2-1 e verificação são inegociáveis.

Qual é a sua meta de perda de dados (RPO)?

Comece pela restrição mais decisiva: em um desastre, quantos minutos/horas de dados você pode se dar ao luxo de perder? Se for exigida perda de dados próxima de zero, o arquivamento contínuo de logs (PITR) é obrigatório; se a tolerância de backup diário/semanal for aceitável, métodos mais simples bastam. O RPO define a estrutura da estratégia.

• Próximo de zero — preciso poder voltar a qualquer ponto no tempo
• Backups diários/periódicos (algumas horas de perda) são aceitáveis
• Primeiro, lembre-me das boas práticas gerais (3-2-1 / verificação)

Quais são os requisitos de tamanho dos dados e portabilidade?

Se backups periódicos bastam, a próxima pergunta é escala e finalidade: o banco é pequeno/médio e você quer que o backup seja portável para outro ambiente/versão, ou os dados são grandes e sua principal preocupação é voltar em minutos? Isso decide entre um dump lógico e um snapshot.

• Pequeno/médio, portável e compatível entre versões
• Dados grandes, a recuperação precisa ser muito rápida (RTO baixo)

Recomendação: dump lógico

Exporta os dados no nível lógico (definições de schema + linhas); a saída é SQL/texto (pg_dump em formato plain, mysqldump) ou um dump binário específico da ferramenta (pg_dump -Fc, Oracle Data Pump). Um método flexível e portável para bancos pequenos e médios, migrações, upgrades de versão e recuperação de tabelas/objetos selecionados.

Recomendação: backup físico + WAL/logs arquivados (PITR)

Você faz base backups físicos regulares e arquiva continuamente os logs de transação (WAL/redo/binlog). Isso permite executar Point-in-Time Recovery para qualquer momento e reduzir a perda de dados a quase zero.

Recomendação: snapshot

Tira um snapshot dos dados no nível de bloco na camada de armazenamento ou de virtualização. Backup e restore são muito rápidos mesmo para bancos muito grandes; porém, depende da infraestrutura e exige uso cuidadoso.

Recomendação: regra 3-2-1 + offsite + verificação obrigatória

Qualquer que seja o método escolhido, estes princípios devem estar acima da estratégia. A mera existência de um backup não basta; ele precisa estar em mídias diferentes, em outro local e ser testado regularmente. É uma estrutura que complementa todas as opções acima.