Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Do que se trata este artigo:

Este artigo tem como objetivo dar sequência ao estudo sobre a ferramenta Bacula, demonstrando suas formas de instalação e configuração. Também serão apresentados os modos de instalação e configuração com o MySQL e apresentadas as variantes para instalação do PostgreSQL e SQLite como bases de dados para gerenciar as rotinas de backup.

Em que situação o tema é útil:

O Bacula é uma solução de backup multiplataforma desenvolvida sob a licença GPL. É robusta, cheia de recursos e modular. O Bacula se adapta às redes de qualquer tamanho e em qualquer topologia. Com essa solução não há mais a necessidade de altos investimentos com licenças de software para backup.

Resumo DevMan:

Este artigo irá contemplar as fases de implantação e configuração do Bacula, extraindo a essência dos conceitos e sua aplicabilidade corporativa. Não foi possível demonstrar neste artigo todas as possibilidades de implementações do software devido a sua extensa variedade de configurações. Contudo, todas as definições aplicadas no artigo são portáveis a outros clientes de backup.

Autores: Eduardo Pagani Julio e Flávio Alexandre dos Reis

No Brasil, o Bacula tem despertado o interesse de diversos profissionais para seu uso. Estamos na era conhecida como a “era da informação”. Mas qual a preocupação que se deve ter com a informação? O que é importante, quanto tempo deve ser armazenado e o que pode ser descartado? Será que dependemos de todas e quaisquer tipos de informação? Nos dias atuais, o conhecimento passou a ser chave-mestra, no qual a informação é utilizada para gerir estratégias do negócio, seja para uma pequena empresa até multinacionais preocupadas em equilibrar seus gastos.

Um importante diferencial ligado ao crescimento e a competitividade está relacionado diretamente às informações contidas na organização como, segredos de negócios, históricos operacionais, pesquisas e analise de marcado.

A segurança da informação está relacionada à garantia de que as informações, em qualquer formato (seja mídias eletrônicas, papel, conversações pessoais) estejam protegidas contra o acesso por pessoas não autorizadas, bem como estejam sempre disponíveis quando necessárias, e que sejam confiáveis.

À medida que o Bacula mostra-se um sistema de gestão de backup seguro, livre e econômico, de fácil aplicabilidade nas empresas de pequeno, médio e grande porte, é portável para os principais sistemas operacionais, e possui interface web para fácil administração, ele passa a ser um forte candidato ao escolhermos uma ferramenta para automação do processo de backup.

Vale ressaltar que o Bacula encontra-se em constante desenvolvimento a cerca de suas versões e atualizações, daí a importância de estudos aprofundados deste software.

O primeiro passo a ser executado quando se planeja uma instalação do Bacula é selecionar e instalar uma base de dados, pois conforme mencionado na primeira parte do artigo, o Bacula usa uma base de dados para armazenar autorizações, índices e atributos que ficam gravados no Catalog SQL. Na versão 5 do Bacula são suportados os seguintes SGBDs: MySQL, PostgreSQL e SQLite.

Cada um destes possui características e limitações distintas, que muito provavelmente não serão perceptíveis ao usuário do Bacula. Os procedimentos de instalação também variam de acordo com a escolha do banco a ser utilizado. Existem diversos manuais na Internet, inclusive em Português, com todos os passos a serem seguidos para a instalação dos bancos. O caminho mais rápido para instalar o banco de dados consiste na utilização de um gerenciador de pacotes (programas que auxiliam a instalação de aplicativos) como o apt, aptitude em distribuições baseadas em Debian (ler Nota DevMan 1), yum naquelas baseadas em RedHat e yast nas baseadas em Suse.

Dito isto, vamos iniciar agora a instalação e configuração do Bacula.

Nota DevMan 1. Aptitude

Aptitude é um front-end para o Advanced Packaging Tool (APT). Ele exibe uma lista de pacotes de software e permite ao usuário escolher interativamente pacotes para instalar ou remover.

Instalação da base de dados

Nesse artigo será utilizado como exemplo de configuração o MySQL. Para a instalação do PostgreSQL ou SQLite basta alterar o nome do pacote a ser instalado (com o aplicativo apt, pode-se instalar o SGBD de forma fácil). Observe na Listagem 1 as formas de instalação de cada um dos bancos em uma distribuição baseada em GNU/Linux Debian.

Listagem 1. Formas de instalação do SGBD no Debian.

Para instalação do MySQL use:
  # apt-get install mysql-server
   
  Para instalação do PostgreSQL use:
  # apt-get install postgresql
   
  Para instalação do SQLite use:
  # apt-get install sqlite

Depois de terminada a instalação, verifique se o serviço de banco de dados está rodando de forma correta. Pode-se confirmar sua execução utilizando o comando ps, conforme a Listagem 2 (no exemplo desta listagem, considerando o MySQL).

Listagem 2. Verificando o status do serviço.

#ps aux | grep mysql

Instalando o Bacula em um Servidor GNU/Linux

Partiremos agora para a instalação do Bacula em um servidor GNU/Linux. De agora em diante serão apresentadas com maiores detalhes duas formas básicas de instalação dos pacotes do Bacula: utilizando um gerenciador de pacotes (apt-get, aptitude, yum) e por compilação (via pacotes binários).

