bsplitter – Divisão Dinâmica de FileSets do Bacula para Backups paralelos

Este script permite listar dinamicamente subdiretórios e arquivos de um diretório de backup, divindo listas de arquivos para backup classificadas por tamanho.
No exemplo do comando:

/opt/bacula/scripts/bsplitter 3 1 /var/lib/pgsql

• “3” é o número total de Jobs e FileSets. Estes precisam ser criados manualmente pelo administrador, e devem ser configurados para execução em paralelo.
• “1” é a parcela do backup que será realizado. Então para cada FileSet, você modificará a parcela que será backupeada. Exemplo:

FileSet1: bsplitter 3 1 /var/lib/pgsql
FileSet2: bsplitter 3 2 /var/lib/pgsql
FileSet3: bsplitter 3 3 /var/lib/pgsql

• “/var/lib/pgsql” é o diretório cujo conteúdo do backup será fracionado em parcelas.

Se estiver usando BWeb, como na Figura 1, basta chamar o script a seguir no campo Include do FileSet:

Figura 1. No BWeb, basta inserir no Include: \|/opt/bacula/scripts/bsplitter 3 1 /var/lib/pgsql

Segue o script, a ser salvo idealmente no caminho “/opt/bacula/scripts/bsplitter” de seu host Cliente do backup.

#!/bin/bash
#
# Autoria: Heitor Faria (Copyleft: all rights reversed).
# Orientador: Prof. Julio Neves (http://www.livrate.com.br/).
# Testador: xxxx
#
# Deve ser chamado no sub-recurso INCLUDE do FileSet do bacula-dir.conf, referente ao backup do cliente instalado que deseja fracionar a quantidade de subdiretórios:
#
# File = "\\|/opt/bacula/scripts/bsplitter 3 1 /var/lib/pgsql"
#                            <parallelism><parcel><dir_to_split>
#
#
bwdir="/opt/bacula/working"
sname=$(sed 's|/|.|g' <<< $3)
# tempo mínimo entre a verificação de novos arquivos, em minutos. 22 horas padrão
minupdate=1320

if  [ $(find $bwdir/$sname.txt -mmin -$minupdate  2>/dev/null | wc -l) -eq 0 ]
  then
    rm -f $bwdir/$sname.part*
    ListaOrdenada=$(find $3 -type f -printf "%s\t%p\n" | sort -nr | cut -f2  | sed 's/ /^/')  # subst o espaço por ^ para não quebrar
    ApontaVet=o
    Sinal=1
    while read Arq
      do
        let ApontaVet+=Sinal
           ((ApontaVet > $1)) && {
              let ApontaVet--
              let Sinal*=-1
           }
           ((ApontaVet < 1)) && {
              ApontaVet=1
              let Sinal*=-1
           }
       eval V$ApontaVet+='($Arq)'
    done < <(echo "$ListaOrdenada")
for ((N=1; N<=$1; N++))
do
    eval TodosArqs=\${V$N[@]}  # Gera uma linha com todos arquivos para cada vetor
    for Nome in $TodosArqs     # Desmembra a lista um a um para criar a pilha de arquivos
    do
        eval Nome=\${Nome//^/ }
        echo $Nome >> $bwdir/$sname.part$N 
    done
done
fi
cat $bwdir/$sname.part$2

Obs.: FileSets dinâmicos não são compatíveis com o Exclude do bacula. Exclusões devem ser tratadas no próprio script.

No exemplo específico do PostgreSQL, para garantia de integridade, este backup está sendo feito de um snapshot de LVM montado em outra máquina. De outra maneira o banco teria de ser parado durante o backup ou colocado em modo backup (ex.: com o plugin Bacula Enterprise pgsql).

De qualquer maneira, o bsplitter pode ser utilizado para qualquer conjunto grande de arquivos de um mesmo host, para o qual se deseja paralelismo.

Restore

Na restauração, você pode concatenar os n conjuntos de jobs feitos para uma única operação de restore, informando os jobids dos jobs paralelizados. Exemplo bconsole:

restore jobid=x,y,z

No BWeb, como exibido na Figura 2, também é possível concatenar diversos Jobs na tela de seleção de arquivos para restores, desmarcando a opção “Only Selected Fileset”

Figura 2. Restauração múltiplos Jobs BWeb, desmarcando “Only Selected Fileset”

Tuning: Melhor Performance e Tratamento de Gargalos do Backup

Bacula

• Algumas empresas usam Antivírus para Windows e até para Linux. Coloque os Daemons do Bacula como excessões de verificação.
• Dividir o FileSet em dois quando for fazer backup de mais de 20 milhões de arquivos.

Especialmente os sistemas de arquivos do Windows não lidam bem com volumes com quantidade gigantesca de arquivos pequenos. Neste caso, o ideal é criar múltiplos FileSets e Jobs (ex.: um para cada Volume ou alguns diretórios), de maneira a paralelizar as operações de cópia. Por exemplo, um servidor com volumes C: e E:.

Job1, FileSet1. Include, File = “C:/”

Job2, FileSet2. Include, Plugin = “alldrives: exclude=C”

Job3, FileSet3. Include, Plugin = “vss:/@SYSTEMSTATE/”

O uso do alldrives é importante para fazer backup de todos os outros drives exceto o C:, que já é backupeado pelo Job1. Se alguém criar um novo Volume neste servidor, o Job2 já irá fazer backup automaticamente.

O Job3 seria para backup exclusivo do System State do Windows (caso deseje separar também). O vss: é um plugin exclusivo do Enterprise, mas também é possível utilizar scripts para gerar o System State do Windows em um volume aparte.

Em algumas interfaces gráficas (como a Bweb), é possível agrupar os Jobs de um mesmo cliente para fins de melhor gestão e estatísticas.

• Diminuir o nível de compressão do GZIP (se habilitado – sempre menos de 6) ou utilizar LZO. Não usar a compressão via software do Bacula para fitas.
• Executar múltiplos jobs de backup simultâneos (Maximum Concurrent Jobs).

Tenha certeza de habilitar a concorrência nos 4 lugares:

a) Recurso Director no bacula-dir.conf

b) Recurso Storage no bacula-dir.conf

c) Recurso Storage no bacula-sd.conf

d) Recurso Device stanza in bacula-sd.conf

• Fazer backup em múltiplos discos, fitas ou diferentes storages daemons simultâneamente.
• Fitas: Habilitar o Spooling de Disco SSD/NVME. Discos HD tradicionais podem ser mais lentos que as fitas.
• Fitas: Aumentar o Minimum (ex.: 256K) e Maximum Block Size para 256K a 512K (*para LTO4. 1M muito grande e pode gerar problemas. Especificado no: bacula-sd.conf, recurso Device). Necessário recriar todos os volumes com o novo tamanho máximo de bloco, caso contrário o Bacula não conseguirá ler os anteriores.
• Fitas:  Aumentar o Maximum File Size para 10GB to 20GB (Especificado no: bacula-sd.conf, recurso Device).
• Desabilitar o AutoPrunning de Clientes e Jobs (Prunar os volumes uma vez por dia através de um Admin Job).
• Turn on Attribute Spooling for all Jobs (Padrão para a versão 7.0 em diante).
• Utilizar inserção em lotes (batch insert) no banco de dados (normalmente é padrão, definido na compilação e precisa ser suportado pelo banco).

Catálogo (banco de dados)

a) PostgreSQL

• Evitar a criação de índices acicionais.
• Utilizar configurações especiais para o Postgresql (postgresql.conf):

wal_buffers = 64kB
shared_buffers = 1GB # up to 8GB
work_mem = 64MB
effective_cache_size = 2GB
checkpoint_segments = 64
checkpoint_timeout = 20min
checkpoint_completion_target = 0.9
maintenance_work_mem = 256MB

synchronous_commit = on

• Realização (periódica) de um vacuumdb na base de dados (postgreSQL), com o passar do tempo a grande alteração de registros acaba por deixar a inserção no banco mais demorada. [1]

[1] Dica do Edmar Araújo. Referências: http://www.postgresql.org/docs/9.0/static/app-vacuumdb.html | Carlos Eduardo Smanioto -> Otimização – Uma Ferramenta Chamada Vacuum: http://www.devmedia.com.br/otimizacao-uma-ferramenta-chamada-vacuum/1710

b) MySQL

• Utilizar configurações especiais para o MySQL:

sort_buffer_size = 2MB
innodb_buffer_pool_size = 128MB

innodb_flush_log_at_trx_commit = 0

innodb_flush_method = O_DIRECT

Como padrão, o innodb_flush_log_at_trx_commit seria 1, significando que o log da transação é armezenado no disco a cada commit no banco e as transações não seriam perdidas no caso de um crash do sistema operacional. Como o Bacula utiliza muitas transações pequenas, você pode reduzir o I/O das logs e aumentar exponencialmente a performance dos backups configurando para 0, significando que não haverá armazenamento de log a cada transação. Como caso de interrupção seria necessário reiniciar o job de backup de qualquer sorte, mostra-se uma opção bastante interessante.

• Executar o mysqltuner (apt-get install mysql tuner) e implementar as modificações sugeridas.

Rede (SD e FD)

• Adicionar mais interfaces (bonding/NIC Teaming) e switches mais rápidos (pode usar o comando do Bacula status network ou a aplicação ethtool para verificar a velocidade de sua conexão ethernet).
• Ajustar o Maximum Network Buffer Size = bytes, que especifica o tamanho inicial do buffer de rede. Este tamanho é ajustado para baixo se o SO operacional não aceitar, ao custo de muitas chamadas de sistemas (não desejado). O valor padrão é 32,768 bytes. O padrão foi escolhido para ser largo o suficiente para transmissão via internet, mas em uma rede local pode ser aumentado para melhoria da performance. Alguns usuários perceberam uma melhoria de 10 vezes de transferência de tados utilizando 65,536 bytes neste valor.
• Evitar tráfego por firewalls e roteadores.
• Usar Frames Jumbo.
• Customizar o Kernel (Ref.: https://fasterdata.es.net/host-tuning/linux/. Exemplo:

echo "
# allow testing with buffers up to 128MB
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# increase Linux autotuning TCP buffer limit to 64MB
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
# net.ipv4.tcp_mtu_probing=1
# recommended for CentOS7+/Debian8+ hosts
net.core.default_qdisc = fq" >> /etc/sysctl.conf

reboot

Sistema Operacional

• RAM (> 8GB)
• vm.dirty_ratio = 2
• vm.dirty_background_ratio = 1
• vm.swappiness = 10
• vm.zone_reclaim_node = 0

Acesso aos Discos

• Use o sistema de arquivos XFS, pois ele se destaca na execução de operações paralelas de entrada/saída (E/S) devido ao seu design, que é baseado em grupos de alocação (um tipo de subdivisão dos volumes físicos nos quais o XFS é usado, encurtado para AGs). Por causa disso, o XFS permite extrema escalabilidade de threads de E/S, largura de banda do sistema de arquivos e tamanho dos arquivos e do sistema de arquivos em si, ao abranger vários dispositivos de armazenamento físico.
• Usar o “deadline disk scheduler”.
• Usar RAID com um bom controlador com bateria (ex.: ARECA).