Como Configurar Dedup Paralela no Bacula Enterprise (Setup Side-by-Side)

A configuração de dedup paralela bacula (Deduplicação Global) permite otimizar drasticamente o armazenamento e a velocidade dos seus backups corporativos.

Este guia técnico detalha o procedimento para construção de um ambiente de deduplicação paralelo e isolado (Side-by-Side) no Bacula Enterprise. O objetivo é permitir a migração segura dos dados sem impactar o ambiente legado.

Para mais informações, consulte a documentação oficial Bacula.

🎯 O que Você Vai Conseguir

- ✅ **Migração sem downtime:** Ambiente antigo e novo rodando lado a lado
- ✅ **Rollback seguro:** Se algo der errado, volta para o legado em segundos
- ✅ **Testes em produção:** Valide o novo storage com Jobs reais antes de migrar tudo

⚠️ Riscos e Cuidados

- 🚨 **Media Type duplicado:** Se usar o mesmo Media Type do legado, o Bacula vai tentar montar Volumes errados (pode corromper dados)
- ⚠️ **Espaço em disco:** Você precisará de espaço para **ambos** os ambientes durante a migração

📋 Checklist Pré-Migração

Antes de começar, confirme:

- ✅ Backup do catálogo atual (make_catalog_backup.pl)
- ✅ Espaço em disco suficiente em /backup e /index
- ✅ Janela de manutenção agendada (para restart do Storage Daemon)
- ✅ Documentação da estrutura atual (pools, jobs, schedules)

🏗️ 1. Definição de Nomenclatura

Esta tabela define o padrão "De/Para" utilizado em todo o projeto. O isolamento é garantido pelo uso de diretórios e Media Types exclusivos.

Componente
Configuração ANTIGA (Legado)
Configuração NOVA (Produção)

Diretórios (Linux)
/backup | /index
/backup/dedup_novo | /index/dedup_novo

Dedup Engine
Dedup2
DedupEngine_NOVO

Devices (Storage Daemon)
Dedup01-01, -02...
Device_Dedup_NOVO_01
Device_Dedup_NOVO_02
Device_Dedup_NOVO_03

Media Type
dedup1
DedupType_NOVO ⚠️ CRÍTICO: Deve ser único

Autochanger
Dedup01
Dedup_Autochanger_NOVO

Storage (Director)
Dedup01
Storage_Dedup_NOVO

Pools
DiskBackup365d, etc.
DiskBackup365d_NOVO (Sufixo _NOVO)

📦 Passo 1: Preparação Física (Linux)

⚠️ ATENÇÃO: A parada do serviço Storage Daemon é obrigatória. Criar pastas com o serviço rodando pode causar problemas de permissão ou travamento de processos filhos.
Acesse o servidor via SSH como root e execute:

# 1. Parar o serviço para segurança
systemctl stop bacula-sd

# 2. Criar a estrutura de diretórios isolada
mkdir -p /backup/dedup_novo
mkdir -p /index/dedup_novo

# 3. Aplicar permissões (Usuário do Bacula deve ser dono)
chown -R bacula:tape /backup/dedup_novo /index/dedup_novo
chmod 775 /backup/dedup_novo /index/dedup_novo

# 4. Verificar se foi criado corretamente
ls -ld /backup/dedup_novo /index/dedup_novo

🔧 Passo 2: Configuração no BWeb (Storage Daemon)

Nesta etapa, criamos os "Hardwares Virtuais" no arquivo bacula-sd.conf.

Caminho: Configuration » Storage Daemon (bacula01-sd)

A) Criar o Dedup Engine (Motor)

- Vá na aba **Dedupengines**.
- Selecione o motor existente (ex: Dedup2) e clique em **Copy**.
- Edite os campos fundamentais:

**Name:** DedupEngine_NOVO
- **Dedup Directory:** /backup/dedup_novo
- **Dedup Index Directory:** /index/dedup_novo


- Clique em **Save**.

B) Criar os Devices (Múltiplos Dispositivos)

Criamos múltiplos devices para permitir concorrência (vários jobs rodando ao mesmo tempo).

- Vá na aba **Devices**.
- Selecione um device existente (ex: Dedup01-01) e clique em **Copy**.
- Edite o **Primeiro Device:**

**Name:** Device_Dedup_NOVO_01
- **Media Type:** DedupType_NOVO ⚠️ **OBRIGATÓRIO MUDAR**
- **Archive Device:** /backup/dedup_novo
- **Dedup Engine:** Selecione DedupEngine_NOVO


- Clique em **Save**.
- Repita o processo (Copy/Paste) para criar:

Device_Dedup_NOVO_02
- Device_Dedup_NOVO_03

Nota: Todos devem ter o mesmo Media Type e apontar para o mesmo Engine.

C) Criar o Autochanger (Robô)

- Vá na aba **Autochangers**.
- Selecione o autochanger existente e clique em **Copy**.
- Edite:

**Name:** Dedup_Autochanger_NOVO
- **Devices:**

Na lista da direita ("Selected"), **remova os devices antigos**.
- Adicione **TODOS os novos devices** (_01, _02, _03).