Mas antes de iniciar a instalação do servidor, inicialmente execute o comando (#apt-cache search bacula) para obter a lista de pacotes disponíveis. Observe na Listagem 3 os pacotes disponibilizados em um sistema GNU/Linux Debian. Como podemos notar, a saída do comando mostra o pacote disponível e uma breve descrição de sua funcionalidade. Por exemplo, da lista de pacotes disponíveis, o pacote bacula-console-qt se refere a uma interface gráfica que traz uma grande facilidade para a administração do Bacula, como acompanhamento de agendamentos.

Listagem 3. Pacotes disponibilizados nas distribuições baseadas no Debian.


  bacula-director-common - verificação, recuperação e "backup" via rede - arquivos comuns do Director
  bacula-server - verificação, recuperação e "backup" via rede - meta pacote de servidor
  bacula-console - verificação, recuperação e "backup" de rede - console de texto
  bacula-sd-pgsql - verificação, recuperação e "backup" via rede - ferramentas PostgreSQL SD
  bacula-traymonitor - verificação, recuperação e "backup" de rede monitor de bandeja
  bacula-director-mysql - verificação, recuperação e "backup" via rede - armazenamento MySQL p/ o Director
  bacula-sd-mysql - verificação, recuperação e "backup" via rede - ferramentas MySQL SD
  bacula-director-pgsql - verificação, recuperação e "backup" via rede - armazenamento PostgreSQL p/ o Director
  bacula-sd-sqlite3 - verificação, recuperação e "backup" via rede - ferramentas SQLite 3 SD
  bacula-console-wx - verificação, recuperação e "backup" de rede - console WxWindows
  bacula-director-sqlite3 - verificação, recuperação e "backup" via rede - armazenamento SQLite 3 p/ o Director
  bacula - verificação, recuperação e "backup" via rede – meta pacote
  bacula-sd - verificação, recuperação e "backup" de rede – daemon de armazenamento
  bacula-doc - documentação para o Bacula
  bacula-director-sqlite - verificação, recuperação e "backup" via rede - armazenamento SQLite p/ o Director
  bacula-console-qt - Ferramenta de Administração Bacula
  bacula-sd-sqlite - verificação, recuperação e "backup" via rede - ferramentas SQLite SD
  bacula-common - verificação, recuperação e "backup" via rede - arquivos de suporte comum
  bacula-fd - verificação, recuperação e "backup" de rede – daemon de arquivo
  bacula-client - verificação, recuperação e "backup" via rede - meta pacote cliente

No site oficial do Bacula, www.bacula.org, é possível encontrar os pacotes compilados para as mais diferentes distribuições GNU/Linux. Note que, neste caso, os pacotes já estão traduzidos para o idioma Português. Então, será necessário saber quais pacotes devem ser instalados, de acordo com a finalidade da instalação, se cliente ou servidor.

Bem, conhecidos os pacotes disponíveis, partiremos agora para a instalação dos pacotes propriamente ditos.

O servidor de backup

Se ao iniciar a instalação do servidor Bacula, apenas for selecionado o pacote Bacula conforme o comando (#apt-get install bacula), o gerenciador de pacotes (apt-get) irá automaticamente escolher uma série de pacotes que possibilitam a instalação completa do serviço de backup. Nesta lista, um pacote referente ao banco de dados também será selecionado. Na Listagem 4 pode-se observar os pacotes extras que o apt-get irá instalar.

Listagem 4. Pacotes extras a serem instalados.

bacula-client bacula-common bacula-console bacula-director-common bacula-director-sqlite3 bacula-fd bacula-sd bacula-sd-mysql bacula-server bacula-traymonitor mt-st mtx sqlite3

Pode-se observar que nesse exemplo está sendo utilizado o SQLite. Este pacote deverá ser alterado caso o administrador deseje utilizar outro banco como o MySQL ou o PostgreSQL. Assim, para instalar um servidor Bacula com o MySQL, basta substituir os pacotes que contenham a expressão sqlite por mysql. A mesma orientação pode ser seguida para uso com o postgresql.

Neste momento, vale uma atenção especial aos pacotes mtx e mailx. Estes trazem funcionalidades importantes para a administração e manipulação de fitas magnéticas e mensagens internas do serviço.

A Tabela 1 apresenta os pacotes mínimos necessários para instalação e configuração de um servidor Bacula.

Pacote

Função

bacula-fd

Para fazer backup do próprio servidor de backup

bacula-common

Arquivos comuns do Bacula

bacula-console

Caso deseje administrar o Bacula através do próprio servidor

bacula-director-[nome_do_banco]

O director é o servidor Bacula propriamente dito

bacula-sd-[nome_do_banco]

storage daemon – ou seja, manipula os dispositivos de armazenamento. O [nome_do_banco] pode ser opcional

bacula-traymonitor

Apenas se o servidor possuir interface gráfica, e você desejar usá-la para administrar o Bacula.

bacula-doc

Documentação do Bacula

Tabela 1. Pacotes mínimos a serem instalados.

Nas versões 3.x do Bacula, existe mais uma dependência: o pacote libssl, utilizado para criptografia. Durante a instalação, o apt irá perguntar se foi configurada alguma senha no banco de dados. Caso positivo, tal senha deverá ser informada.

Após a instalação, já se pode iniciar os daemons do Bacula (Nota DevMan 2), sempre seguindo a ordem indicada na Listagem 5.

Nota DevMan 2. Daemon

Daemons são processos que rodam em segundo plano aguardando por requisições.

Listagem 5. Ordem de inicialização dos daemons.


  /etc/init.d/bacula-fd
  /etc/init.d/bacula-sd
  /etc/init.d/bacula-director

Qualquer erro que venha a ocorrer nas configurações dos arquivos (localizados em /etc/bacula) será imediatamente demonstrado. Caso nenhum erro seja reportado, a instalação estará completa.

Para ter acesso ao director, que é o serviço responsável pela administração de todos os processos de backup, digite bconsole. Entretanto, caso o director não retorne nenhum erro, mas tenha sua execução terminada, provavelmente poderemos ter um problema relacionado à comunicação com o banco de dados. Caso isso venha a ocorrer, execute os scripts da Tabela 2.

Script

Descrição

/etc/bacula/create_bacula_database

Cria o banco de dados Bacula – no caso do MySQL, há um script específico

/etc/bacula/make_bacula_tables

Cria as tabelas do banco

/etc/bacula/grant_bacula_privileges

Cria o usuário bacula e garante os privilégios no banco de mesmo nome.

Tabela 2. Scripts disponíveis no Bacula.

Caso o erro persista, deve-se verificar a configuração de usuário e a senha do banco. Para isso, verifique o arquivo (/etc/bacula/bacula-dir.conf). Se mesmo assim o daemon do bacula-director vier a apresentar problemas, consulte os arquivos de log do Bacula para mais detalhes sobre o erro. Geralmente, quando a instalação é feita por compilação, essa irá apresentar melhores resultados quanto à ocorrência destes incidentes.

Cliente de backup

Obviamente, se a máquina for apenas um cliente de backup Bacula, não será necessário instalar um banco de dados para o catálogo. A instalação do cliente pode ser feita através do pacote de nome bacula-client. Em algumas distribuições o pacote será bacula-fd.

Nessa parte do artigo será apresentado como efetuar a instalação por meio de compilação, sendo que o exemplo apresentado contemplará o servidor de backup (inclui o cliente e o storage daemons). A sequência exibida a seguir demonstra o processo de instalação:

1) Efetue o download do pacote no endereço: www.bacula.com.br;

2) Descompacte o .tar.gz (tar -xzf bacula.tar.gz -C /opt). A opção “-xzf“ descompacta arquivos antes compactados com o gzip, e o parâmetro “-C” indica o diretório onde o mesmo será descompactado;

Após descompactar, acesse o diretório /opt. Antes de compilar, instale os compiladores e demais pacotes necessários. Para isso, em distribuições baseadas em GNU/Linux Debian, execute #apt-get install build-essential;

3) Se estiver instalando a versão 3 ou superior do Bacula, instale o pacote libssl-dev (#apt-get install libssl-dev) a fim de tratar questões de criptografia;

4) Execute o comando ./configure a fim de checar possíveis dependências ainda não satisfeitas. Observe as possíveis opções:


  ./configure
  --sbindir=$HOME/bacula/bin
  --sysconfdir=$HOME/bacula/bin
  --with-pid-dir=$HOME/bacula/bin/working
  --with-subsys-dir=$HOME/bacula/bin/working
  --enable-smartalloc
  --with-mysql
  --with-working-dir=$HOME/bacula/bin/working
  --with-dump-email=reis.falexandre@gmail.com
  --with-job-email=reis.falexandre@gmail.com
  --with-smtp-host=localhost

5) Caso seja utilizado o MySQL, há uma dependência específica, portanto deve-se instalar o pacote libmysql++-dev (se optar por PostgreSQL, instale o libpq-dev);

6) Pode-se executar: ./configure (apenas optando pelo banco MySQL -–with-mysql ou PostgreSQL --with-postgresql);

7) Execute o comando make (#make) para gerar o instalador. Mas atenção, o autostart faz com que o Bacula seja inicializado junto com o sistema operacional;

8) Agora execute o comando make com a opção install para iniciar a instalação do Bacula (#make install);

9) Execute o comando #cd $HOME/bacula/bin e acesse o diretório do Bacula onde se encontra os seus binários;

10) Execute o comando #./bacula start. Esse script é responsável por iniciar o Bacula;

11) Execute o comando #./etc/bacula/create_bacula_database. Ele irá criar o banco de dados Bacula. No caso do MySQL, há um “script” específico;

12) Execute o script #/etc/bacula/create_bacula_tables. Este irá criar as tabelas do banco;

13) Por fim, execute o script #/etc/bacula/grant_bacula_privileges. Este irá criar o usuário bacula e garantir os privilégios no banco de mesmo nome (ler Nota DevMan 3).

Nota DevMan 3. Usuário e senha do banco

Para todos os scripts mencionados, é possível passar o usuário e senha do banco de dados como parâmetro.

Exemplo: /etc/bacula/create_bacula_database –u “usuario” –p “senha”

Depois de instalado o servidor, instale o cliente Bacula nas estações. A sequência de comandos a seguir apresenta a forma de instalação por compilação:

1) Descompacte o arquivo .tar.gz e, no diretório criado, digite:


  #./configure –-enable-client-only
  #make
  #make install autostart

2) Configure o bacula-fd. Compilando apenas um dos “daemons” do Bacula, quando a instalação será em um cliente, não há necessidade de instalar todas as opções do Bacula. Assim, podemos compilar apenas os pacotes necessários. As opções de compilação para seleção dos daemons a serem instalados são as apresentadas a seguir. Perceba que neste caso estamos definindo que serão instalados apenas alguns daemons:


  #./configure
  --enable-client-only (apenas compila o File Daemon)
  --enable-build-dird (também compilará o Director)
  --enable-build-stored (também compilará o Storage Daemon) 

Configurando o Bacula

O arquivo criado automaticamente na instalação do Bacula irá funcionar apenas como um ambiente para testes. É indispensável que você faça algumas modificações para que se torne realmente um sistema útil.

Um dos erros mais comuns que podem acontecer na instalação do Bacula consiste na falha de autenticação com o banco de dados (isso pode ser verificado através do log do Bacula, conforme já visto anteriormente). Quando isso acontece, não é possível se conectar ao director (bacula-dir) e o daemon deixa de estar em execução. Para corrigi-lo, tenha certeza de que rodou o script /etc/bacula/grant_bacula_privileges e que o login e senha de acesso ao catalog estejam corretos (observe o arquivo /etc/bacula/bacula-dir.conf).

