Como um sistema distribuído, existem vários arranjos que podem ser feitos para o deploy do Bacula. Para ambientes pequenos, uma única máquina provavelmente pode hospedar todos os componentes do Bacula: o Director, o Storage Daemon, o File Daemon (cliente de backup), o banco de dados do Catálogo e as interfaces da Web, como bweb (Enterprise) e Baculum (Community). Para ambientes maiores, os Storage Daemons podem ser instalados em máquinas diferentes, fornecendo balanceamento de carga para a carga de trabalho de backup. Um soquete de CPU moderna para o Storage Daemon é recomendada para cada 400-500 máquinas com backup.

As operações do Bacula devem sempre ocorrer em sistemas operacionais de 64 bits, que pode ser virtualizado. No entanto, os recursos necessários do servidor de backup e das máquinas clientes são muito dependentes dos recursos usados pelo Bacula, como desduplicação em nível de bloco, criptografia, compactação, tamanho do backup, número de clientes e tarefas de backup simultâneas. Algumas considerações de dimensionamento de recursos são fornecidas da seguinte maneira.

Bacula Director

O daemon do Bacula Director não requer muitos recursos e foi testado com mais de 10.000 clientes de backup conectados. Ele hospeda as configurações de backup, fornece autenticação dos daemons e agendamento de tarefas. É por isso que o Director geralmente é hospedado em conjunto com a interface da Web, o Catálogo e até mesmo os Daemons de Armazenamento. O cliente de backup instalado é sempre necessário, pois fornece o auto-backup do sistema.

Catálogo

O Catálogo de metadados de backup do Bacula deve ser preferencialmente o PostgreSQL. O tamanho do banco de dados depende muito do número de arquivos copiados e dos tempos de retenção de backup, pois cada arquivo é uma entrada no banco de dados (em média, 250 bytes). Um CentOS 7 ou Windows Server 2016 tem uma média de 140.000 arquivos. Se considerarmos 200.000 para crescimento do sistema, existência de aplicativos com vários arquivos e execução de backup diferencial, cada sistema operacional com backup completo ocupará 50 MB de tamanho de banco de dados por tarefa de backup completo multiplicado pelo número de backups completos mantidos pela política de backup.

50MB * número_máquinas_bkp_full * número_bkps_full_retidos = espaço_disco_BD

Por exemplo, um backup completo de 25 sistemas operacionais com 4 backups completos retidos semanalmente e 12 meses exigiria 20 GB de espaço no banco de dados.

Naturalmente, os requisitos são muito mais baixos se seus Jobs de backup copiarem apenas os arquivos das aplicações e de bancos de dados.

Os discos da partição do Catalog e do SO podem ser hospedados em LVM e terão grande vantagem se forem usados discos com E/S rápida, como SSD, especialmente para sistemas Bacula médios e maiores (por exemplo, mais de 100 clientes de backup).

O uso do SSD também pode diminuir a quantidade de memória RAM necessária, pois o acesso ao disco não é tão lento (e a RAM é muitas vezes mais cara). Caso contrário, a RAM física ideal total deve ser maior que o tamanho do banco de dados no disco para minimizar a E/S.

A RAM e a CPU sugeridas para uma máquina que hospeda o Director e o banco de dados do catálogo usando discos muito rápidos, SSD ou NVME, são informadas na tabela seguinte.

# Clientes de Backup	25	50	200	500	2000	5000
RAM	8	8	16	32	64	128
Threads de CPU	2	2	4	4	8	8

Bacula Storage Daemon (SD)

O Storage Daemon foi testado atendendo a até 500-600 clientes de backup. Ele depende da capacidade da CPU e da boa conexão de rede (Gigabit, Gigabits em bond ou 10 Gbit), pois receberá dados dos clientes de backup e os armazenará no NAS, na biblioteca de fitas ou em qualquer tipo de armazenamento de backup. A capacidade de conexão com esses dispositivos também deve ser abundante, como SCSI, iSCSI e FC.

XFS com LVM ou ZFS são bons candidatos para o sistema de arquivos, que provavelmente hospedará backups baseados em disco. Inicialmente, o único espaço requerido pelo SD é o do sistema operacional, e o espaço extra para armazenamento de backup provavelmente será fornecido por discos extras montados.

Se estiver usando a deduplicação, no entanto, um disco pequeno muito rápido ou SSD deve ser fornecido para hospedar os arquivos de índice de deduplicação. A velocidade de backup da Deduplicação Global dependerá em grande parte da E/S. O valor sugerido é de 20 GB de SSD por 1 TB de backups.

Quanto aos discos de contêiner de dados desduplicados regulares, que podem ser mais lentos, o uso de RAID-6 (ou superior) é especialmente recomendável, pois um único bloco de informações serve para vários backups e não deve ser perdido de forma alguma. Seu tamanho requerido depende da desduplicabilidade de seus dados, de quanto eles mudam e dos tempos de retenção de backup, mas é seguro dizer que desduplicação do Bacula é tão boa ou melhor que qualquer outro software de backup com desduplicação.

Além disso, a quantidade de RAM só é importante se você usar a deduplicação. Em um mundo de recursos livre, ele deve ter pelo menos o mesmo tamanho dos arquivos de índice de dedução. Como isso nem sempre é possível, tente ter ao menos 1,3 GB de RAM para cada 1 TB backup. Se isso ainda não for possível, use os discos SSD ou NVME mais rápidos disponíveis para hospedar os arquivos de índice de deduplicação como uma compensação aceitável.

Os recursos sugeridos para uma máquina com o Bacula Storage Daemon e a Deduplicação são informados da seguinte forma:

Núm. de hosts backupeados	10	20	50	100	300	500
RAM	8	8	16	32	64	128
Threads CPU	2	2	4	4	8	12
Disco SSD Índice Dedup TB	0.2	0.4	1	2	6	10
Disco Lento Conteiners Dedup TB	15	30	50	150	450	750

Bacula File Daemon

O cliente Bacula usa CPU e memória mínima para backups padrão.

Se estiver usando o recurso Global Deduplication, Encryption e / ou Accurate mode (requerido pelo VSphere, Oracle, PGSQL PITR e outros plugins), recursos extras são sugeridos.

Os seguintes recursos extras são recomendados para as máquinas do cliente: