Proxmox Backup Server: Backups Deduplicados para PME

1. Introdução

O Proxmox Backup Server (PBS) é uma solução de backup enterprise-class, client-server, capaz de fazer backups de máquinas virtuais, containers e hosts físicos. É especialmente optimizado para a plataforma Proxmox Virtual Environment (PVE) e permite armazenar dados de forma segura, mesmo entre sites remotos, com gestão através de uma interface web.

Escrito integralmente em Rust, o PBS oferece deduplicação, compressão e encriptação autenticada (AE). A comunicação cliente-servidor usa TLS, e os dados podem ser encriptados no lado do cliente antes do envio, tornando seguro fazer backups para destinos que não são totalmente confiáveis. Todo o código é open-source sob licença AGPL v3, sem limites artificiais de armazenamento ou clientes.

Para uma PME que já usa Proxmox VE, o PBS é o complemento natural: integra-se nativamente desde o PVE 6.3, permite backups incrementais com detecção de alterações ao nível de bloco, e oferece verificação de integridade baseada em SHA-256. Este guia cobre a instalação, configuração, operação e boas práticas do PBS, com base na documentação oficial do Proxmox Backup Server (versão 4.2.4).

2. Arquitectura do PBS

O PBS usa um modelo client-server. O servidor armazena os dados de backup e fornece uma API para criar e gerir datastores. O cliente (proxmox-backup-client) envia dados para o servidor e também é usado para restaurar ficheiros.

2.1 Chunks e Deduplicação

A deduplicação do PBS baseia-se na reutilização de chunks — blocos de dados identificados pelo checksum SHA-256 do seu conteúdo. Existem dois tipos de chunking:

• Chunks de tamanho fixo (tipicamente 4 MiB): usados para backups de VMs (imagens de disco). O PVE pode usar dirty bitmaps do QEMU para identificar apenas os blocos modificados, evitando a necessidade de snapshots de armazenamento.
• Chunks de tamanho dinâmico: usados para backups de ficheiros (containers, hosts físicos). Um algoritmo rolling hash (variante de Buzhash) calcula os limites dos chunks, permitindo que ficheiros não alterados produzam os mesmos checksums e sejam reutilizados.

Cada snapshot de backup referencia os chunks necessários. Vários snapshots podem partilhar os mesmos chunks, reduzindo o espaço de armazenamento. Como cada snapshot referencia todos os chunks, todos os backups são effectively full backups — mas apenas os chunks novos são transferidos.

2.2 Encriptação

Os chunks encriptados são um caso especial. O hash é calculado sobre o conteúdo em texto simples concatenado com a chave de encriptação, não sobre o conteúdo encriptado. Isto garante que chunks com os mesmos dados mas encriptados com chaves diferentes produzam checksums diferentes, evitando colisões. Apenas os chunks que efectivamente precisam de ser enviados são encriptados — os que já existem no backup anterior não precisam de ser encriptados nem transferidos.

2.3 Estrutura de Directórios

Os chunks são armazenados em <datastore-root>/.chunks/, subdivididos em directórios agrupados pelo prefixo de 2 bytes do checksum (4 dígitos hexadecimais), ex: .chunks/a342/. Estes directórios (0000-ffff) são pré-alocados na criação do datastore para reduzir o número de ficheiros por directório.

3. Instalação

3.1 Requisitos do Sistema

Para produção, o PBS requer hardware de qualidade. Os requisitos recomendados pela documentação oficial:

3.2 Instalação via ISO

O método recomendado é usar a imagem ISO de instalação, disponível em proxmox.com/downloads. A ISO é uma imagem híbrida que pode ser gravada num DVD ou copiada para uma pen USB com dd:

# Copiar a ISO para uma pen USB (Linux)
dd bs=1M conv=fdatasync if=./proxmox-backup-server_*.iso of=/dev/sdX

Após arrancar pelo medium de instalação, o instalador gráfico orienta a configuração do target de instalação, fuso horário, teclado, password de root e rede. O instalador instala um Debian completo com todos os pacotes necessários.

3.3 Instalação sobre Debian