Com o Bacula acessível através do bconsole, podem-se efetuar algumas configurações básicas para sua customização. Os tópicos seguintes irão guiar o leitor nessas alterações.

O nome do Director e do Monitor deverá ser personalizado. Essa informação é inserida durante a instalação do Bacula e é utilizado o hostname como nome do director. Caso o administrador deseje modificar esta informação, esse é o melhor momento de fazê-lo, pois esse ainda é o início da configuração e ainda não há outros clientes configurados. Esta alteração precisa ser feita em todos os arquivos .conf do servidor (bacula-dir, bacula-fd, bacula-sd e bconsole.conf). Como exemplo, pode-se inserir o novo nome como devmedia-dir (director) e devmedia-mon (monitor). As respectivas senhas são randômicas e deverão estar corretamente configuradas, portanto, não é necessária nenhuma alteração nesse momento.

Agora altere o nome do seu único Job de backup, até então configurado para corresponder ao novo nome do seu director. Em nosso caso, renomearíamos de default-job para devmedia-job. Lembre-se de reiniciar os Daemons (ler Nota DevMan 4).

Nota DevMan 4. Reiniciar daemons

A cada passo da instalação, reinicie os daemons para que as mudanças sejam aplicadas. Dessa forma, pode-se verificar possíveis erros na configuração.

O nome do JobDefs (definições de job) deve ser alterado, por exemplo, para debian. Observe que JobDefs são definições gerais para os jobs de backup que facilitam a configuração de novos Jobs, tornando desnecessária a repetição de informações. Ainda há as opções constantes nos Jobs que irão prevalecer sobre as do JobDefs. O administrador precisará alterar o nome do JobDefs também no Recurso Job (bacula-dir.conf). No exemplo em questão, também seria para debian. Feita esta alteração, reinicie os Daemons.

Para trabalhar com a estratégia GFS (ler Nota DevMan 5), crie três novas pools no Recurso Pool (diário, semanal e mensal). Depois, apague as duas pools existentes. O nome da pool padrão precisa ser alterado no JobDefs. Feita esta alteração, reinicie os Daemons.

Nota DevMan 5. Esquema GFS

O esquema GFS (Grandfather-father-son backup) se refere ao mais comum esquema de rotação de mídias para as cópias de segurança. Originalmente concebido para o backup em fitas, funciona bem para qualquer estrutura de backup hierárquico. O método básico consiste em criar três conjuntos, sendo um diário, um semanal e outro mensal. Para melhor entendimento podem ser associados da seguinte forma. Os diários ou filhos serão rotacionados a cada dia com um semanal (ou pai) a cada semana; o semanal é rotacionado, em bases semanais, com um mensal (ou avô).

Agora modifique o agendamento (WeeklyCycle), pois o original são apenas exemplos de como configurá-lo. É aconselhável utilizar apenas um agendamento para ambos os jobs (backup e backup Catalog) para que sempre sejam feitos nas mesmas pools. Obviamente, o nome WeeklyCycle pode ser alterado para um nome mais simpático, desde que as mudanças sejam feitas também no JobDefs e em outras partes do Director. Feita esta alteração, reinicie os Daemons.

Agora, configure um storage (em bacula-sd e depois no bacula-dir). O storage configurado originalmente pelo Bacula (File, Device = /tmp) obviamente trata-se apenas de um laboratório de testes. Entretanto, no próprio bacula-sd há vários exemplos de configuração para outros dispositivos. Feita esta alteração, também reinicie os Daemons.

O FileSet original do bacula-dir.conf vem configurado para “backupear” apenas um diretório. Como exemplo de uso inicial, é aconselhável mudar para que seja “backupeado” todo o sistema (“/”, no caso de um servidor GNU/Linux). Altere o nome dele para devmediafileset. Essa alteração precisa ser replicada em outras partes do bacula-dir.conf. Assim, crie outros FileSets para os novos servidores. Entretanto, há vários servidores com perfis semelhantes, que podem usufruir do mesmo FileSet – exemplo: servidores GNU/Linux nos quais tudo será “backupeado”, ou seja, todo o sistema (“/”).

Neste momento, o sistema de backup básico já está quase pronto para ser utilizado. Obviamente, novos clientes serão adicionados e algumas alterações de customizações mais avançadas precisarão ser feitas.

Na próxima seção serão apresentados os arquivos de configuração com alguns comentários mais importantes. No entanto, não serão explicadas todas as possibilidades visto que o material ficaria muito extenso.

bacula-dir.conf

O Bacula Director (ou diretor Bacula) é o arquivo principal do sistema de backup. Para que tudo funcione, é necessário que, pelo menos, exista um Director configurado. Nele estão as principais configurações de backup: clientes, storages, pools, file sets, retenções, agendamentos, etc. Enquanto mais de 99% das alterações na configuração são feitas no diretor, os demais arquivos (bacula-fd, sd e bconsole.conf) são raramente alterados. Em compensação, trata-se do maior e mais complexo arquivo de configuração do Bacula. Na Listagem 6 é apresentado um arquivo customizado, com alguns comentários sobre as principais opções do Bacula. A ordem entre os “recursos” pode variar sem que haja problema na configuração.