- Clique em **Save**.

⚙️ Passo 3: Configuração no BWeb (Director)

Nesta etapa, criamos a lógica de controle no arquivo bacula-dir.conf.

Caminho: Configuration » Director » Storage

A) Criar o Storage (O Ponteiro)

- Vá na aba **Storage**.
- Use a função **Copy** no Storage antigo.
- Edite os campos com atenção especial (pois os nomes novos ainda não aparecem nas listas):

**Storage Name:** Storage_Dedup_NOVO
- **Device:** Dedup_Autochanger_NOVO (Digite manualmente, idêntico ao Passo 2C).
- **Media Type:** DedupType_NOVO (Digite manualmente).
- **Autochanger:** Marque a opção **Yes**.


- Clique em **Save**.

B) Criar as Pools (Espelhamento de Produção)

Devemos criar uma versão "NOVA" para cada Pool que existe hoje e usa deduplicação.

- Vá na aba **Pools**.
- Para cada Pool (ex: DiskBackup365d, Poll_DB_30_dias):

Selecione e clique em **Copy**.
- **Name:** Adicione o sufixo _NOVO (ex: DiskBackup365d_NOVO).
- **Storage:** Selecione Storage_Dedup_NOVO.
- **Label Format:** Altere para VolNovo- (Facilita auditoria visual).
- Salve.

✅ Passo 4: Finalização e Validação

1. Aplicar Configurações

- No BWeb: **Commit / Write Configuration**.
- No BWeb: **Reload Director**.
- No Terminal: systemctl restart bacula-sd

2. Comandos de Validação (Terminal)

# Verifica se o Director aponta para o Autochanger correto
grep -r "Device" /opt/bacula/etc/ | grep "Storage_Dedup_NOVO"
# Saída Esperada: Device = "Dedup_Autochanger_NOVO"

# Verifica se o Motor de Dedup subiu e está "ouvindo"
echo "dedup usage storage=Storage_Dedup_NOVO" | bconsole
# Saída Esperada: Status do DedupEngine_NOVO com data/hora atual.

🚀 Passo 5: Automação da Migração (Script Definitivo)

Este script realiza a migração em massa, alterando Jobs, JobDefs e Schedules. Ele suporta mapeamento de múltiplas pools e regras de agendamento (FullPool/IncPool).

Script: migrar_producao.sh

Copie o código abaixo, salve no servidor, dê permissão de execução (chmod +x) e execute.

#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# 1. CONFIGURAÇÃO
# ==============================================================================
DIR_BASE="/opt/bacula/etc/conf.d/Director/bacula01-dir"
STORAGE_ANTIGO="Dedup01"
STORAGE_NOVO="Storage_Dedup_NOVO"

POOL_MAP=(
  "CatalogBackup14d:CatalogBackup14d_NOVO"
  "Poll_DB_30_dias:Poll_DB_30_dias_NOVO"
  "Poll_VM-PROX_30_dias:Poll_VM-PROX_30_dias_NOVO"
  "Poll_VM-ESXI_90_dias:Poll_VM-ESXI_90_dias_NOVO"
  "Poll_VM-PROX_90_dias:Poll_VM-PROX_90_dias_NOVO"
  "DiskBackup365d:DiskBackup365d_NOVO"
  "DiskBackup5anos:DiskBackup5anos_NOVO"
)

# 1 = SIMULAÇÃO | 0 = APLICAR
DRY_RUN=1

# ==============================================================================
# 2. MOTOR DE MIGRAÇÃO (REGEX CORRIGIDO PARA ASPAS)
# ==============================================================================
TARGET_DIRS=("$DIR_BASE/Job" "$DIR_BASE/JobDefs" "$DIR_BASE/Schedule")

backup_file() {
  local f="$1"
  local bkp="${f}.bkp_migracao"
  if [[ -e "$bkp" ]]; then
    local n=1
    while [[ -e "${bkp}.${n}" ]]; do n=$((n+1)); done
    bkp="${bkp}.${n}"
  fi
  cp -a -- "$f" "$bkp"
}

apply_perl() {
  local f="$1"
  shift
  if [[ "$DRY_RUN" -eq 1 ]]; then
    echo "  [SIMULACAO] Alteraria: $(basename "$f")"
  else
    backup_file "$f"
    perl -0777 -i -pe "$@" -- "$f"
    echo "  [APLICADO] Atualizado: $(basename "$f")"
  fi
}

echo "=== MIGRAÇÃO FINAL (IDEMPOTENTE + FIX ASPAS) ==="
echo "Proteção ativa: Ignora pools já migradas."

PERL_RULES=()

# 1. Storage (Corrigido escape para o bash)
PERL_RULES+=("s/(bStorages*=s*)"?Q$STORAGE_ANTIGOEb"?/${1}"$STORAGE_NOVO"/mg;")