Alternativamente, o PBS pode ser instalado sobre um Debian existente adicionando o repositório de pacotes:

# Adicionar o repositório no-subscription
echo "deb http://download.proxmox.com/debian/pbs $(. /etc/os-release; echo $VERSION_CODENAME) pbs-no-subscription" \
  > /etc/apt/sources.list.d/pbs.list

# Adicionar a chave GPG
wget https://enterprise.proxmox.com/debian/proxmox-release-$(. /etc/os-release; echo $VERSION_CODENAME).gpg \
  -O /etc/apt/trusted.gpg.d/proxmox-release-$(. /etc/os-release; echo $VERSION_CODENAME).gpg

# Instalar
apt update && apt install proxmox-backup-server

Também é possível executar o PBS dentro de uma VM no próprio Proxmox VE, útil para ambientes pequenos, embora a documentação oficial recomende hardware dedicado para produção.

3.4 Repositórios de Pacotes

4. Configuração de Datastore

Um datastore é o local lógico onde os backups são armazenados. A implementação actual usa um directório num sistema de ficheiros standard (ext4, XFS ou ZFS). Cada datastore é identificado por um ID simples e a sua configuração é guardada em /etc/proxmox-backup/datastore.cfg.

4.1 Criar um Datastore via CLI

Pode criar um datastore formatando um disco e criando automaticamente o datastore:

# Criar filesystem ext4 e datastore automaticamente
proxmox-backup-manager disk fs create store1 \
  --disk sdX --filesystem ext4 --add-datastore true

# Ou criar um zpool mirrored e datastore
proxmox-backup-manager disk zpool create zpool1 \
  --devices sdX,sdY --raidlevel mirror --add-datastore true

Para criar um datastore sobre um directório existente:

proxmox-backup-manager datastore create store1 \
  /mnt/datastore/store1 \
  --gc-schedule "03:00" \
  --prune-schedule "24:00"

4.2 Opções de Configuração

Ao configurar um datastore, pode definir:

• Name — identificador único do datastore
• Backing Path — caminho no sistema de ficheiros
• GC Schedule — periodicidade do garbage collection
• Prune Schedule — periodicidade do prune automático
• Prune Options — política de retenção (keep-last, keep-daily, etc.)
• Comment — descrição contextual

4.3 Backup Namespaces

Os namespaces permitem organizar backups dentro de um datastore, criando partições lógicas. São úteis para separar backups de diferentes clientes, ambientes ou equipas, mantendo a deduplicação ao nível do datastore inteiro. Cada namespace pode ter as suas próprias políticas de prune e permissões de acesso.

4.4 Protecção contra Ransomware

O PBS inclui protecção integrada contra ransomware. A documentação oficial destaca o seguimento da regra 3-2-1: manter 3 cópias dos dados, em 2 media diferentes, com 1 cópia off-site. O PBS suporta isto nativamente através de sync remoto (apenas deltas são transferidos) e backup para fita LTO. A verificação de integridade SHA-256 e o controlo de acesso granular com utilizadores e permissões restritivas complementam a estratégia de defesa.

5. Jobs de Backup via PVE

O Proxmox VE tem integração nativa com o PBS desde a versão 6.3. O PBS é adicionado como um storage do tipo pbs no Datacenter, permitindo fazer backup de VMs e containers da mesma forma que com qualquer outro storage.

5.1 Adicionar PBS via Interface Web

No PVE, navegar para Datacenter → Storage → Add → Proxmox Backup Server. Preencher:

• ID — nome do storage no PVE
• Server — endereço do PBS
• Datastore — nome do datastore no PBS
• Username — utilizador no PBS (ex: user1@pbs)
• Password — palavra-passe do utilizador
• Fingerprint — fingerprint do certificado do PBS (necessário para self-signed)

5.2 Adicionar PBS via CLI

# Adicionar o storage do tipo pbs
pvesm add pbs store2 --server 192.168.1.100 --datastore store1
pvesm set store2 --username user1@pbs --password

# Obter o fingerprint no servidor PBS
proxmox-backup-manager cert info | grep Fingerprint