Listagem 6. Conteúdo do arquivo bacula-dir.conf.


  Director {                      
    Name = devmedia-dir
    DIRport = 9101  
    QueryFile = "/etc/bacula/scripts/query.sql"
    WorkingDirectory = "/var/lib/bacula"
    PidDirectory = "/var/run/bacula"
    Maximum Concurrent Jobs = 1
    Password = "Ui3dLcjKWiR6QIyTu+PjPK6wHlziIf7fZlSiCgiZZ3jq"  
    Messages = Daemon
    DirAddress = 127.0.0.1
  }
   
  JobDefs {
    Name = "DefaultJob"
    Type = Backup
    Level = Incremental
    Client = devmedia-fd 
    FileSet = "Full Set"
    Schedule = "WeeklyCycle"
    Storage = File
    Messages = Standard
    Pool = File
    Priority = 10
    Write Bootstrap = "/var/lib/bacula/%c.bsr"
  }
   
  Job {
    Name = "BackupClient1"
    JobDefs = "DefaultJob"
  }
   
  Job {
    Name = "BackupCatalog"
    JobDefs = "DefaultJob"
    Level = Full
    FileSet="Catalog"
    Schedule = "WeeklyCycleAfterBackup"
    # This creates an ASCII copy of the catalog
    # Arguments to make_catalog_backup.pl are:
    #  make_catalog_backup.pl <catalog-name>
    RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup.pl MyCatalog"
    # This deletes the copy of the catalog
    RunAfterJob  = "/etc/bacula/scripts/delete_catalog_backup"
    Write Bootstrap = "/var/lib/bacula/%n.bsr"
    Priority = 11  
  }
   
  Job {
    Name = "RestoreFiles"
    Type = Restore
    Client=devmedia-fd                 
    FileSet="Full Set"                  
    Storage = File                      
    Pool = Default
    Messages = Standard
    Where = /nonexistant/path/to/file/archive/dir/bacula-restores
  }
   
  FileSet {
    Name = "Full Set"
    Include {
      Options {
        signature = MD5
      }
      File = /usr/sbin
    }
   
    Exclude {
      File = /var/lib/bacula
      File = /nonexistant/path/to/file/archive/dir
      File = /proc
      File = /tmp
      File = /.journal
      File = /.fsck
    }
  }
   
  Schedule {
    Name = "WeeklyCycle"
    Run = Full 1st sun at 23:05
    Run = Differential 2nd-5th sun at 23:05
    Run = Incremental mon-sat at 23:05
  }
   
  Schedule {
    Name = "WeeklyCycleAfterBackup"
    Run = Full sun-sat at 23:10
  }
   
  FileSet {
    Name = "Catalog"
    Include {
      Options {
        signature = MD5
      }
      File = "/var/lib/bacula/bacula.sql"
    }
  }
   
  Client {
    Name = devmedia-fd
    Address = localhost
    FDPort = 9102
    Catalog = MyCatalog
    Password = "4pVPQ7Rca5ydDivqsHJWX9IFRz4gOgU5z" 
    File Retention = 30 days            
    Job Retention = 6 months            
    AutoPrune = yes                     
  }
   
  Storage {
    Name = File
    Address = localhost               
    SDPort = 9103
    Password = "L7NeeJ6XIsN3sJFjoiRHFuEJTTncT4DGG"
    Device = FileStorage
    Media Type = File
  }
   
  Catalog {
    Name = MyCatalog
    dbname = bacula; DB Address = ""; dbuser = "bacula"; dbpassword = "s3curity"
  }
   
  Messages {
    Name = Standard
   
    mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
    operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
    mail = root@localhost = all, !skipped            
    operator = root@localhost = mount
    console = all, !skipped, !saved
    append = "/var/lib/bacula/log" = all, !skipped
    catalog = all
  }
   
  Messages {
    Name = Daemon
    mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
    mail = root@localhost = all, !skipped            
    console = all, !skipped, !saved
    append = "/var/lib/bacula/log" = all, !skipped
  }
   
  Pool {
    Name = Default
    Pool Type = Backup
    Recycle = yes                       
    AutoPrune = yes                     
    Volume Retention = 365 days         
  }
   
  Pool {
    Name = File
    Pool Type = Backup
    Recycle = yes                       
    AutoPrune = yes                     
    Volume Retention = 365 days         
    Maximum Volume Bytes = 50G         
    Maximum Volumes = 100              
  }
   
  Pool {
    Name = Scratch
    Pool Type = Backup
  }
   
  Console {
    Name = devmedia-mon
    Password = "ID-1Z-7tlOFkLymasyvks7HhyUtKkfxCd"
    CommandACL = status, .status
  }

Dentro de Jobs pode-se alterar as opções de level. A seguir são apresentadas algumas delas:

· InitCatalog: Faz o scan do fileset especificado e armazena os atributos dos arquivos no catálogo. Basicamente, permite que seja verificado se houve codificações em arquivos, deleções ou criações. Normalmente é utilizado pela primeira vez que o sistema é “backupeado”, e depois de uma mudança no sistema (exemplo: upgrade);

· Catalog: Compara o estado atual de arquivos contra as informações auferidas pelo InitCatalog. Qualquer diferença é reportada. Tipicamente este comando é executado diariamente para verificação de mudanças nos arquivos do sistema;

· VolumeToCatalog: Este nível faz com que o Bacula leia o atributo do arquivo escrito no Volume e compare com as informações do catálogo;

· DiskToCatalog: Esta opção compara os arquivos no disco (sistema) com os copiados no último backup. É útil quando são percebidos problemas no disco, e é desejável saber se o “restore” se faz necessário.

·

Já em Pools podem-se alterar os limitadores de uso dos volumes (necessários para a reciclagem). A seguir podemos observar algumas opções:

· Use Volume Once = yes: Com esta opção habilitada (o valor default é no) o Bacula só usará o volume uma vez e, após, irá encerrá-lo;

· Volume Use Duration = ttt: Período de tempo pelo qual o volume pode ser gravado. Este é iniciado a partir do primeiro “job” para ele submetido. Após este tempo, o volume é automaticamente encerrado;

