Bacula usa variável para reutilizar o Recurso FileSet

Question

Eu tenho vários ambientes do mesmo aplicativo em diferentes servidores. A estrutura do diretório é muito semelhante, então eu gostaria de usar um único FileSet para todos eles. Por exemplo:

- server1: /opt/env1/app/logs
- server1: /opt/env1/app/bin
- server1: /opt/env1/app/temp
- server1: /opt/env1/app/lib

- server2: /opt/env2/app/logs
- server2: /opt/env2/app/bin
- server2: /opt/env2/app/temp
- server2: /opt/env2/app/lib

- server2: /opt/env3/app/logs
- server2: /opt/env3/app/bin
- server2: /opt/env3/app/temp
- server2: /opt/env3/app/lib

Eu gostaria de ter algo como:

FileSet {
  Name = "APP"
  Include {
    Options {
      signature = MD5
      Compression = GZIP
    }
    File = "/opt/${env}/app"
  }
  Exclude {
    File = "/opt/${env}/app/logs"
    File = "/opt/${env}/app/temp"
  }
}

Então:

Job {
  Name = "JOBENV1"
  #somehow set env variable as env1
  FileSet="APP"
  ...
}

Job {
  Name = "JOBENV2"
  #somehow set env variable as env2
  FileSet="APP"
  ...
}

Job {
  Name = "JOBENV3"
  #somehow set env variable as env3
  FileSet="APP"
  ...
}

    

Answer 1

Depois de alguns dias com a solução, parece estar funcionando, então aqui vai:

Até o exemplo, digamos que temos os seguintes trabalhos:

• server1-env1-job
• server2-env2-job
• server2-env3-job

Assumindo então o --job como uma convenção, o conjunto de arquivos deve se parecer com:

FileSet {
  Name = "someapp-fileset"
  Include {
    Options {
      signature = MD5
      Compression = GZIP
    }
    File = "| bash -c \"echo %n | awk -F '-' '{print \}' | xargs -I ARG echo /opt/ARG\""
  }
  Exclude {
     File = "| bash -c \"echo %n | awk -F '-' '{print \}' | xargs -I ARG echo /opt/ARG/temp\""
     File = "| bash -c \"echo %n | awk -F '-' '{print \}' | xargs -I ARG echo /opt/ARG/logs\""
  }
}

Para obter mais informações sobre a execução de comandos no conjunto de arquivos, consulte o documentação

Backups completos e incrementais estão funcionando bem.

    

Answer 2

Eu não acredito que você possa fazer isso - o arquivo de configuração do Bacula é um arquivo de configuração , não uma linguagem de programação ou shell.

Suas opções práticas são:

1. Use estruturas de diretório idênticas em cada máquina
   Esta é a solução mais prática do ponto de vista de Bacula. Ele requer o mínimo de trabalho adicional no arquivo de configuração do Bacula e, se seus aplicativos forem "idênticos", faz mais sentido.

2. Use um conjunto de arquivos por máquina
   Isso é mais irritante do que a opção (1) em que você está mantendo um conjunto de conjuntos de arquivos quase idênticos. É mais prático se você estiver gerando sua configuração do Bacula com algum outro processo que possa criar automaticamente os conjuntos de arquivos.

3. Use um conjunto de arquivos que lista todos os diretórios
   Isso funciona, mas sempre que você adicionar uma nova máquina (e, portanto, um novo diretório env# ), você estará alterando o conjunto de arquivos global e acionando backups completos.

4. Use uma diretiva ClientRunBeforeJob para colocar os arquivos em um local uniforme
   Isso é um pouco sujo, mas funciona - Tenha o Bacula rsync do ambiente do aplicativo para outro local antes que ele faça o backup. (Se você estiver em um sistema Linux, também poderá usar mount --bind para colocar o aplicativo em um local uniforme sem afetar mais nada.)
   A principal desvantagem dessa abordagem é que você dobra seus requisitos de armazenamento: você tem a cópia de produção em execução do aplicativo e a cópia de sombra que o Bacula faz para fazer o backup.