Espalhando a carga de backup completo nas estratégias 1, 8, 15, 22 com Bacula, mas não tendo certeza da configuração do diretor [closed]

Question

Estou usando o Bacula para conectar-me a servidores remotamente (em um DC diferente) e fazer backup.

Devido a restrições de velocidade e sem sobrecarregar a rede do escritório durante o dia, eu não vejo que seja viável fazer um backup completo dos nossos 4 servidores ao mesmo tempo, então podemos dividir os backups completos para cada semana um servidor tem um backup completo, em rotação.

Requisito 1 - Distribuição de carga de transferências de backup completo

Se tivéssemos 4 servidores, queremos executar um backup completo em rotação da seguinte forma:

1. myhost1 = > 1 de cada mês completo, incremental todos os outros.
2. myhost2 = > 8 de cada mês completo, incremental todos os outros.
3. myhost3 = > 15 de cada mês completo, incremental todos os outros.
4. myhost4 = > 22 de cada mês completo, incremental todos os outros.

Em qualquer data específica, queremos manter um backup completo, além do último backup completo antes disso. Todos os incrementos a partir de agora para o backup completo mais recente devem ser mantidos.

Requisito 2 - Integral e Incremental em pools separados

Eu tenho dois pools de armazenamento, um para incremental e outro para full, precisamos dizer ao Bacula para usar o pool completo se um snapshot incremental não puder encontrar um full completo, caso contrário use o pool-inc.

Requisito 3 - Escalabilidade

Potencialmente, poderia haver mais servidores no futuro, se eu quisesse rotacioná-los ao longo dos sábados e domingos (dando até 8 agendamentos por mês nos dias [1,2], [8,9], [15,16], [22,23]). Existe alguma maneira mais fácil de definir trabalhos, como posso ver se está se tornando um grande arquivo de configuração.

    

Answer 1

Tomando os pontos individuais da sua pergunta:

Requisito 1 - espalhamento de carga
Você precisa descobrir isso para o seu ambiente - "razoável" depende de vários fatores (quantas máquinas, quantos dados, que tipo de mídia você está fazendo backup, quanta largura de banda você tem disponível, quanto dinheiro que seu chefe está disposto a alocar para backups, tenha ou não um Gato do Teto em seu datacenter que possa ser treinado para rodar fitas ...)

Você também pode querer olhar para "backups sintéticos completos" (Bacula os chama VirtualFull backups) - eles podem produzir um backup "completo" sem precisar extrair dados do cliente, consolidando os dados dos quais você fez backup no seu último full plus, além de todas as alterações incrementais / diferenciais.

Requisito 2 - Completo e Incremental em pools alternativos
Parece que você não descobriu as diretivas de configuração FullPool , IncrementalPool e DifferentialPool . Consulte o manual do Bacula para obter mais informações sobre eles.
Eles são o que você precisa para dividir os backups em diferentes pools por tipo de trabalho.

Requisito 3 - Escalabilidade
Primeiro, se você estiver usando o Bacula e fazendo algo de complexidade moderada, desista de um pequeno arquivo de configuração agora mesmo. A configuração do diretor será grande.

O que você está fazendo com as diretrizes JobDef e Schedule é o jeito certo de lidar com as coisas, adicione as definições conforme necessário para atender às suas necessidades.

Se eu fosse você, não usaria as datas de backup como a convenção de nomenclatura - chame seus agendamentos (e padrões de trabalho) "Grupo A", "Grupo B" etc. (ou algo igualmente genérico). Documente em qual grupo de backup cada servidor está, para que você possa reequilibrar facilmente sua carga de backup movendo um servidor de um grupo para outro. Você pode fazer isso com seus nomes baseados em data, é claro, mas acho mais fácil pensar em grupos de backup como um conceito abstrato. Além disso, se Group A estiver sendo sangrado no período de backup de Group B , posso sempre mover todos os Group B um dia, alterando a definição de programação, e não preciso alterar seu nome.