· Maximum Volume Jobs = nnn: Quando atingido o número máximo de “jobs” do volume, o mesmo é encerrado;

· Maximum Volume Bytes = mmm: Número máximo de “bytes por volume”. Quando atingido, de igual sorte, o volume se encerra.

·

Esses limitadores de uso dos volumes podem ser ignorados com o uso da linha Purge Oldest Volume = Yes. Se utilizada, todos os limitadores de reciclagem de volumes mencionados serão ignorados (exceto o de tamanho máximo do volume). Trata-se de um segundo método de reciclagem de volumes, mas que não respeita tempos de retenção.

bacula-sd.conf

O bacula-sd (ou Bacula Storage Daemon) é o “estoquista” do sistema de backup. Trata-se do responsável por armazenar todos os dados, independente de quais dispositivos sejam utilizados. Um Bacula Director pode controlar vários Storage Daemons em máquinas diferentes. Na Listagem 7 pode-se observar o exemplo padrão de um arquivo bacula-dir.conf.

Listagem 7. Conteúdo do arquivo bacula-dir.conf.


 Storage {                        
    Name = devmedia-sd
    SDPort = 9103                  
    WorkingDirectory = "/var/lib/bacula"
    Pid Directory = "/var/run/bacula"
    Maximum Concurrent Jobs = 20
    SDAddress = 127.0.0.1
  }
   
  Director {
    Name = devmedia-dir
    Password = "L7NeeJ6XIsN3sJFjoiRHFuEJTTncT4DGG"
  }
   
  Director {
    Name = devmedia-mon
    Password = "3YbvH1IgpDjYTHa3NN3imJ4A5Z0z2bbYd"
    Monitor = yes
  }
   
  Device {
    Name = FileStorage
    Media Type = File
    Archive Device = /nonexistant/path/to/file/archive/dir
    LabelMedia = yes;                   
    Random Access = Yes;
    AutomaticMount = yes;               
    RemovableMedia = no;
    AlwaysOpen = no;
  }
   
  Messages {
    Name = Standard
    director = devmedia-dir = all
  }

bacula-fd.conf

O bacula-fd (ou Bacula File Daemon) é o “vampiro” do sistema de backup. Trata-se do responsável por “sugar” as informações dos computadores (arquivos) e enviá-las para o Storage Daemon. Os sistemas de backup Bacula geralmente possuem inúmeros file daemon instalados em diferentes servidores (ou até estações de trabalho), todos ligados a um mesmo “director”. Na Listagem 8 pode-se observar um exemplo padrão de um arquivo bacula-fd.conf.

Listagem 8. Conteúdo do arquivo bacula-dir.conf.


  Director {
    Name = devmedia-dir
    Password = "4pVPQ7Rca5ydDivqsHJWX9IFRz4gOgU5z"
  }
   
  Director {
    Name = devmedia-mon
    Password = "DRkBz_tyQ6QZ5GFkMrLIU443exw0Im-EK"
    Monitor = yes
  }
   
  FileDaemon {                          
    Name = devmedia-fd
    FDport = 9102                  
    WorkingDirectory = /var/lib/bacula
    Pid Directory = /var/run/bacula
    Maximum Concurrent Jobs = 20
    FDAddress = 127.0.0.1
  }
   
  Messages {
    Name = Standard
    director = devmedia-dir = all, !skipped, !restored
  }

bconsole.conf

O último de nossos módulos do Bacula é o bconsole. Trata-se da ferramenta que abre as portas para acesso e administração do sistema de backups. Para os administradores e operadores, é interessante que se tenha o bconsole instalado em seus equipamentos, pois se trata de um acesso mais seguro que o SSH na medida em que só permite o acesso ao diretor Bacula em si.

Na Listagem 9 é apresentada a forma mais simples de configuração do bconsole.conf. Nesta configuração definimos o agente do Bacula que está sendo executado em localhost (máquina local). Pode-se observar também o nome do host (localhost-dir), sua porta de atuação (DirPort = 9101), o endereço (localhost, neste caso) podendo ser um endereço IP e a senha definida pelo Bacula.

Além disso, existe a possibilidade de criar usuários que só terão acesso a determinados elementos do sistema de backup (um job específico, um cliente, etc.).

Listagem 9. Conteúdo do arquivo bacula-dir.conf.


  #
  # Bacula User Agent (or Console) Configuration File
  #
   
  Director {
    Name = localhost-dir
    DIRport = 9101
    address = localhost
    Password = "Ui3dLcjKWiR6QIyTu+PjPK6wHlziIf7fZlSiCgiZZ3jq"
  }

Utilizando Include para organizar os arquivos de configuração do Bacula

Ao invés de declarar todos os recursos dentro de um mesmo arquivo de configuração (ex.: Jobs dentro do bacula-dir.conf), é possível fazê-lo em arquivos distintos apenas citando os caminhos para os mesmos conforme o exemplo na Listagem 10, onde são inseridas várias referências a configurações externas como jobs, storages, schedules, dentre outras.

Listagem 10. Exemplo de bacula-dir.conf.


  @/etc/bacula/bacula-dir-filesets.conf
  @/etc/bacula/bacula-dir-jobs.conf
  @/etc/bacula/bacula-dir-jobdefs.conf
  @/etc/bacula/bacula-dir-clients.conf
  @/etc/bacula/bacula-dir-storage.conf
  @/etc/bacula/bacula-dir-pools.conf
  @/etc/bacula/bacula-dir-schedules.conf

Ciclo de vida dos volumes

