Como desenvolver estratégia de backup de muitos bancos de dados em 1 servidor

Não ter um backup, causará muito mais frustração, quando o banco de dados estiver corrompido, quebrado ou se tornar indisponível.

É um cálculo bem simples:

Sem backup

• fora do negócio
• gestão infeliz
• clientes insatisfeitos
• Grande performance

Cópia de segurança

• Leve degradação do desempenho durante o backup
• o negócio continua
• gestão feliz
• clientes felizes

pg_basebackup

A seguir está um trecho da pg_basebackupferramenta, que é fornecida com o PostgreSQL:

_{( ênfase minha)}

pg_basebackupé usado para fazer backups básicos de um cluster de banco de dados PostgreSQL em execução. Eles são obtidos sem afetar outros clientes para o banco de dados e podem ser usados ​​tanto para recuperação pontual (consulte a Seção 25.3) quanto como ponto de partida para um envio de log ou servidores em espera de replicação de streaming (consulte a Seção 26.2).

pg_basebackupfaz uma cópia binária dos arquivos do cluster de banco de dados, enquanto garante que o sistema seja colocado e retirado do modo de backup automaticamente. Os backups são sempre feitos de todo o cluster de banco de dados; não é possível fazer backup de bancos de dados individuais ou objetos de banco de dados. Para backups de banco de dados individuais, uma ferramenta como essa pg_dumpdeve ser usada.

O backup é feito através de uma conexão regular do PostgreSQL e utiliza o protocolo de replicação. A conexão deve ser feita com um superusuário ou um usuário com permissões de REPLICATION (consulte a Seção 21.2), e o pg_hba.conf deve permitir explicitamente a conexão de replicação. O servidor também deve ser configurado com max_wal_senders definido alto o suficiente para deixar pelo menos uma sessão disponível para o backup e uma para streaming WAL (se usada).

Pode haver vários pg_basebackups em execução ao mesmo tempo, mas é melhor do ponto de vista do desempenho fazer apenas um backup e copiar o resultado. ...

^{pg_basebackup (Documentação do PostgreSQL 12}

Fazendo um backup básico

Depois que tudo estiver configurado (leia toda a documentação), você poderá realizar um backup básico usando o seguinte comando:

bash #> pg_basebackup -D \postgresql\backup\ -F t -R -z -h yourhost -p 5432 -U root -W

Isso pode ser usado em um prompt interativo do bash. Ao configurar um trabalho crontab, você terá que criar um .pgpassarquivo. Isso permitirá que você execute o comando como um trabalho crontab, sem precisar digitar uma senha.

Por favor, leia 33.15. O Arquivo de Senhas (Documentação do PostgreSQL) para obter mais detalhes.

Arquivamento constante de WAL

O artigo 25.3. O arquivamento contínuo e recuperação pontual (PITR) contém informações sobre como arquivar os arquivos WAL (write ahead log) que o PostgreSQL cria. Esses arquivos são necessários para restaurar um cluster PostgreSQL para um determinado momento.

O PostgreSQL mantém sempre um registro de escrita antecipada (WAL) no subdiretório pg_wal/ do diretório de dados do cluster. O log registra todas as alterações feitas nos arquivos de dados do banco de dados. Esse log existe principalmente para fins de segurança contra falhas: se o sistema travar, o banco de dados pode ser restaurado à consistência "reproduzindo" as entradas de log feitas desde o último ponto de verificação. No entanto, a existência do log permite usar uma terceira estratégia para fazer backup de bancos de dados: podemos combinar um backup em nível de sistema de arquivos com backup dos arquivos WAL. Se a recuperação for necessária, restauramos o backup do sistema de arquivos e, em seguida, reproduzimos os arquivos WAL de backup para trazer o sistema para um estado atual. Esta abordagem é mais complexa de administrardo que qualquer uma das abordagens anteriores, mas tem alguns benefícios significativos:

• Não precisamos de um backup do sistema de arquivos perfeitamente consistente como ponto de partida. Qualquer inconsistência interna no backup será corrigida pela repetição do log (isso não é significativamente diferente do que acontece durante a recuperação de falhas). Portanto, não precisamos de um recurso de instantâneo do sistema de arquivos, apenas tar ou uma ferramenta de arquivamento semelhante.

• Como podemos combinar uma sequência indefinidamente longa de arquivos WAL para reprodução, o backup contínuo pode ser obtido simplesmente continuando a arquivar os arquivos WAL. Isso é particularmente valioso para bancos de dados grandes, nos quais pode não ser conveniente fazer um backup completo com frequência.

• Não é necessário repetir as entradas do WAL até o fim. Poderíamos interromper a reprodução a qualquer momento e ter um instantâneo consistente do banco de dados como estava naquele momento. Assim, essa técnica oferece suporte à recuperação pontual: é possível restaurar o banco de dados ao seu estado a qualquer momento desde que o backup básico foi feito.

• Se alimentarmos continuamente a série de arquivos WAL para outra máquina que foi carregada com o mesmo arquivo de backup básico, teremos um sistema de espera quente: a qualquer momento, podemos abrir a segunda máquina e ela terá uma cópia quase atual do o banco de dados.

Você então simplesmente copia o conteúdo do WALdiretório para um destino de sua escolha ou faz backup desses arquivos e tem um trabalho que exclui arquivos antigos depois que eles foram copiados para um local seguro.

Recomendação geral

Leia a seção Capítulo 25. Backup e Restauração da documentação oficial do PostgreSQL. Se você não conseguir entender como implementar uma estratégia de backup, entre em contato com um consultor que possa apoiá-lo na implementação de uma solução. Não há nada pior do que não ter um backup de banco de dados quando o proverbial "s.. bate no ventilador".

Ter um backup básico o deixará parcialmente coberto. Se você pode executar isso diariamente, então você está na metade do caminho. Mas se isso não for viável, você precisará pelo menos configurar o arquivamento do WAL.