# Adicionar o fingerprint (para certificados self-signed)
pvesm set store2 --fingerprint 64:d3:ff:3a:50:38:53:5a:9b:f7:50:...:ab:fe

# Verificar o estado do storage
pvesm status --storage store2

5.3 Criar Jobs de Backup

Após adicionar o PBS como storage, criar jobs de backup em Datacenter → Backup. Pode agendar backups para seleccionar VMs/containers, definir o modo (full ou incremental), definir a compressão e configurar notificações. O PVE envia os dados para o PBS, que se encarrega da deduplicação e armazenamento.

Para VMs, o PVE usa dirty bitmaps do QEMU para identificar blocos modificados desde o último backup. Apenas esses blocos são lidos e enviados ao PBS, tornando o backup incremental sem necessidade de snapshots de armazenamento. Para consistência, o PVE usa o mecanismo de snapshot interno do QEMU.

5.4 Modos de Detecção de Alterações

Para backups de ficheiros (containers e hosts físicos), o PBS oferece três modos de detecção de alterações:

6. Prune, Verify e Garbage Collection

6.1 Prune — Políticas de Retenção

O prune permite especificar quais os snapshots a manter, removendo os restantes. Ao podar um snapshot, apenas os metadados (manifesto, índices, blobs, logs e notas) são removidos. Os chunks que continham os dados do snapshot podado têm de ser removidos pelo garbage collection.

As opções de retenção disponíveis são:

As opções são processadas pela ordem acima. Cada opção cobre apenas backups dentro do seu período temporal. A próxima opção apenas considera backups mais antigos não cobertos.

6.2 Exemplo de Retenção

Para backups diários com retenção de 10 anos e crescimento gradual do intervalo entre backups:

# Exemplo de retenção para backups diários
keep-last: 3
keep-daily: 13
keep-weekly: 8
keep-monthly: 11
keep-yearly: 9

Isto garante pelo menos 2 semanas de backups diários, 2 meses de backups semanais, 1 ano de backups mensais e 9 anos de arquivo de longo prazo. O keep-last: 3 protege contra eliminações acidentais de backups manuais extra antes ou após upgrades.

6.3 Garbage Collection

O garbage collection (GC) remove os chunks que já não são referenciados por nenhum snapshot. O GC pode ser executado em background (GC Background), iniciado manualmente ou agendado. Os chunks não referenciados são marcados para eliminação e removidos numa execução subsequente após um período de tolerância (grace period), para segurança.

# Iniciar garbage collection manualmente
proxmox-backup-manager garbage-collection start store1

# Verificar o estado do último GC
proxmox-backup-manager garbage-collection status store1

6.4 Verificação de Integridade

O PBS pode verificar a integridade dos dados de backup, lendo cada chunk e confirmando que o checksum SHA-256 corresponde ao esperado. Esta verificação é essencial para detectar corrupção de dados (bit rot) e garantir que os backups são restauráveis. A verificação pode ser agendada ou executada manualmente a partir da interface web ou CLI.

# Verificar um datastore completo
proxmox-backup-manager verify store1

# Verificar um snapshot específico
proxmox-backup-client verify host/elsa/2026-01-15T09:30:00Z

7. Restore Granular

A criação regular de backups é necessária, mas a restauração é o que realmente importa. A documentação oficial recomenda testes periódicos de recuperação para garantir acesso aos dados em caso de desastre. O PBS oferece várias formas de restore, desde a restauração completa de uma VM até à recuperação de um único ficheiro.

7.1 Listar Snapshots

# Listar todos os snapshots no servidor
proxmox-backup-client snapshot list

# Output:
# snapshot                          size        files
# host/elsa/2026-01-15T09:30:15Z    51788646825 root.pxar catalog.pcat1 index.json
# host/elsa/2026-01-16T09:30:00Z    51790622048 root.pxar catalog.pcat1 index.json

7.2 Restore de um Ficheiro Completo

Para restaurar um ficheiro completo de um snapshot:

# Restaurar o arquivo root.pxar para um caminho
proxmox-backup-client restore host/elsa/2026-01-15T09:30:15Z root.pxar /target/path/

