Dedup Paralela Bacula: Setup Side-by-Side Sem Downtime | 2026

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

Jonas Oliveira 1 de janeiro de 2026
Como Configurar Dedup Paralela no Bacula Enterprise

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:

  1. ✅ Backup do catálogo atual (make_catalog_backup.pl)
  2. ✅ Espaço em disco suficiente em /backup e /index
  3. ✅ Janela de manutenção agendada (para restart do Storage Daemon)
  4. ✅ 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.
ComponenteConfiguração ANTIGA (Legado)Configuração NOVA (Produção)
Diretórios (Linux)/backup | /index/backup/dedup_novo | /index/dedup_novo
Dedup EngineDedup2DedupEngine_NOVO
Devices (Storage Daemon)Dedup01-01, -02…Device_Dedup_NOVO_01 Device_Dedup_NOVO_02 Device_Dedup_NOVO_03
Media Typededup1DedupType_NOVO ⚠️ CRÍTICO: Deve ser único
AutochangerDedup01Dedup_Autochanger_NOVO
Storage (Director)Dedup01Storage_Dedup_NOVO
PoolsDiskBackup365d, 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)

  1. Vá na aba Dedupengines.
  2. Selecione o motor existente (ex: Dedup2) e clique em Copy.
  3. Edite os campos fundamentais:
    • Name: DedupEngine_NOVO
    • Dedup Directory: /backup/dedup_novo
    • Dedup Index Directory: /index/dedup_novo
  4. 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).
  1. Vá na aba Devices.
  2. Selecione um device existente (ex: Dedup01-01) e clique em Copy.
  3. 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
  4. Clique em Save.
  5. 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ô)

  1. Vá na aba Autochangers.
  2. Selecione o autochanger existente e clique em Copy.
  3. Edite:
    • Name: Dedup_Autochanger_NOVO
    • Devices:
      • Na lista da direita (“Selected”), remova os devices antigos.
      • Adicione TODOS os novos devices (_01, _02, _03).
  4. 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)

  1. Vá na aba Storage.
  2. Use a função Copy no Storage antigo.
  3. 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.
  4. 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.
  1. Vá na aba Pools.
  2. 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 < <(find "$d" -maxdepth 1 -type f -name "*.cfg" -print0)
  fi
done

CHANGED=0
for f in "${FILES[@]}"; do
  if [ -f "$f" ]; then
      before="$(cat -- "$f")"
      after="$(perl -0777 -pe "$(printf '%s' "${PERL_RULES[@]}")" -- "$f")"
      
      if [[ "$before" != "$after" ]]; then
        CHANGED=$((CHANGED+1))
        if [[ "$DRY_RUN" -eq 1 ]]; then
             echo "   >>> MUDANÇA NECESSÁRIA EM: $(basename "$f") <<<"
             # Deve mostrar apenas uma aspa no final agora
             diff <(echo "$before") <(echo "$after") | grep ">" || 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

  1. Media Type deve ser único: Nunca use o mesmo Media Type do ambiente antigo.
  2. Sempre faça backup antes: O script cria backups automáticos, mas valide manualmente.
  3. Execute em modo simulação primeiro: DRY_RUN=1 evita mudanças acidentais.
  4. 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)

🔗 Recursos Relacionados

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

📚 Você Também Pode Gostar
🎓 Continue Aprendendo com Nossos Simulados

Simulados gratuitos para AWS, Linux, CompTIA e Microsoft Azure

Tag
Avatar de Jonas Oliveira
Jonas Oliveira
Ver mais postagens
Jonas Oliveira é especialista em tecnologia e redator no TecMestre.