Eu pensei sobre o que você escreveu e aqui estão algumas idéias para você:
- Se você precisar de backup que será realmente consistente em algum momento, então você deve usar pg_basebackup ou pg_barman (usa internamente pg_basebackup) - a explicação está em 1. link abaixo. O pg_basebackup 10 mais recente transmite logs WAL para que você faça backup também de todas as alterações feitas durante o backup. É claro que esse backup leva apenas toda a instância PG. Por outro lado, não bloqueia nenhuma tabela. E se você fizer isso a partir de uma instância remota, isso causará apenas uma pequena carga de CPU na instância PG e a E/S do disco não será tão grande quanto alguns textos sugerem. Veja os links 4 sobre minhas experiências. A restauração é bastante simples - veja o link 5.
- Se você usa pg_dump, deve entender que não tem garantia de que seu backup seja realmente consistente até o momento - veja novamente o link 1. Existe a possibilidade de usar o snapshot do banco de dados (veja os links 2 e 3), mas mesmo com ele você não pode contar com 100% de consistência. Usamos pg_dump apenas em nosso banco de dados analítico que carrega novos apenas 1x por dia (partições de ontem do banco de dados de produção). Você pode acelerar com a opção paralela (funciona apenas para o formato de backup de diretório). Mas a desvantagem é uma carga muito maior na instância PG - maior uso da CPU, E/S de disco muito maior. Mesmo se você executar o pg_dump remotamente - nesse caso, você salva apenas a E/S do disco para salvar os arquivos de backup. Além disso, o pg_dump precisa colocar o bloqueio de leitura nas tabelas para que possa colidir com novas inserções ou com a replicação (quando feita na réplica). Mas quando seu banco de dados atinge centenas de GBs, até mesmo o dump paralelo pode levar horas e, nesse momento, você precisaria mudar para o pg_basebackup de qualquer maneira.
- pg_barman é a "versão confortável" do pg_basebackup + permite que você evite a perda de dados mesmo quando sua instância PG trava muito. Configurá-lo para funcionar requer mais mudanças, mas definitivamente vale a pena. Você terá que definir o arquivamento de log do WAL (consulte o link 6) e se o PG for <10, você terá que definir "max_wal_senders" e "max_replication_slots" (que você precisa para replicação de qualquer maneira) - tudo está no manual do pg-barman, embora a descrição não é exatamente ótimo. O pg_barman irá transmitir e armazenar registros WAL mesmo entre backups, desta forma você pode ter certeza de que a perda de dados em caso de falha muito grave será quase nenhuma. Mas fazê-lo funcionar pode levar muitas horas porque as descrições não são exatamente boas. O pg-barman faz backup e restauração com seus comandos.
Seu banco de dados tem 5 GB de tamanho, então qualquer método de backup será rápido. Mas você precisa decidir se precisa de recuperação pontual e quase zero de perda de dados ou não - então, se você investirá tempo para configurar o pg-barman ou não.
Links:
- PostgreSQL, Backups e tudo mais você precisa saber
- Revisão do artigo:14-serializável Isolamento de instantâneos no PostgreSQL - sobre instantâneos
- Despejo paralelo de bancos de dados - exemplo de como usar instantâneo
- pg_basebackup experiências
- pg_basebackup - restaurar backup tar
- Arquivar logs WAL usando script