Quando inserido um novo dispositivo de hardware (ex.: uma nova fita ou HD), o primeiro passo para sua utilização junto ao Bacula é o etiquetamento lógico (comando label). Assim que “etiquetado” (ou seja, batizado), o novo volume está pronto para gravação (ou seja, status append).

Se nada for configurado no bacula-dir.conf, este volume será gravado, diariamente, enquanto houver espaço na fita (seu volume ficará sempre append, podendo ser gravado de onde se parou, até o momento que se torne full). Ou seja, o comportamento natural do Bacula é a gravação contínua dos volumes. Dessa forma, com a configuração original, sempre serão necessários novos volumes, indefinidamente (a não ser que haja intervenção manual), pois não há uma rotação dos dados. Em outras palavras, você não programou o Bacula para automaticamente reciclar os volumes (por exemplo, após determinado período de tempo). Neste sentido, pode ser necessário adotar uma das estratégias de reciclagem apresentadas a seguir.

Reciclagem bruta

Neste método, o Bacula sempre reciclará o volume mais velho (ou seja, com mais tempo desde a sua última gravação). Desta maneira, sempre que não houver volumes disponíveis para a gravação dentro de determinado grupo de fitas (pool), o Bacula irá permitir que os dados do volume mais antigo sejam sobrescritos. A opção que habilita este comportamento localiza-se no bacula-dir.conf, dentro do recurso Pool:

Purge Oldest Volume = Yes

A grande desvantagem deste método consiste na necessidade de uma administração proativa para evitar que os dados dos backups cresçam demasiadamente, e o tempo de retenção dos dados se torne muito pequeno – já que não há nenhuma espécie de controle sobre a reciclagem.

Reciclagem por tempos de retenção

É possível estabelecer um tempo de retenção para os volumes de determinado grupo (pool) dentro do arquivo bacula-dir.conf. Para isso, utilizamos o parâmetro VolumeRetention. Um exemplo seria VolumeRetention = 6 Days, onde definimos que após seis dias os dados do volume poderão ser sobrescritos. Contudo, para que este tempo de retenção comece a ser contabilizado, é necessário encerrar o volume. Para isso, a opção abaixo pode ser utilizada (também no bacula-dir.conf, recurso Pool):

Use Volume Once = yes

Com esta opção habilitada (o valor default é no), o Bacula só usará o volume uma vez e, após isso, irá encerrá-lo.

Podemos também definir o período de tempo pelo qual o volume pode ser gravado, sendo contabilizado do início do primeiro job para ele submetido. Após este tempo, o volume é automaticamente encerrado. Geralmente, este valor é um pouco menor do que sua janela de backups. Para esta definição, o parâmetro abaixo pode ser utilizado:

Volume Use Duration = ttt 

Podemos também definir que quando for atingido o número máximo de jobs do volume, o mesmo seja encerrado. Para esta definição, o parâmetro abaixo pode ser utilizado:

Maximum Volume Jobs = nnnn 

Por fim, também podemos definir o número máximo de bytes por volume. Quando atingido, o volume se encerra. Para esta definição, o parâmetro abaixo pode ser utilizado:

Maximum Volume Bytes = mmm

Este parâmetro é indispensável para a utilização de volumes em discos rígidos para possibilitar a gravação de vários volumes e não apenas um para o disco inteiro (o mínimo recomendado são quatro volumes por disco). Para as fitas, essa opção nunca deve ser utilizada, pois a capacidade de gravação das mesmas é variável. No momento que uma destas opções atingir seu limite, o volume deixa de ter status append e passa a ser full, passando a ocorrer o Volume Retention.

Como exemplo, suponha que se deseja obter uma retenção de 7 dias (volume gravado numa segunda-feira seja sobrescrito na próxima segunda, considerando a realização de backups diários). Neste caso, as configurações serão:


  VolumeRetention = 6 Days
  Volume Use Duration = 23 hours

Assim, o tempo de retenção real dos volumes contidos nesta pool seria de 6 dias + 23 horas. Observe que esta retenção deve ser sempre um pouco menor do que o intervalo entre os backups (que no caso seria de 7 dias), de maneira a evitar a sobreposição do tempo de retenção com a necessidade de gravação de volume, na próxima segunda-feira.

Exemplo de GFS no Bacula

A implementação da estratégia GFS clássica no Bacula se dá através da definição de ao menos 03 (três) pools distintas (no bacula-dir.conf). Pools diária, semanal e mensal. Obviamente, você pode chamar de outra maneira (ex.: daily, weekly, monthly), mas a função delas deverá ser a mesma: hospedar os backups para cada hierarquia (diferenciais ou incrementais diários; full semanais e full mensais). Atente às observações a seguir:

· Quando se deseja que o Bacula sempre utilize a mesma fita para determinado dia da semana (ex.: VOL1 sempre ser gravado às segundas-feiras), deve-se criar pools específicas para cada dia da semana (ex.: diario_seg, diario_ter, etc.);

· Pode-se criar uma pool para fitas que estão fora do seu robô de fitas para evitar que o Bacula as procure durante a operação de backup – e para melhor organizá-las. Para criar uma nova pool, basta duplicar as configurações de uma pool qualquer (inicialmente a “default”), e alterar seu nome. Não se esqueça de configurá-la (tempo de retenção, tempo de uso do volume, reciclagem – “yes/no”, etc.), tudo isso no bacula-dir.conf.

Agendamento

O schedule ou agendamento também é configurado no bacula-dir.conf. Você deve associar um Job criado neste arquivo a um agendamento. Portanto, aconselhamos criar um novo schedule (ex.: agenda_gfs) e ir associando os Jobs conforme o exemplo da Listagem 11.

