Poupe 15% em todos os serviços de alojamento

Teste as suas habilidades e obtenha Desconto em qualquer plano

Utilizar o código: Skills Começar a trabalhar
Secções
Instrução Servidores Dedicados

Backup e Recuperação de Bancos de Dados PostgreSQL: Um Guia Completo para Usuários AlexHost

Por que a Estratégia de Backup do PostgreSQL é Mais Importante do que Você Pensa

A perda de dados não é um risco hipotético — é uma certeza operacional que todo administrador de banco de dados enfrentará em algum momento. Falhas de hardware, exclusões acidentais, transações corrompidas e ataques de ransomware podem derrubar um ambiente de produção em segundos. Para usuários de PostgreSQL, ter uma estratégia de backup robusta, testada e automatizada é a diferença entre um incidente menor e uma falha catastrófica nos negócios.

AlexHost Dedicated Servers fornecem uma base ideal para hospedar e proteger bancos de dados PostgreSQL. Com armazenamento NVMe SSD de nível empresarial oferecendo throughput de I/O excepcional, acesso root completo para controle total de configuração e proteção DDoS integrada, AlexHost oferece o desempenho de infraestrutura e postura de segurança que cargas de trabalho sérias de banco de dados exigem.

Quer você esteja executando uma plataforma de e-commerce de alto tráfego, uma aplicação SaaS, uma instalação WordPress apoiada por um banco de dados relacional ou um sistema empresarial personalizado, este guia o orienta através de todos os principais métodos de backup e recuperação do PostgreSQL — desde dumps SQL simples até Point-in-Time Recovery (PITR) avançado — tudo otimizado para ambientes de produção.

1. Understanding PostgreSQL Backup Options

PostgreSQL ships with several mature, well-documented backup mechanisms. Choosing the right one depends on your database size, recovery time objectives (RTO), recovery point objectives (RPO), and operational complexity tolerance.

MétodoMelhor ParaVantagensDesvantagens
SQL Dump (pg_dump)Bases de dados pequenas a médiasSimples, portátil, legível por humanosLento para DBs muito grandes
Custom Format DumpBases de dados médias a grandesComprimido, restauração paralelaBinário, requer pg_restore
File System SnapshotBases de dados muito grandesRápido, consistenteRequer experiência, DB deve estar em repouso ou com suporte a snapshot
PITR (WAL Archiving)Sistemas de produção críticos para a missãoRecuperação granular point-in-timeConfiguração e manutenção complexas

Understanding these trade-offs before you begin is essential. Most production environments benefit from combining at least two approaches — for example, nightly custom format dumps alongside continuous WAL archiving for granular recovery capability.

2. Pré-requisitos e Requisitos de Privilégio

Antes de executar qualquer operação de backup, confirme se os seguintes pré-requisitos estão em vigor:

Privilégios do Utilizador:

  • Deve ser um superutilizador PostgreSQL ou o proprietário da base de dados de destino para executar um backup completo.
  • Para pg_dumpall, privilégios de superutilizador são obrigatórios.

Verifique a sua versão PostgreSQL:

psql --version

Verifique o espaço em disco disponível antes de fazer backup:

df -h /var/lib/postgresql/

Certifique-se de que o seu destino de backup tem espaço livre suficiente — no mínimo 1.5× o tamanho da base de dados que está a fazer backup para contabilizar ficheiros temporários e overhead de compressão.

Conecte-se ao seu servidor via SSH:

ssh root@your-server-ip

Se estiver a utilizar um plano de VPS Hosting, terá acesso SSH completo e a capacidade de instalar, configurar e gerir PostgreSQL sem restrições.

3. Método 1 — SQL Dump com pg_dump

O utilitário pg_dump é a ferramenta de backup PostgreSQL mais comumente utilizada. Produz um snapshot consistente de uma única base de dados, mesmo enquanto a base de dados está sendo usada ativamente. O resultado é um script SQL em texto simples que pode ser revisado, editado e reproduzido em qualquer instalação PostgreSQL compatível.

Passo 1: Abra um Terminal e Aceda ao Seu Servidor

ssh root@your-alexhost-server-ip

Passo 2: Execute o Comando pg_dump

pg_dump -U username -W -F p database_name > /backups/backup_file.sql

Detalhamento dos parâmetros:

ParâmetroDescrição
-U usernameO utilizador PostgreSQL que realiza o backup
-WSolicitar a palavra-passe interativamente
-F pFormato de saída: p = texto SQL simples
database_nameO nome da base de dados para fazer backup
> /backups/backup_file.sqlRedirecionar a saída para um ficheiro

Exemplo prático:

pg_dump -U postgres -W -F p my_production_db > /backups/my_production_db_$(date +%Y%m%d_%H%M%S).sql

> Dica Profissional: Adicionar um timestamp usando $(date +%Y%m%d_%H%M%S) ao nome do ficheiro de backup garante que nunca sobrescreve acidentalmente um backup anterior e cria um arquivo cronológico natural.

Passo 3: Verifique o Ficheiro de Backup

ls -lh /backups/
head -50 /backups/my_production_db_*.sql

O ficheiro deve começar com comentários de cabeçalho PostgreSQL e declarações SET, confirmando que um dump válido foi criado.

4. Método 2 — Fazer Backup de Todas as Bases de Dados com pg_dumpall

Quando precisa fazer backup de todas as bases de dados numa instância PostgreSQL — incluindo objetos globais como roles e tablespaces — pg_dumpall é a ferramenta correta.

pg_dumpall -U postgres -W > /backups/all_databases_$(date +%Y%m%d).sql

Este comando exporta:

  • Todas as bases de dados
  • Todas as roles (utilizadores e grupos)
  • Todos os tablespaces
  • Toda a configuração global

Importante: O ficheiro de saída de pg_dumpall pode ser muito grande em servidores ocupados. Certifique-se de que a sua partição de backup tem espaço adequado e considere comprimir a saída imediatamente:

pg_dumpall -U postgres | gzip > /backups/all_databases_$(date +%Y%m%d).sql.gz

5. Método 3 — Backups em Formato Personalizado para Grandes Bases de Dados

Para bases de dados de produção que excedem alguns gigabytes, o formato personalizado (-F c) é fortemente recomendado em relação aos dumps SQL simples. Os backups em formato personalizado são:

  • Comprimidos por padrão — reduzindo significativamente os requisitos de armazenamento
  • Mais rápidos de restaurar — suportando operações de restauração paralela com a flag -j
  • Restauráveis seletivamente — permitindo restaurar tabelas ou esquemas individuais

Criando um Backup em Formato Personalizado

pg_dump -U postgres -W -F c my_production_db > /backups/my_production_db_$(date +%Y%m%d).dump

Criando um Backup em Formato de Diretório Comprimido (Suporta Paralelismo)

pg_dump -U postgres -W -F d -j 4 -f /backups/my_production_db_dir my_production_db
ParâmetroDescrição
-F dFormato de diretório — um ficheiro por tabela
-j 4Usar 4 processos de trabalho paralelos
-f /path/to/dirDiretório de saída (não deve existir ainda)

Esta abordagem reduz dramaticamente a duração do backup em servidores multi-core, tornando-a ideal para os ambientes de servidor dedicado de alto desempenho disponíveis na AlexHost.

6. Restaurar a partir de Dumps SQL

Restaurar uma Base de Dados Única a partir de um Dump SQL Simples

Primeiro, certifique-se de que a base de dados de destino existe. Se não existir, crie-a:

psql -U postgres -c "CREATE DATABASE my_restored_db;"

Depois restaure:

psql -U postgres -d my_restored_db -f /backups/my_production_db_backup.sql

Análise de parâmetros:

ParâmetroDescrição
-U postgresSuperutilizador PostgreSQL
-d my_restored_dbBase de dados de destino para restauração
-f /path/to/file.sqlCaminho para o ficheiro de dump SQL

Monitorizar o Progresso de Restauração

Para ficheiros SQL grandes, pode monitorizar o progresso utilizando pv:

pv /backups/my_production_db_backup.sql | psql -U postgres -d my_restored_db

7. Restaurando a partir de Dumps em Formato Personalizado

Dumps em formato personalizado requerem o utilitário pg_restore em vez de psql.

Restauração Básica

pg_restore -U postgres -d my_restored_db /backups/my_production_db.dump

Restaurar e Criar a Base de Dados Automaticamente

Use a flag -C para instruir pg_restore a criar a base de dados antes de preenchê-la:

pg_restore -U postgres -C -d postgres /backups/my_production_db.dump

Restauração Paralela para Recuperação Mais Rápida

pg_restore -U postgres -d my_restored_db -j 4 /backups/my_production_db_dir/

Usar -j 4 com um backup em formato de diretório pode reduzir o tempo de restauração em até 75% num servidor quad-core — uma vantagem significativa ao minimizar o tempo de inatividade durante a recuperação de desastres.

Restaurar Apenas uma Tabela Específica

pg_restore -U postgres -d my_restored_db -t orders /backups/my_production_db.dump

Esta capacidade granular é uma das principais vantagens do formato personalizado em relação aos dumps SQL simples.

8. Método 4 — Arquivamento Contínuo e Recuperação Point-in-Time (PITR)

PITR é o padrão ouro para implementações PostgreSQL críticas. Permite restaurar sua base de dados para qualquer momento específico — não apenas o último backup — ao reproduzir segmentos Write-Ahead Log (WAL) sobre um backup base. Isto é essencial para cenários onde precisa recuperar de um erro lógico (como um DROP TABLE acidental) que ocorreu num timestamp conhecido.

Passo 1: Ativar Arquivamento WAL em postgresql.conf

Localize e edite seu ficheiro de configuração PostgreSQL:

nano /etc/postgresql/15/main/postgresql.conf

Adicione ou modifique as seguintes diretivas:

# Enable WAL archiving
wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/wal_archive/%f'

Explicação dos parâmetros:

ParâmetroValorDescrição
wal_levelreplicaAtiva detalhe WAL suficiente para arquivamento
archive_modeonAtiva o processo de arquivamento
archive_command'cp %p /path/%f'Comando shell para copiar ficheiros WAL para arquivo

Crie o diretório de arquivo e defina as permissões corretas:

mkdir -p /var/lib/postgresql/wal_archive
chown postgres:postgres /var/lib/postgresql/wal_archive
chmod 700 /var/lib/postgresql/wal_archive

Reinicie PostgreSQL para aplicar as alterações:

systemctl restart postgresql

Passo 2: Fazer um Backup Base com pg_basebackup

pg_basebackup -U postgres -D /backups/base_backup -Ft -z -P -Xs
ParâmetroDescrição
-D /backups/base_backupDiretório de destino para o backup base
-FtSaída em formato Tar
-zComprimir com gzip
-PMostrar progresso
-XsTransmitir WAL durante o backup

Passo 3: Restaurar para um Ponto Específico no Tempo

Para restaurar a partir de um backup base e arquivos WAL:

  1. Pare PostgreSQL:
systemctl stop postgresql
  1. Limpe o diretório de dados existente:
rm -rf /var/lib/postgresql/15/main/*
  1. Extraia o backup base:
tar -xzf /backups/base_backup/base.tar.gz -C /var/lib/postgresql/15/main/
  1. Crie um recovery.conf (PostgreSQL 11 e anteriores) ou configure postgresql.conf e crie um ficheiro recovery.signal (PostgreSQL 12+):
# For PostgreSQL 12+
touch /var/lib/postgresql/15/main/recovery.signal

Adicione a postgresql.conf:

restore_command = 'cp /var/lib/postgresql/wal_archive/%f %p'
recovery_target_time = '2025-01-15 14:30:00'
recovery_target_action = 'promote'
  1. Defina a propriedade correta e inicie PostgreSQL:
chown -R postgres:postgres /var/lib/postgresql/15/main/
systemctl start postgresql

PostgreSQL reproduzirá segmentos WAL até ao timestamp especificado e depois promoverá para um estado normal de leitura-escrita.

9. Automatizar Backups com Cron

Backups manuais são pouco confiáveis. Automatizar seu cronograma de backup com cron garante consistência e remove o fator de erro humano.

Criar um Script de Backup

nano /usr/local/bin/pg_backup.sh
#!/bin/bash

# PostgreSQL Automated Backup Script
BACKUP_DIR="/backups/postgresql"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
DB_USER="postgres"
DB_NAME="my_production_db"
RETENTION_DAYS=14

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Perform the backup
pg_dump -U "$DB_USER" -F c "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Remove backups older than retention period
find "$BACKUP_DIR" -name "*.dump" -mtime +"$RETENTION_DAYS" -delete

# Log completion
echo "[$TIMESTAMP] Backup of $DB_NAME completed successfully." >> /var/log/pg_backup.log

Torne o script executável:

chmod +x /usr/local/bin/pg_backup.sh

Agendar com Cron

crontab -e

Adicione a seguinte linha para executar um backup todas as noites às 2:00 AM:

0 2 * * * /usr/local/bin/pg_backup.sh

Para backups completos semanais mais arquivamento WAL incremental diário, combine isso com a configuração PITR descrita na seção anterior.

10. Protegendo e Armazenando Backups Offsite

Um backup armazenado no mesmo servidor que seu banco de dados de produção não é um backup real — é um ponto único de falha. Implemente as seguintes práticas de segurança e armazenamento offsite:

Criptografar Backups Antes da Transferência

gpg --symmetric --cipher-algo AES256 /backups/my_production_db.dump

Transferir Backups para um Local Remoto com rsync

rsync -avz --progress /backups/postgresql/ user@remote-backup-server:/remote/backups/postgresql/

Usar pg_dump com SSH Pipe para Backup Remoto Direto

pg_dump -U postgres my_production_db | gzip | ssh user@remote-server "cat > /backups/my_production_db_$(date +%Y%m%d).sql.gz"

Regras de Firewall para PostgreSQL (UFW)

Restrinja o acesso à porta PostgreSQL apenas para IPs confiáveis:

ufw allow from 192.168.1.0/24 to any port 5432
ufw deny 5432
ufw enable

Para equipes que gerenciam múltiplos projetos em diferentes níveis de hospedagem, os planos de Hospedagem Web Compartilhada AlexHost também suportam ferramentas de gerenciamento de banco de dados que podem complementar seus fluxos de trabalho de backup para projetos menores.

11. Resumo das Melhores Práticas

Implementar backups PostgreSQL corretamente requer disciplina e uma abordagem em camadas. Siga estas melhores práticas para garantir que seus dados estejam sempre protegidos:

PráticaRecomendação
Frequência de backupNo mínimo diariamente; por hora para bancos de dados com alto volume de transações
Formatos de backupUse formato customizado (-F c) para bancos de dados > 1 GB
Política de retençãoMantenha 14 backups diários, 4 semanais e 3 mensais
VerificaçãoRestaure para um ambiente de teste mensalmente para validar integridade
EncriptaçãoSempre encripte backups antes da transferência offsite
Armazenamento offsiteMantenha backups em pelo menos uma localização geograficamente separada
MonitoramentoAlerte sobre falhas de trabalhos de backup via email ou sistema de monitoramento
PITR para produçãoAtive o arquivamento WAL em todos os bancos de dados críticos para a missão
DocumentaçãoMantenha um runbook escrito para procedimentos de restauração

> Lembrete crítico: Um backup que nunca foi testado não é um backup — é uma suposição. Agende testes de restauração regulares e documente os resultados.

Conclusão: Proteja os Seus Dados PostgreSQL com Confiança na AlexHost

PostgreSQL oferece um dos conjuntos de backup e recuperação mais abrangentes de qualquer sistema de banco de dados open-source. Desde a simplicidade de pg_dump para snapshots SQL rápidos até a precisão cirúrgica de PITR para recuperação granular point-in-time, você tem tudo o que precisa para construir uma estratégia de proteção de dados à prova de balas.

A chave é a execução: automatize seus backups, verifique-os regularmente, criptografe-os antes da transferência e armazene-os fora do local. Combinado com o desempenho e confiabilidade dos Servidores Dedicados AlexHost — com armazenamento NVMe, acesso root completo e proteção DDoS de nível empresarial — seus bancos de dados PostgreSQL serão rápidos e resilientes.

Para equipes que precisam de infraestrutura escalável sem a sobrecarga de gerenciar bare metal, Hospedagem VPS AlexHost oferece uma alternativa flexível e econômica com o mesmo compromisso com desempenho e uptime. E se você precisa proteger suas aplicações web baseadas em banco de dados de ponta a ponta, combinar sua hospedagem com Certificados SSL AlexHost garante comunicação criptografada entre sua camada de aplicação e seus usuários.

Comece a implementar essas estratégias de backup hoje. Seu eu futuro — enfrentando um incidente às 3 da manhã com um banco de dados de produção corrompido — agradecerá por isso.