# Dump do manifesto para stdout
proxmox-backup-client restore host/elsa/2026-01-15T09:30:15Z index.json -

7.3 Restore Interactivo

Para restaurar apenas alguns ficheiros individuais, o PBS oferece uma shell interactiva de recuperação. Esta shell usa o catálogo de metadata (catalog.pcat1) para listar, navegar e procurar ficheiros rapidamente, sem precisar de descarregar todos os chunks:

# Iniciar a shell interactiva
proxmox-backup-client catalog shell host/elsa/2026-01-15T09:30:15Z root.pxar

# Shell interactiva:
pxar:/ > ls
bin boot dev etc home lib lib32 ...
pxar:/ > find etc/**/*.conf --select
pxar:/ > restore etc/hosts /tmp/restored/

Os comandos cd e ls navegam no arquivo, pwd mostra o directório actual e find procura ficheiros com padrões glob. O catálogo é pequeno e pode ser descarregado rapidamente; os chunks de dados só são acedidos quando necessário para o restore.

7.4 Restore de VMs no PVE

No Proxmox VE, o restore de VMs e containers a partir do PBS é feito da mesma forma que com qualquer outro storage. A partir da interface web, seleccionar o snapshot e clicar em Restore. É possível restaurar a VM completa ou usar o file restore para montar um disco virtual e extrair ficheiros individuais através do proxmox-file-restore.

7.5 Mount via FUSE

Os ficheiros pxar também podem ser montados via FUSE, permitindo acesso aos ficheiros como num sistema de ficheiros normal:

# Montar um arquivo via FUSE
proxmox-backup-client mount host/elsa/2026-01-15T09:30:15Z root.pxar /mnt/restore

# Aceder aos ficheiros
ls /mnt/restore/etc/hosts
cat /mnt/restore/etc/fstab

# Desmontar
fusermount -u /mnt/restore

8. Boas Práticas

8.1 Armazenamento

• Usar SSDs enterprise para o datastore principal, garantindo IOPS elevados para workloads de deduplicação.
• Se usar HDDs, adicionar um ZFS special device mirror como metadata cache para melhorar o desempenho de I/O aleatório.
• Considerar ZFS para o datastore, com redundância (mirror ou RAID-Z) para proteger contra falhas de disco.
• Dimensionar a RAM: 4 GiB base + 1 GiB por TiB de armazenamento, conforme a documentação oficial.

8.2 Retenção e Prune

• Definir uma política de retenção com crescimento gradual de intervalos (ex: keep-last 3, keep-daily 13, keep-weekly 8, keep-monthly 11, keep-yearly 9).
• Agendar o prune para executar após os backups (ex: prune às 24:00, backup à meia-noite).
• Usar o Prune Simulator da interface web para visualizar o efeito das políticas antes de aplicar.

8.3 Garbage Collection

• Agendar o GC regularmente (ex: diariamente às 03:00) para libertar espaço de chunks não referenciados.
• Monitorizar o tempo de execução do GC — se aumentar significativamente, pode indicar fragmentação ou problemas de performance.

8.4 Verificação de Integridade

• Agendar verificações de integridade pelo menos mensalmente para detectar corrupção de dados.
• Para datastores grandes, agendar verificações semanais de subconjuntos (por namespace ou grupo de backup).

8.5 Segurança

• Activar encriptação client-side (AES-256-GCM) para backups que contenham dados sensíveis.
• Usar utilizadores dedicados com permissões restritas para cada cliente de backup, seguindo o princípio do menor privilégio.
• Configurar autenticação de dois factores (TFA) para acesso administrativo ao PBS.
• Usar certificados Let’s Encrypt (ACME) ou pessoais para TLS, evitando certificados self-signed em produção.

8.6 Estratégia 3-2-1

• Manter pelo menos 3 cópias dos dados (produção + 2 backups).
• Usar 2 media diferentes (disco + fita LTO, ou disco local + sync remoto).
• Ter pelo menos 1 cópia off-site via sync remoto para um PBS num local físico diferente.
• Testar a recuperação periodicamente — um backup não testado não é um backup confiável.