Listagem 11. Exemplo de agendamento.


  Schedule {
  Name = agenda_gfs
  Run = Level=Differential
  Run = Level=Full
  Pool=Diaria Monday-Thursday at 19:00
  Pool=Semanal 2nd 3rd 4th 5th
  Friday at 19:00
  Run = Level=Full Pool=Mensal 1st Friday at 19:00
  }

No exemplo, teremos backups diários de segunda a quinta, semanais na segunda, terça, quarta e quinta, e mensais na primeira sexta-feira do mês.

Retenções do Bacula

Retenção trata-se de um conceito muito importante para quem precisa trabalhar com backups. Esta expressão se encontra presente em quase toda ferramenta do gênero. Retenção consiste no período de tempo no qual os dados gravados em um backup não podem ser apagados, nem pelo sistema nem por intervenções humanas convencionais.

A única forma para apagar as informações seria explicitamente indicando que a ferramenta o fizesse (no caso do Bacula, com o comando purge). Esta proteção visa ainda evitar erros de um operador (ex.: colocar a fita errada no drive), ou do administrador através do console. Em linhas gerais: a retenção é a segurança dos seus dados. Depois de terminado o tempo de retenção, se diz que ele expirou e, dessa forma, o volume poderá ser sobrescrito em um próximo trabalho de backup.

No sistema GFS clássico, a retenção para os backups diários deve ser de aproximadamente 7 dias. No semanal, de aproximadamente um mês. E no mensal, de aproximadamente um ano.

Geralmente pode ser um pouco menos, para evitar a sobreposição do tempo de retenção com a data na qual o volume deve ser sobrescrito, como vimos anteriormente. Lembre-se que o tempo de retenção do volume só começa a ser contado quando o mesmo é encerrado, ou seja, quando ele enche (status full) ou quando previamente foi configurado um dos limitadores.

A Retenção do Volume não se confunde com as retenções de informação no catálogo (jobs e file retention), que servem como limitadores do tamanho do banco e podem ser apagadas automaticamente se a opção auto prune estiver ativada.

File e Job Retention no Bacula

As duas retenções em negrito na Listagem 12 servem apenas para preservar informações do catálogo do Bacula (banco de dados), especificamente para este cliente. Se o Auto Prune estiver ativo, após este tempo, as informações de file e jobs serão automaticamente apagadas. Ou seja, essas retenções servem para limitar o tamanho do Catálogo do “Bacula”.

Listagem 12. Exemplo de File e Job retention.


  Client { 
  Name = devmedia-fd 
  Password = "senhadadevmedia" 
  Address = x.x.x.x 
  FDPort = 9102 
  Catalog = MyCatalog 
  AutoPrune = yes 
  File Retention = 30 days 
  Job Retention = 6 months 
  }

File Retention

O file são as informações sobre os arquivos gravados em cada volume do backup. É um verdadeiro índice que permite a restauração parcial de arquivos de um determinado job. Se esta informação for expirada, não é mais possível selecionar alguns arquivos de um job para restauração, mas apenas o job inteiro.

Job Retention

A informação do job permite que ele seja restaurado pelo Bacula. Sem esta informação, só é possível a restauração através do bextract, ou se o bscan for utilizado no volume para restaurar as informações do catálogo.

Cuidado com essas duas opções. Se há um bom espaço em disco para o banco de dados Bacula, deve-se sempre aumentar estes parâmetros, principalmente a retenção do job. Se estas duas retenções forem maiores do que o tempo de reciclagem (ou retenção) do volume, não há problema, pois a reciclagem do volume também irá apagar estas informações do catálogo para aquele volume específico.

Novos clientes Bacula

Nesta seção será apresentado como configurar novos clientes para backup no Bacula. Sempre que novos hosts forem planejados para fazerem parte do projeto de backup, alguns passos devem ser respeitados para que o processo seja concluído com sucesso. O primeiro arquivo a ser configurado é o bacula-dir.conf. Observe a sequência de configurações para que o cliente seja inserido:

1. Definir um novo job para o cliente a ser criado;

2. Criar um novo recurso Client. A senha (password) será a mesma que consta no bacula-fd.conf do cliente correspondente;

3. Criar um novo FileSet, caso os arquivos a serem “backupeados” sejam diferentes do FileSet que já existe. Obs.: no caso do Windows, lembrar que deve ser utilizado / (barra) ao invés de \ (barra invertida);

4. No recurso storage, certificar-se de que o endereço utilizado seja um IP ou de que o nome da máquina esteja num servidor DNS;

5. Reiniciar os serviços do Bacula.

O segundo arquivo a ser modificado é o bacula-fd.conf. Veja a seguir a sequência de configurações:

1. Colocar o nome do director;

2. Modificar a senha que o director irá utilizar para se conectar ao cliente;

3. Reiniciar o daemon ou serviço (bacula-fd).

3.

Conclusão

Este artigo apresentou como configurar o Bacula para efetuar cópias de segurança em uma organização. Como pôde ser observado, o assunto é bastante extenso para que possa ser trabalhado por completo nesse artigo. Assim, apresentamos aqui algumas informações importantes para quem deseja iniciar os estudos e implementações com essa aplicação.

Links

Source Forge
http://sourceforge.net/projects/bacula/files/#files

Source Force - Download
http://sourceforge.net/projects/bacula/files/bacula/5.2.3/bacula-5.2.3.tar.gz/download

Software Livre
http://softwarelivre.org/bacula

Dicas-L
http://www.dicas-l.com.br

Bacula
http://www.bacula.org/en/

Bacula-br
http://www.bacula.com.br/?p=367

Viva o Linux
http://www.vivaolinux.com.br

Referências

FARIA, M.H. Bacula – Ferramenta Livre de Backup. Editora Brasport.