# 2. Pools
for map in "${POOL_MAP[@]}"; do
  OLD="${map%%:*}"
  NEW="${map##*:}"

  # AQUI ESTÁ A CORREÇÃO: b antes de "?
  # Isso garante que ele consome a aspa original, evitando duplicidade

  # Regras Genéricas
  PERL_RULES+=("s/(bPools*=s*)"?Q$OLDEb"?/${1}"$NEW"/g;")
  PERL_RULES+=("s/(bFullPools*=s*)"?Q$OLDEb"?/${1}"$NEW"/g;")
  PERL_RULES+=("s/(bIncrementalPools*=s*)"?Q$OLDEb"?/${1}"$NEW"/g;")
  PERL_RULES+=("s/(bDifferentialPools*=s*)"?Q$OLDEb"?/${1}"$NEW"/g;")
  PERL_RULES+=("s/(bNexts*Pools*=s*)"?Q$OLDEb"?/${1}"$NEW"/g;")

  # Regras Verbose
  PERL_RULES+=("s/(^s*Fulls+Backups+Pools*=s*)"?Q$OLDEb"?/${1}"$NEW"/mg;")
  PERL_RULES+=("s/(^s*Differentials+Backups+Pools*=s*)"?Q$OLDEb"?/${1}"$NEW"/mg;")
  PERL_RULES+=("s/(^s*Incrementals+Backups+Pools*=s*)"?Q$OLDEb"?/${1}"$NEW"/mg;")
done

FILES=()
for d in "${TARGET_DIRS[@]}"; do
  if [[ -d "$d" ]]; then
    while IFS= read -r -d '' f; do FILES+=("$f"); done >> MUDANÇA NECESSÁRIA EM: $(basename "$f") " || true
             echo "   -----------------------------------------"
        fi
        apply_perl "$f" "$(printf '%s' "${PERL_RULES[@]}")"
      fi
  fi
done

echo "--------------------------------------------------------"
if [[ "$DRY_RUN" -eq 1 ]]; then
    echo "FIM DA SIMULAÇÃO."
    if [[ "$CHANGED" -gt 0 ]]; then
        echo "✅ Verifique se as aspas estão corretas (apenas uma)."
        echo "   Se sim, mude DRY_RUN=0 e execute."
    else
        echo "✅ Tudo pronto! Nenhuma alteração pendente."
    fi
else
    echo "SUCESSO: $CHANGED arquivos atualizados."
    echo "Execute 'reload' no bconsole."
fi

📊 Como Executar o Script

# 1. Salvar o script
nano migrar_producao.sh
# Cole o conteúdo acima

# 2. Dar permissão de execução
chmod +x migrar_producao.sh

# 3. Executar em modo SIMULAÇÃO (DRY_RUN=1)
./migrar_producao.sh

# 4. Se tudo estiver correto, editar e mudar DRY_RUN=0
nano migrar_producao.sh  # Alterar linha: DRY_RUN=0

# 5. Aplicar as mudanças
./migrar_producao.sh

# 6. Recarregar o Director
echo "reload" | bconsole

⚠️ Pontos Críticos de Atenção

- **Media Type deve ser único:** Nunca use o mesmo Media Type do ambiente antigo.
- **Sempre faça backup antes:** O script cria backups automáticos, mas valide manualmente.
- **Execute em modo simulação primeiro:** DRY_RUN=1 evita mudanças acidentais.
- **Valide as aspas:** O script corrige aspas duplicadas, mas sempre confira a saída.

❓ FAQ

Posso rodar o ambiente antigo e novo simultaneamente?

Sim! Esse é o objetivo do setup Side-by-Side. Você migra Jobs gradualmente enquanto o legado continua funcionando.

O que acontece se eu usar o mesmo Media Type?

O Bacula vai tentar usar Volumes do ambiente antigo, causando erros de montagem e possivelmente corrupção de dados.

Preciso parar todos os Jobs para aplicar?

Não. Após criar a estrutura nova, você migra Jobs individualmente. O ambiente antigo continua operacional.

📚 Veja Também (Tutoriais Bacula Enterprise)

- [Como Restaurar Backup de Job Prunado (bscan e bextract)](https://tecmestre.com.br/restaurar-job-prunado-bacula-bscan-bextract/)
- [Erro "Unsupported Proxmox version" - Solução Completa](https://tecmestre.com.br/erro-unsupported-proxmox-version-bacula-plugin/)
- [Configurar Deduplicação Paralela (Side-by-Side)](https://tecmestre.com.br/configurar-dedup-paralela-bacula-side-by-side/)
- [Migração Completa para Oracle Cloud (OCI)](https://tecmestre.com.br/migracao-bacula-enterprise-oracle-cloud-oci/)
- [10 Devices Paralelos para 50 Jobs Simultâneos](https://tecmestre.com.br/configurar-10-devices-paralelos-bacula-alta-concorrencia/)

🔗 Recursos Relacionados

- [Documentação Oficial Bacula Enterprise - Deduplicação](https://www.baculasystems.com/documentation-downloads/)
- [Mais tutoriais de Bacula no TecMestre](https://tecmestre.com.br/bacula-enterprise/)

Última atualização: Janeiro de 2026 | Testado no Bacula Enterprise 18.2.1

---

Originally published at https://tecmestre.com.br