Prévia do material em texto

Linux Solutions
“Bacula” - Ferramenta Livre de 
“backup”
por Heitor Medrado de Faria
www.bacula.com.br
 2
Sumário
Capítulo 1 
Conceitos Básicos de “backup”......................................................................................6
1.1. Mitos do "backup".........................................................................................................7
1.2. Conceitos.....................................................................................................................12
1.3. Tipos de “backup”.......................................................................................................14
1.4. Mídias de “Backup”.....................................................................................................16
Capítulo 2 
Desenhando um Sistema de “backup”.........................................................................18
Capítulo 3 
Políticas e Melhores Práticas ......................................................................................24
3.1. Políticas de "backup":.................................................................................................24
3.2. Melhores Práticas de "backup":.................................................................................25
Capítulo 4 
Estratégias de "backup" e o Esquema GFS ................................................................26
4.1. Vantagens de um sistema de "backup" Centralizado (viabilizado pelo “Bacula”):......26
Capítulo 5 
Questões sobre “backups” em Concursos....................................................................31
Capítulo 6 
O que é o “Bacula”? ....................................................................................................37
6.1. Como ele funciona?.....................................................................................................37
6.2. Principais Características do “Bacula”:......................................................................40
6.3. O que há de novo na versão 5.0?................................................................................42
Capítulo 7 
O “Bacula” e as Ferramentas Similares ......................................................................45
7.1. Amanda (livre):............................................................................................................46
7.2. “Arcserve” (proprietária).............................................................................................47
7.3. TSM (proprietária)......................................................................................................47
Capítulo 8 
Instalando o “Bacula”..................................................................................................49
8.1. Instalando o Banco de Dados:.....................................................................................49
 3
8.2. Instalando o “Bacula” (Linux):....................................................................................51
Capítulo 9 
Configurando o “Bacula”.............................................................................................59
9.1. Passo-a-passo: Configurando o “Bacula” pela Primeira Vez.......................................59
9.2. bacula-dir.conf.............................................................................................................62
9.3. bacula-sd.conf.............................................................................................................87
9.4. bacula-fd.conf..............................................................................................................92
9.5. bconsole.conf..............................................................................................................93
9.6. Utilizando “Include” para organizar os arquivos de Configuração do “Bacula”.........94
9.7. Configurando: Ciclo de Vida dos Volumes..................................................................95
9.8. Configurando: Exemplo de “GFS” no “Bacula”...........................................................97
9.9. Configurando: Retenções do Bacula...........................................................................99
9.10. Configurando: Novos Clientes Bacula.....................................................................101
9.11. Configurando: Compressão dos "backups".............................................................102
9.12. Configurando: Migração e Cópia de Volumes.........................................................102
9.13. Configurando: Label Automático de Volumes no Bacula........................................107
9.14. Configurando: Desduplicação de Arquivos............................................................109
9.15. Configurando: Criptografia das Comunicações do Bacula (TLS)...........................111
9.16. Configurando: Criptografia dos dados Gravados no Storage................................118
9.17. A função da “pool scratch”......................................................................................121
Capítulo 10 
Primeiros Passos com Fitas Magnéticas....................................................................122
10.1. Os dispositivos de Fita-Magnética..........................................................................123
10.2. Operações com Fitas...............................................................................................124
10.3. Manipulando Robôs-de-fitas:...................................................................................124
10.4. Usando robôs com múltiplos drives gravando simultaneamente:...........................131
10.5. “Spooling” de Dados...............................................................................................131
Capítulo 11 
Comandos do “Bacula”...............................................................................................134
11.1. Lista Alfabética dos Comandos do “bconsole”:.......................................................134
11.1. Comandos especiais com Arroba (@) .....................................................................156
11.2. Executando o bconsole por Shell Script................................................................157
Capítulo 12 
Restaurando Arquivos................................................................................................158
 4
Capítulo 13 
Restaurando Informações do Catálogo .....................................................................165
13.1. Restaurando catálogo MySQL a partir do arquivo .sql ("backup").........................165
13.2. bscan.......................................................................................................................166
Capítulo 14 
Upgrade de Versões do Bacula..................................................................................168
Capítulo 15 
Acessórios para o “Bacula”........................................................................................172
 15.1 Interfaces Gráficas...................................................................................................172
 15.2. Monitoração............................................................................................................175
 Capítulo 16
16.1. Instalação do Webacula (GUI) – Versão: 3.*......................................................176
 16.1. Instalação e Configuração:......................................................................................177
 Capítulo 17
“Backup” de Aplicações Específicas com o “Bacula”.................................................183
 17.1. "backup" de Máquinas Virtuais...............................................................................183
 17.2. "backup" de Bancos de dados.................................................................................18617.3. Servidores Web.......................................................................................................193
 17.4.Serviços de Email.....................................................................................................193
 17.5. Serviços de Diretório..............................................................................................198
 Capítulo 18
“Bacula Disaster Recovery” no Linux........................................................................199
 18.1. “Bare Metal Recovery” usando um Disco de Emergência do “Bacula” .................199
 Capítulo 19
Bacula no “Windows”” ..............................................................................................208
 19.1. Instalando um Servidor Bacula no “Windows”.......................................................209
 19.2. Botando para Funcionar.........................................................................................211
 19.3. Configurando o “Bacula”.........................................................................................211
 19.4. Operando o “Bacula”...............................................................................................213
 19.5. Clientes “Windows”.................................................................................................214
 19.6. Modificações no Servidor Específicas para os Clientes Windows..........................214
 19.7. VSS Shadow............................................................................................................218
 19.8. Disaster Recovery no Windows...............................................................................218
 5
 Anexo I
Códigos de “status” do “Bacula” ...............................................................................225
 Anexo II
Comparativo Entre as Ferramentas de “Backup”......................................................228
 6
Capítulo 1 
Conceitos Básicos de “backup”
O “backup” (ou cópia de segurança) consiste na cópia de dados específicos 
(redundância), para serem restaurados no caso da perda dos originais.
 A cópia pode ser realizada para o mesmo computador, para um dispositivo de 
armazenamento ou, ainda, em outro prédio ou localidade. Desta forma, protegendo 
os dados também contra acidentes que possam acometer fisicamente a estrutura.
Independente de como os dados forem perdidos (apagamentos acidentais, 
corrupção dos dados, etc.), um “backup” eficiente consiste naquele que minimiza os 
impactos desta perda, possibilitando a restauração do arquivo ou serviço no menor 
tempo possível e com o minimo de defasagem em termos de alteração das 
informações.
Os dispositivos de armazenamento mais comuns são o “DVD, disco rígido, 
disco rígido externo, fitas magnéticas e a cópia de segurança externa. Esta última, 
transporta os dados por uma rede como a Internet para outro ambiente, geralmente 
para equipamentos mais sofisticados, de grande porte e segurança. 
 7
As cópias de segurança podem variar de acordo com a natureza dos arquivos, 
com as necessidades empresariais e com a infra-estrutura disponível. Ainda, algumas 
métricas devem ser observadas: tempo de execução (janela de “backup”), a 
periodicidade, a quantidade de exemplares das cópias armazenadas, o tempo que as 
cópias devem ser mantidas, a capacidade de armazenamento, o método de 
rotatividade entre os dispositivos, a compressão e encriptação dos dados. 
Quanto a topologia, os “backups” podem ser classificados entre 
“centralizados” ou “descentralizados”. Na modalidade “centralizada”, geralmente há 
um servidor que comanda a realização de cópias de segurança, conferindo uma 
maior praticidade na administração e economicidade pelo armazenamento dos dados 
em poucos dispositivos, ocorrendo aí um ganho pela escalabilidade.
Geralmente o “backup” é realizado pela noite, para que haja mínima 
possibilidade de impacto aos serviços utilizados em horário administrativo.
1.1. Mitos do "backup"
1.1.1. O “ROI” do Serviço de "backup"
Em se tratando de um serviço relativo à área da “Segurança” em Tecnologia 
da Informação, o serviço de "backup" não poderia faltar à regra: trata-se de um 
aspecto cujo retorno de investimento se mostra praticamente impossível de ser 
quantificado.
“Os benefícios são muito teóricos e incertos para que as 
empresas possam levá-los a sério como justificativa de 
investimento por si só. Para a maioria dos projetos em 
segurança da informação, é simplesmente impossível 
quantificar antecipadamente um ROI financeiro. Portanto, as 
organizações devem reagir com ceticismo a cálculos ou 
modelos de ROI divulgados por vendedores de soluções em 
segurança que não sejam substanciados por uma rigorosa 
pesquisa anterior, personalizada de acordo com o contexto de 
 8
cada organização.”1
Ao longo do tempo, algumas companhias que experimentam um número 
limitado de falhas tendem a reduzir a atenção e o orçamento para "backup", 
considerando eles, de certa forma, menos necessários. Ou ainda, simplesmente 
deixam de fazer as devidas expansões indicadas pela Gerência de Capacidade, 
fazendo com que o sistema não atenda adequadamente à demanda.
Necessário ter em mente que "backups” e contratos de seguro não possuem 
muita diferença:
“Similar às apólices de seguro são um investimento nos quais é preferível 
deixar de precisar do que usá-los” - conforme as palavras do autor Preston de Guise2.
Portanto, a não-ocorrência de demandas para a restauração de arquivos não 
pode, de forma alguma, constituir uma justificativa para que o serviço de cópias de 
segurança seja realizado de maneira precária – ou pior: que se deixe de fazê-lo.
Uma vantagem das soluções em software livre consiste no fato de poderem ser 
testadas e, dessa forma, obter uma flutuação menor na estimativa do ROI.
1.1.2. "Backup" não se confunde com o Gerenciamento do ciclo-de-vida 
da Informação ("ILM – Information Lifecycle Management")
Muito tem se falado sobre o ILM atualmente – inclusive, alguns 
desenvolvedores de ferramentas para "backup" tem advogado no sentido de que seria 
um dos papéis das mesmas.
Ocorre que o Gerenciamento do Ciclo-de-vida da Informação consiste em um 
processo que abrange muito mais elementos, como: a auditoria, indexação, criação, 
atualização, deleção, aspectos de armazenamento e de acesso.
Portanto, o "backup" estaria dentro, ainda, de uma subdisciplina do ILM, que 
seria o ILP (“Information Lifecycle Protection” – ou Proteção do Ciclo-de-vida da 
1 Rodrigo Faustini: http://www.faustiniconsulting.com/artigo10.htm
2 Tradução do mesmo livro: "backup" & Recovery: A Corporate Insurance Policy, p. 7, Preston de Guise.
 9
Informação), que também conteria uma série de outros fatores:
a) proteção proativa contra a perda de dados – que pode constituir em anti-
vírus ou outros aspectos em nível de aplicação, por exemplo;
b) alta disponibilidade;
c) redundância de sistemas;
d) e se mesmo assim houver perda na informação, a restauração dos dados, 
previamente armazenados pelo serviço de "backup", seria executada.
1.1.3. O serviço de "backup" versus sistemas de tolerância a falhas
“Tolerância a falhas é a propriedade que permite que 
sistemas (em geral, computacionais) continuem a operar 
adequadamente mesmo após falhas em alguns de seus 
componentes. Se sua qualidade de operação diminui, a queda 
é proporcional à severidade da falha. A tolerância a falhas é 
propriedade inerente em sistemas de alta disponibilidade…”3
Desta forma, o “backup” não vem, de forma alguma, constituir um elemento 
de tolerância a falhas. Entretanto, trata-se de um importante elementoda 
recuperação de falhas (inclusive o tempo necessário para a restauração de arquivos – 
e consequentemente de serviços, deve ser considerada uma métrica importante para 
a escolha do hardware e software utilizado pela cópia de segurança).
Algumas empresas tendem a imaginar que sistemas tolerantes a falhas 
diminuem a necessidade por "backups". Entretanto os sistemas de tolerância a falha 
são caros (nem sempre podendo ser implementados em todos os pontos críticos do 
parque computacional) e, em nenhuma hipótese, podem ser considerados 100% 
eficazes.
3 Conceito da Wikipédia: http://pt.wikipedia.org/wiki/Tolerância_a_falhas_(hardware)
 10
“nada corrompe mais rápido do que um espelho” – máxima que traduz o fato 
de que discos redundantes, por exemplo, não estão imunes à corrupção de dados – 
muito menos à deleção acidental de arquivos.
Portanto, os “backups” permanecem como uma necessidade imperativa para a 
grande maioria dos sistemas.
1.1.4. Relação Riscos X Custos dos "backups”
Os riscos da atividade de TI geralmente podem ser divididos em duas grandes 
áreas: os riscos operacionais e os comerciais. Em contrapartida, sabemos que nem 
todos as chances de perdas de dados podem ser evitadas – por mais caros que sejam 
os sistemas de proteção (ex.: um maremoto de proporções globais, uma guerra 
nuclear mundial, etc.).
Deixando de lado as hipóteses catastróficas (nas quais provavelmente a 
restauração dos dados não será mais importante), deve ser feito um gerenciamento 
de capacidade constante no sentido de verificar a relação risco versus custo dos 
sistemas de "backup", principalmente quando as opções são plurais. Exemplo: a 
armazenagem das cópias de segurança em edificação diversa de onde foram gerados 
– protegendo assim as mídias de um possível incêndio, seria preferível em relação à 
compra de um cofre anti-chamas? Ou ainda: seria interessante fazer um "backup" 
redundante (ou seja, duas cópias de segurança), de determinados dados?
Isto posto, necessário levar em consideração uma série de fatores, como a 
criticidade e natureza das informações, o grau de maturidade dos usuários, a 
periodicidade da atualização dos dados, etc.
1.1.5. As ferramentas de "backup" nativas dos Sistemas Operacionais 
seriam suficientes e/ou mais confiáveis que as ferramentas específicas para 
este serviço?
Os softwares nativos dos sistemas operacionais carecem de uma qualidade 
 11
essencial no âmbito dos "backups” – interoperabilidade. Dessa maneira, impossível 
(ou excessivamente difícil) realizar cópias de segurança de vários servidores em 
apenas um “storage” – o que representa uma enorme economia com recursos de 
armazenamento. Ainda, teríamos um maior custo pela manutenção e administração 
descentralizada de aplicações heterogêneas de "backup".
Mesmo as ferramentas proprietárias de cópias de segurança são consideradas 
mais eficientes quando comparadas com as nativas – e em relação à confiabilidade, 
não estariam há anos no mercado se não tivessem esta qualidade. O mesmo, 
analogamente, vale para as soluções livres.
Existem outras funcionalidades importantes que dificilmente são encontradas 
em ferramentas nativas, a saber:
a) possibilidade de “backups” e “restores” cruzados (ou seja, através da rede – 
de uma estação para outra diversa);
b) “restores” rápidos utilizando apenas as mídias necessárias para o trabalho;
c) catálogo para indexar os arquivos gravados, facilitando a buscar pelos 
arquivos gravados;
d) manipulação de robôs-de-fitas;
e) ferramentas de recuperação de desastres.
1.1.6. “Scripts” bem elaborados para “backup” podem suprir a 
necessidade de uma ferramenta específica?
A elaboração de “scripts” para “backup” consiste em um “retrabalho”, na 
medida que já existem aplicações bastante maduras desenvolvidas sob licenças 
“livres”. Ademais, tratar-se-ia de uma solução única, apenas utilizada no ambiente no 
qual se encontra em produção e, desta forma, impossível qualquer forma 
considerável de suporte externo ou compartilhamento de experiências em outros 
cenários.
 12
A continuidade da solução também estaria prejudicada se não houvesse uma 
detalhada documentação interna sobre os “scripts”, bem como os custos para o 
aprendizado seriam mais elevados do que com uma ferramenta de “backup” comum.
De igual sorte, as aplicações proprietárias de “backup” eventualmente 
realizam testes de performance que dificilmente seriam superados por um “script”. 
Segue o exemplo:
“Em 2004, um vendedor de "backup" comercial 
publicou seu recorde de velocidade, realizando o 
"backup" de 10 TB das informações de um cliente real, 
com uma taxa de transferência ao nível de arquivo de 
2.6 Gb/s. É razoavelmente seguro dizer que poucos, 
para não dizer nenhum, administrador de sistemas 
desenvolveria um script que atinja uma performance 
de "backup" nessa escala”4
1.2. Conceitos
1.1.1. Retenção: período pelo qual determinada informação não pode ser 
apagada do banco de dados ou da mídia de "backup" – a não ser por especial 
intervenção humana.
1.1.2. Expiração: término do prazo de retenção.
1.1.3. “Job”: trabalho de “backup” ou de “restore”. No caso do “Bacula” 
ainda há os “jobs” de verificação.
1.1.4. “Purge”: ato de eliminar os dados do catálogo a respeito de 
determinado volume (“files, jobs”, etc.). Entretanto, permanecem o “label” no 
catálogo e os dados na fita.
1.1.5. “Prune”: ato de eliminar entradas provavelmente já não necessárias 
4 Extraído do livro: "Backup" & Recovery: A Corporate Insurance Police, p. 15, Preston de Guise.
 13
no banco de dados (exemplo: arquivos e jobs expirados dos volumes.
1.1.6. SAN (“Storage Area Network”): Rede seccionada com o objetivo de 
isolar o tráfego destinado a “backup”, tanto por segurança quanto por performance. 
Utiliza protocolo SCSI.
1.1.7. Volume: divisão (espécie de caixa) reservada para o armazenamento 
dos dados de “backup”. Compartimento lógico no qual os “backups” serão 
armazenados. Pode ser criado em fitas, HD, etc., sendo que cada fita somente poderá 
conter 01 (um) volume lógico.
1.1.8. “Pool” (grupo): conjunto de volumes com características semelhantes 
(ex.: tempo de retenção). De igual sorte, trata-se de um dispositivo de segurança (se 
o “backup” utilizando determinada pool é agendado não poderão ser utilizados 
volumes de outra). O volume herda as características da pool.
1.1.9. “FileSet”: lista de diretórios (ou arquivos) que serão "backupeados". 
Pode ser utilizado para um ou vários servidores. Geralmente deve excluir diretórios 
desnecessários (/proc, /tmp). No Bacula, são suportadas expressões regulares para 
excluir ou incluir arquivos com nomes e/ou terminações específicas.
1.1.10. Catálogo: é o responsável por armazenar um índice de todos os 
arquivos armazenados pela ferramenta de "backup". Fica armazenada em um banco 
de dados. A vantagem do Bacula, é que ele suporta 3 bancos diferentes (e livres) para 
armazenamento do catálogo. 
1.1.11. Janela de “backup” (“backup window”): consiste no tempo 
máximo de duração na qual pode ser executado um "job" de "backup" ou restore, de 
maneira a não gerar impactos para os usuários do respectivo servidor. Por isso, na 
maioria das vezes, os "backups" são agendados logo após o expediente 
administrativo, momento em que os dados já não devem sofrer tantas alterações e, 
assim, aumentando a fidelidade da cópia de segurança. Lógico que, determinadas 
aplicações, possuem uma grande atividade ininterrupta (24x7) - nestas, nas quais não 
há janela de "backup", o horário de realização do "backup" torna-se menos 
importante.
1.1.12.Política de “backup”: trata-se em um documento corporativo onde 
 14
devem estar delineadas de maneira genérica (sem explicitar produtos específicos), 
como devem ser feitos os “backups” dentro da corporação. Deve seguir as normas 
ISO referentes ao tema, tentando ao máximo seguir as orientações de 
armazenamento e descarte de mídias, além de outras melhoras práticas descritas. 
Deve especificar as retenções para cada aplicação e, de igual sorte, o nível do 
“backup” (o quê deve ser armazenado).
1.1.13. MTBF (“Mean Time Between Failure”): conceito muito 
importante, que diz respeito ao tempo médio que determinado hardware (ou 
suprimento) deve ser utilizado com segurança, com a mínima probabilidade de erros. 
Exemplo: o MTBF de fitas magnéticas é, em geral, 5 anos - ou seja, depois deste 
período indica-se que sejam trocadas.
1.1.14. GFS (“grandfather, father, son”): estratégia de rotação de fitas 
mais utilizados pelos administradores. É viabilizado através da utilização de uma 
hierarquia de "pools" com tempos diferentes de retenção, gerando uma grande 
economia com mídias. Será explicado em outros capítulos.
1.1.15. “Tape virtualization”: a diminuição no custo dos HD (por Gb), aliado 
a um ganho de confiabilidade, fez com que atualmente seja muito utilizado para 
“backups”, em substituição à fita magnética. “Tape virtualization” nada mais é do que 
a criação de múltiplos volumes de “backup” nestes HD, simulando um robô-de-fitas. 
Assim, é possível implementar estratégias de retenção como o GFS.
1.1.16. "backup" Cruzado: “backup” realizado remotamente, de uma 
máquina para outra (ou para um “storage” independente, através da rede.
1.3. Tipos de “backup”
1.2.1. “Full” – faz cópia de todos os arquivos definidos na configuração 
da ferramenta, independente que os arquivos da lista ("file set") terem sido 
alterados ou não. Geralmente é realizado quando o servidor é “backupeado” pela 
primeira vez, ou no início de cada ciclo de "backups" (ex.: Ciclo Semanal GFS). Como 
é um "backup" mais longo, geralmente é iniciado na sexta-feira ou sábado, para que 
tenha a janela do final de semana para ser realizado.
 15
Se for o "backup" mais atual, apenas uma mídia será realizada para restore 
(considerando um "backup" monovolume). Entretanto, se mostra um tipo de "backup" 
extremamente caro para ser realizado diariamente, principalmente pela excessiva 
quantidade de suprimentos (armazenamento) gastos.
1.2.2. Diferencial – faz o “backup” apenas dos arquivos modificados a 
partir do último “backup full”. Exemplo: um "backup" Full ocorreu no sábado; um 
"backup" diferencial realizado na segunda só conterá os dados alterados ou criados 
na segunda; se na terça-feira for gravado outro "backup" diferencial, ele novamente 
vai gravar os arquivos alterados ou criados, desde que se gravou o "backup" Full, isto 
é, os arquivos de segunda e terça.
Assim, requer menor capacidade de armazenamento e resulta em "backups" 
mais rápidos. Em contrapartida, a restauração fica mais complexa, pois necessita 
sempre de até dois volumes (um “full” e possivelmente o último diferencial).
1.2.3. Incremental – faz cópia apenas dos arquivos modificados a partir do 
último “backup” diferencial. Ao contrário do diferencial, se for feito um "backup" 
Incremental após outro Incremental, o segundo "backup" não irá conter os dados do 
primeiro. Apesar de ser o tipo mais rápido de “backup”, tende a deixar a restauração 
demasiadamente complexa, na medida que pode exigir vários volumes (o full e todos 
os demais incrementais mais recentes). 
1.2.4. Cópia – cópia secundária ou complementar de determinado volume de 
“backup” (redundante). Muito utilizada para “backup off-site”. O volume copiado é 
mantido intacto.
1.2.5. Migração – os dados de determinado volume são migrados para outro, 
sendo que o primeiro deixa de existir. Pode ser útil quando há suspeitas de erros de 
leitura e/ou gravação em determinada mídia de armazenamento (ex.: fita, HD, etc.) e, 
dessa forma, os dados precisam ser movidos para um meio saudável.
Você consegue identificar os principais elementos e tipos de “backup” da 
empresa onde trabalha?
 16
1.4. Mídias de “Backup”
1.4.1. Tipos:
 Fita magnética: 
As fitas magnéticas geralmente trazem a capacidade no seguinte formato: 
não-compactado / compactado. Ex.: 20 / 40 Gb. Esta é uma compactação via 
“hardware” realizada pelo próprio “drive”, e deve ser privilegiada em relação a 
compressão via “software”.
A quantidade de dados compactados gravados varia de acordo com a natureza 
original das informações (ex.: arquivos já compactados como .mp3, .jpg, .zip, etc.). 
Quanto mais compactados os dados, menos poderão estar contidos numa mesma fita.
Alguns modelos de fita5:
a) Digital Data Storage (DDS) - as capacidades mais recentes são DDS-4 
(20/40GB e 3.2 MB/s de gravação / leitura) e DDS 72 (36/72GB, com mesma taxa de 
transmissão). DDS 160 (capacidade: 80/160Gb e “throughput” de 6.9MB/s)
b) Digital Linear Tape (DLT) – capacidades: 40, 300 e 800 Gb, com taxas de 
6, 36 e 60 Mb/s respectivamente.
c) Linear Tape-open (LTO) – capacidades recentes: 200/400Gb (LTO-2), 
400/800GB (LTO-3) e 800/1.6Tb (LTO-4), com taxas de transmissão de 40, 80 e 
120 Mb/s. 
Mídia óptica: 
A falta de uma capacidade, durabilidade e confiabilidade ampliadas, fizeram 
com que esse tipo de mídia não fosse tão utilizada para fins de “backup”.
Disco rígido: 
O fato dos discos rígidos estarem sempre acessíveis para o sistema 
5 Barros, E. Entendendo os Conceitos de Backup, Restore e Recuperação de Desastres. Editora Ciência 
Moderna, Rio de Janeiro, 2007.
 17
operacional, aliada a diminuição no custo por “gigabyte” e aumento de 
confiabilidade, fizeram com que aumentasse a aplicabilidade dos HD para o 
armazenamento dos “backups”. Atualmente, se mostra uma boa opção para pequenas 
e médias empresas, já que o investimento inicial é baixo (ao contrário dos robôs de 
fita).
É escalável, na medida que basta a aquisição de mais discos para que seja 
ampliada a capacidade de armazenamento.
A facilidade de operação também é um dos pontos fortes. Enquanto com 
robôs-de-fita só é possível ler ou escrever em uma fita, por “drive”, de cada vez, num disco 
rígido é possível a leitura e gravação simultânea de todos os seus volumes (ex.: “backup” 
e “restore” simultâneo).
No caso dos discos, é recomendável a criação de vários volumes dentro 
de um mesmo disco (no mínimo 04), para otimizar seu uso (evitar a perda de espaço 
ocioso).
De igual sorte, alternar o “schedule” de maneira a utilizar os vários discos 
(no mínimo 02), de maneira alternada, para que a perda de um dos discos não 
represente a perda de todas as informações de “backup” já gravadas
O “Bacula” suporta todos os tipos citados de mídias.
1.4.2. Quanto ao local de armazenamento:
 
“Backup” on-site: 
Neste caso, os dados ficam armazenados no mesmo prédio de origem 
(servidor). Assim, a ocorrência de catástrofes físicas (ex.: incêndio) poderia afetar 
não apenas o dado original, mas também a cópia de segurança.
O “backup” on-site é aceitável quando existe a existência de cofres anti-
chamas para armazenamento das mídias.
 18
“Backup” off-site: 
Oposto do “backup on-site”, os dados ficam armazenados em localidade 
diversa dos dados originais. É uma das características do “backup em nuvem”. 
Capítulo 2 
Desenhando um Sistema de “backup”
Utilizando alguns fundamentos do Gerenciamento de Projetos, vamos planejar 
(e executar!) a instalação de um sistema de “backups”.
 19
Termo de Início do Projeto: Implementar Sistema de “backup” 
(preferencialmente automatizado), que salvaguardeinformações essenciais 
- ou seja - que minimizem o impacto da perda de dados e/ou parada dos 
serviços de TI.
O que deve ser levantado no planejamento:
2.1. Prospecção sobre a existência / elaboração de uma 
política de “backup”.
Trata-se de um documento normativo que trará as diretrizes para os sistemas 
de “backup” da empresa, devendo ser constituído antes mesmo da EAP (este assunto 
será abordado no próximo capítulo).
2.2. Levantamento da natureza dos serviços e dados que 
serão protegidos.
Aqui, necessário equilibrar padronização (de agendamentos, níveis, retenções, 
etc.) em relação com as diferentes necessidades da organização. Um ambiente muito 
complexo pode trazer dificuldades na administração dos “backups”.
Importante também, verificar seu SLA (“service level agreements” / acordo de 
níveis de serviço), para saber a periodicidade adequada dos “backups”, além do 
prazo pactuado para restauração de arquivos.
De igual sorte, para cada aplicação, estudar se existem rotinas especiais que 
precisam ser seguidas para a realização de um "backup" confiável (Exemplo: "dump" 
de um banco de dados que não suporta "backup on-line").
A maioria das aplicações, traz em sua documentação quais arquivos ou como 
deve se proceder para efetuar cópias de segurança.
2.3. Levantamento dos Sistemas Operacionais envolvidos.
Infelizmente, nem todas as soluções de "backup" são como o Bacula - cuja 
gratuidade de licença e compatibilidade entre módulos para diferentes sistemas 
operacionais, dispensa uma maior precisão nesta etapa da migração.
 20
No caso das ferramentas proprietárias, a compra de uma licença para "backup" 
de máquina Linux, por exemplo, não serve para "backup" de uma estação “Windows” 
(e vice versa). Torna-se necessário um planejamento muito mais preciso e penoso - 
um verdadeiro exercício de imaginação (ou até clarividência), para adquirir licenças 
de um serviço tão dinâmico quanto cópias de segurança. De igual sorte, os módulos 
podem não ser compatíveis entre si, impossibilitando "backup" cruzado, ou modelo 
centralizado.
O cerne da questão, aqui, consiste em saber se a solução de software a ser 
adquirida suporta todos os sistemas operacionais de sua empresa (ou ao menos a 
maioria) - de preferência com módulos compatíveis. Ainda, fundamental verificar se a 
ferramenta faz “backup” de arquivos abertos (nas soluções proprietárias, geralmente 
é cobrado um alto valor por esta funcionalidade adicional).
2.4. Levantamento da Quantidade de Dados a serem 
armazenados e Gerência de Capacidade.
Estudos informam que as necessidades de "backup" crescem, em média, entre 
20 e 25% ao ano. Entretanto, um bom planejamento se mostra importante para que 
não seja adquirida uma solução de software que fique obsoleta rapidamente. em 
contrapartida, seria desperdiçar recursos a compra de um storage 
superdimensionado às necessidades reais de armazenamento.
Aqui, entra o Gerenciamento de Capacidade, conceito trazido pelo ITIL. Trata-
se de assegurar que a capacidade da infra-estrutura de TI está adequada às 
demandas do negócio conforme a necessidade e no tempo.
Boas alternativas são soluções baseadas em disco rígido, e que podem ser 
modularizadas. Um exemplo está no uso de “disk-arrays serial-ata” e “hot-swap”, que 
permitem inclusive configuração de RAID - caso não considere o uso de LVM ou BOF 
(“bunch of disks”) suficientemente segura.
Se optar por “drives” de fita singulares (ou seja - sem alimentação automática: 
robô), tenha certeza que seu "backup" dificilmente irá requerer multi-volume (mais 
de uma fita para o "backup" full). Caso contrário, será penosa a atividade de troca de 
fitas do operados.
 21
No caso de robôs de fita, a grande preocupação reside no "throughput" de 
seu(s) “drive”(s), na medida que a quantidade de fitas por "backup" não é tão 
importante, pois não requer intervenção manual. A quantidade de fitas de seu 
esquema pode aumentar muito, caso necessário - mas sua janela de "backup" não. 
Alguns robôs, suportam a instalação posterior de "drives" adicionais.
Ainda, para “backups” centralizados ou cruzados (ou seja, que importem em 
tráfego de rede), verificar a capacidade de transferência de dados, bem como 
estações críticas, nas quais o "download" dos dados possa causar impacto ao usuário. 
Neste caso, uma alternativa seria a instalação de uma placa de rede adicional.
2.5. Prospectar o CMDB* (Banco de Dados de Configuração) 
na procura por equipamentos que possam ser alocados para o 
sistema de “backups”.
Algumas vezes, encontramos tesouros perdidos em nosso parque de TI. Um 
“drive DDS”, com sorte um DLT. Somados, ou seja, como se fossem um conjunto de 
“storage”, podem fornecer uma boa capacidade de armazenamento e gravação para 
seus “backups”. O mesmo ocorre com os HD.
Vale salientar que, no caso de mídias antigas, verificar o MTBF (ou validade) 
das mesmas. Também, tenha certeza do conteúdo das mesmas antes de reciclá-las.
2.6. Escolha e aquisição de software para a realização dos 
“backups”.
Além dos aspectos já mencionados, o suporte ao "hardware" de armazenamento 
é fundamental - não só pela ferramenta a ser adquirida mas, também, pelo sistema 
operacional hospedeiro. As distribuições Linux costumam prover uma farta e estável 
compatibilidade com sistemas de fita / disco rígido, etc., aliadada à flexibilidade do 
“shell script”, configurando-se como ótima escolha para hospedar um servidor de 
“backups”.
Necessário cuidado com a operação de "autochangers" (robôs de fitas) no que 
se refere aos tempos entre os comandos de operações (carga, descarga de fitas). Se 
este tempo (utilizado pela solução de "backup") for menor do que o necessário, 
 22
podem ocorrer desagradáveis travamentos. E se a ferramenta não permitir a 
modificação destes parâmetros, tudo indica que a integração entre as soluções será 
inviável.
Não podemos esquecer que notificações por email facilitarão, e muito, a vida 
do administrador e operadores de “backups”. Ainda, a opção por uma ferramenta 
proprietária pode ocasionar um "aprisionamento tecnológico", na verdade que você 
não poderá mudar de solução, posteriormente, sem ter de renovar as licenças para 
poder restaurar o legado.
2.7. Eventual escolha e aquisição dos hardwares de 
armazenamento e servidor de "backup".
Este é um dos últimos passos no planejamento de "backup", na medida que a 
maioria das informações que subsidiarão esta escolha, já foram levantadas. Tenha em 
mente que a solução adquirida deverá permanecer, no mínimo, por 5 ou 7 anos 
(quando então já estará obsoleta, com dificuldade em adquirir suprimentos ou peças 
de reposição). Soluções definitivas nunca serão uma opção.
As opções mais usuais são o “drive” de fita manual (para soluções de até 1.2 
“terabytes” - LTO4), o robô de fitas (mais caros e, portanto, para capacidades 
superiores) e sistemas baseados em discos rígidos (que, no caso, atendem a todas as 
necessidades de armazenamento, independente do tamanho).
Os dispositivos ópticos, apesar de muito promissores, ainda se mostram muito 
limitados em termos de capacidade, podendo ser utilizados, apenas, para pequenos 
projetos.
2.8. Levantamento e preservação do legado de “backup” de 
antiga ferramenta (em caso de migração).
A maneira mais usual de se preservar determinado legado de “backup” (ou 
seja, “backup” realizado por solução que não está mais em produção na empresa), 
consiste em manter um conjunto alternativo (software e hardware) para restauração 
de arquivos antigos.
 23
Entretanto, podem ser utilizados outros métodos: coexistência de soluções 
numa mesma estação (compartilhando o hardware de '"backup"”, de maneira sempre 
alternada),ou ainda, a transferência de dados da solução antiga para a atual, através 
de "restores" e novos "backups". Esta última, apesar de econômica em termos de 
ocupação de "hardware", pode gerar um grande trabalho manual e comprometer a 
integridade dos dados.
Por ser tão problemática, a migração de sistemas de "backup" deve sempre ser 
planejada com cautela, inclusive evitando as diversas limitações impostas pelas 
licenças de "software" proprietário.
 24
Capítulo 3 
Políticas e Melhores Práticas 
3.1. Políticas de "backup":
A existência de uma política de "backup" em sua empresa, por si, está dentro 
do considerado como “melhores práticas”.
Consiste em um documento que deverá conter os princípios de como 
ocorrerão os “backups” (e “restores”), bem como o papel das partes interessadas, o 
tempo máximo para a resolução das ocorrências, a estratégia de "backup", etc.
Entretanto, deve ser genérico o suficiente para permitir liberdade razoável de 
escolha das ferramentas de "backup", bem como as soluções de “hardware”.
Ex.: pode especificar que o “backup” será feito (preferencialmente) em mídia 
magnética e de maneira automatizada (robôs de fita), mas nunca especificar 
fabricantes, modelos, referências, etc.).
Vale salientar que é importante estar de acordo com os SLA* ou OLA* 
existentes, para não gerar divergência entre a política e os contratos.
 25
3.2. Melhores Práticas de "backup":
Exemplos:
− Estratégia de "backup" condizente com a natureza dos dados armazenados.
− Testes de “restore” periódicos.
− Auditorias periódicas, inclusive com gerência de capacidade do sistema.
− Operador de fitas, administrador de “backup” e administrador de “restore” devem 
ser sempre pessoas diferentes.
− Constante documentação (inclusive banco de soluções).
− Alta disponibilidade.
− Planejamento e simulações de "disaster recovery".
− Exigência de "ticket" para “restore”
− "Desejável" ticket para cada dia de realização dos “backups”, para que seja 
informado se foram concluídos corretamente.
− Deve haver um procedimento formal de descarte das mídias não mais necessárias 
(ex.: trituração, incineração, etc;)
− Adequação à norma ISO 27002
 26
Capítulo 4 
Estratégias de "backup" e o Esquema 
GFS 
4.1. Vantagens de um sistema de "backup" 
Centralizado (viabilizado pelo “Bacula”):
- Economia de fitas na medida que é minimizada a quantidade de espaço 
subutilizado.
- Facilidade na administração, correção de erros, troca e controle de fitas.
- Economia de “hardware” (“storages”).
- Maior agilidade (“time sharing”).
−Facilidade no “restore” (catálogo único)
 27
4.1.1. Esquema GFS (“Grandfather-father-son "backup"”):
“Grandfather-Father-Son” "backup" se refere ao mais comum esquema de 
rotação de mídias para "backup". Originalmente concebido para o "backup" em fitas, 
funciona bem para qualquer estrutura de "backup" hierárquico. O método básico 
consiste em criar 3 conjuntos de "backup", sendo um diário, um semanal e outro 
mensal. Os "backup" diários ou “filhos”, são rotacionados a cada dia com um semanal 
(ou pai) a cada semana. O "backup" semanal é rotacionado, em bases semanais, com 
um mensal (“ou avô”). Ocasionalmente, um volume pode ser removido do esquema 
para estabelecer um marco (“milestone”), ou para fins de “Disaster Recovery”).
Os administradores de rede consideram o GFS como método mais simples e 
efetivo de rotação de fitas.
Benefícios:.
- Proteção de seus arquivos com um mínimo número de fitas (normalmente 
apenas uma ou duas são necessárias para o "restore" de um servidor), reciclando 
(sobrescrevendo) algumas fitas e arquivando outras.
- Reduz o desgaste das fitas e/ou outros dispositivos ligados ao "storage".
- Facilidade na localização de arquivos armazenados, devido à sistematização 
dos "backups".
Ainda não entendi. O que é GFS?
A estratégia de rotação GFS é baseada numa agenda de 7 dias (Domingo - 
Sábado), na qual é feito ao menos um "backup" “full” a cada semana. Nos demais 
dias, são feitos "backups" diferenciais (diários).
O “"backup" full” realizado durante a semana (geralmente na sexta-feira a 
noite, ou sábado), será sempre considerado como ""backup" semanal". Então, as fitas 
diárias podem ser recicladas depois de 7 dias e as semanais após um mês - mas esse 
 28
assunto será abordado em maior profundidades.
Alguns exemplos de agendamento semanal:
SUN MON TUES WED THUR FRI SAT
None Diff* Diff Diff Diff FULL None
*WEEKLY*
Exemplo 2:
SUN MON TUES WED THUR FRI SAT
Diff Diff* Diff Diff Diff Diff FULL "backup"
*WEEKLY*
*Diff = "backup" diferencial.
Na terminologia GFS, o “backup” diário é o filho e o semanal, o pai. O último 
“"backup" full” de cada mês (o primeiro ou ainda outro), será considerado o "backup" 
mensal (“monthly”) - ao invés de semanal. Este é o avô. Os "backups" mensais, devem 
ser armazenados por um período maior (meses, ou até anos), de acordo com a 
política de “backup” existente.
Exemplo Mensal:
SUN MON TUES WED THUR FRI SAT
1 2 3 4 5 6 7
None Diff* Diff Diff Diff F-WKLY** None
Tape 1 Tape 2 Tape 3 Tape 4 Tape 5
8 9 10 11 12 13 14
None Diff* Diff Diff Diff F-WKLY** None
Tape 1 Tape 2 Tape 3 Tape 4 Tape 6
15 16 17 18 19 20 21
None Diff* Diff Diff Diff F-WKLY** None
Tape 1 Tape 2 Tape 3 Tape 4 Tape 7
22 23 24 25 26 27 28
None Diff* Diff Diff Diff F-WKLY** None
 29
Tape 1 Tape 2 Tape 3 Tape 4 Tape 8
* Diff "backup" diferencial.
**F-WKLY=Full Semanal (WEEKLY).
Reciclagem de Fitas:
Por padrão, o "backup" reutiliza as fitas diárias semanalmente (ou seja, uma 
mesma fita sempre vai fazer o "backup" da segunda-feira, etc). As semanais, devem 
ser reutilizadas para cada sexta-feira (por exemplo) do mês, ou seja: uma fita será 
sempre utilizada na segunda sexta do mês, etc.
Seguindo o exemplo, você teria a proteção de 1 ano de "backups", utilizando 4 
fitas diárias, 4 semanais, e 12 mensais. Obviamente, este número pode aumentar em 
caso de "backups" multi-volumes, ou se o tempo de retenção (reciclagem) for menor 
que o padrão. 
Dica - GFS diário avançado:
Sabendo que os "backup" diferenciais diários ocupam menos de 10% do 
volume, ao invés das 4 fitas necessárias no padrão GFS comum (que gera 
uma necessidade diária pela troca das mídias), pode ser implementado o 
seguinte esquema.
Semana 1: (fita a) para todos os "backups" diferenciais diários é utilizado 
uma mesma fita, com retenção de uma semana.
Semana 2: (fita b) uma segunda fita é colocada, e será utilizada durante 
toda esta segunda semana, a não ser para realização do "backup" full 
semanal, que será feito em uma fita específica.
Semana3: (fita a) agora reciclamos a "fita a", que receberá os "backups" 
diários desta semana.
Semana 4: (fita b) ...
 30
A grande vantagem deste esquema, é que o risco de danos à fita 
provavelmente de ejetamento (ou montagem) no drive é diminuído, pois 
menos trocas de fitas são necessárias. Entretanto, as fitas são gravadas e 
regravadas em um ritmo mais acelerado.
 31
Capítulo 5 
Questões sobre “backups” em 
Concursos
5.1 Concurso SERPRO 2008 - Cargo I*:
*Autoria da CESPE (Gabarito ao final).
5.1.1. Considerando a figura seguinte, que apresenta um 
diagrama esquemático de funcionamento de um ambiente 
corporativo, na qual se destaca um sistema de virtualização de 
fita, julgue os itens de 89 a 97, a respeito de armazenamento de 
dados:
 32
89 O eventual uso de cachês junto ao elemento F teria como um de seus 
principais objetivos reduzir a latência no acesso aos dados. 
90 Os elementos F, G e H possuem a mesma finalidade básica de suportar a 
realização de "backup" e restore, sendo que G e H variam quanto ao tamanho da 
janela de operaçãoque deve ser aberta por seus clientes, a qual é maior em G que 
em H.
91 O padrão de fita LTO, empregado em muitos sistemas de "backup" em fita, 
possui elevada capacidade de armazenamento de dados, sendo que uma única fita é 
 33
capaz de armazenar entre 4 a 8 “terabytes” de dados, inclusive com o uso de 
compressão e criptografia.
92 A velocidade de transmissão de dados entre os elementos A e D é 
usualmente superior à velocidade alcançada na transmissão de dados entre C1 e G.
93 Quanto à diversidade e necessidade de sistemas e algoritmos de 
escalonamento de recursos, é correto afirmar que ela é crescente na sequencia dos 
dispositivos: G, H e F.
94 O uso de espelhamento remoto de dados apresenta maior correlação entre 
os dispositivos H e F, que entre os dispositivos H e G.
95 Considere diversas estratégias para transferência de dados entre os vários 
dispositivos apresentados. A que permite o uso de G ou H como elemento 
intermediário na transferência de dados entre C1 e C2 é denominada “server-to-
server”; que permite o uso de H como elemento intermediário na transferência de 
dados entre G e F é denominada “storage-to-storage”.
96 Com relação a diferenças nas abordagens de conectividade empregadas 
nos elementos ligados a E, é correto afirmar que o uso de interfaces de canal de fibra 
(“fibre channel”) apresenta maiores vantagens sobre o uso de interfaces SCSI, 
mesmo a primeira sendo de natureza paralela, enquanto que interfaces SCSI são 
seriais; e o protocolo de transporte FCP (“fibre channel protocol”) não pode ser 
empregado sobre interfaces físicas do tipo SCSI.
97 Considerando as similaridades nos protocolos de comunicação empregados 
nos elementos B e E, é correto afirmar que ambos podem usar o protocolo TCP/IP, 
especialmente se E permite, em pelo menos uma de suas portas, o uso do protocolo 
FCIP (“fibre channel over IP”).
Gabarito:
 34
5.2 Prova do CGU aplicada pela banca ESAF para o cargo de 
Analista de Finanças e Controle – Área – Tecnologia da 
Informação / 2004:
5.2.1. Com o objetivo de restaurar informações deve-se fazer 
cópia de segurança ("backup") que, no sistema operacional 
“Windows”, pode ser do tipo: 
a) Diferencial, no qual são copiados somente, entre os arquivos selecionados, 
os arquivos modificados no dia corrente. O atributo arquivo é desmarcado. 
b) Diferencial, no qual todos os arquivos selecionados devem ser copiados, 
independentemente de estarem ou não com seu "backup" atualizado. Este tipo de 
"backup" não atualiza o atributo arquivo. 
c) Cópia, no qual somente serão copiados, entre os arquivos selecionados, 
aqueles que estiverem desatualizados (com seu atributo arquivo marcado). Este tipo 
de "backup" não afeta o atributo arquivo. 
d) Incremental, no qual todos os arquivos selecionados devem ser copiados, 
independentes de estarem ou não com seu "backup" atualizado. Todos os arquivos 
copiados terão seu atributo arquivo desmarcado. 
e) Incremental, no qual somente serão copiados, entre os arquivos 
selecionados, aqueles que estiverem desatualizados (com seu atributo arquivo 
marcado). Todos os arquivos copiados terão seu atributo arquivo desmarcado. 
5.2.2. A respeito dos sistemas de "backup" das organizações 
é incorreto afirmar que: 
a) a política de "backup" compreende os procedimentos e a infra-estrutura 
necessários à proteção de informações com o objetivo de possibilitar a continuidade 
de suas atividades. 
b) é recomendável que cada sistema crítico para uma organização tenha pelo 
 35
menos duas cópias: uma em local próximo, para recuperação imediata e outra em 
local distante, para permitir a recuperação em caso de desastres com maiores 
dimensões. 
c) a estratégia de "backup" precisa estar focada em objetivos distintos e que 
não abrangem os requisitos de negócio e ambiente operacional da empresa. 
d) uma arquitetura de "backup" e recuperação deve incluir um plano de 
prevenção de desastres, procedimentos e ferramentas que ajudem na recuperação de 
um desastre ou falha de energia, além de procedimentos e padrões para realizar a 
recuperação. 
e) a recuperação dos dados define os procedimentos necessários ao retorno 
da operação normal dos sistemas. Se esta recuperação não funcionar, o "backup" não 
terá utilidade. 
5.3. Prova da Receita Federal aplicada pela banca ESAF 
para o cargo de Auditor Fiscal da Receita Federal – Área 
Tecnologia da Informação / 2005. 
5.3.1. Um planejamento detalhado é o ponto de partida para 
a eficácia de um plano de "backup" e recuperação. Na 
implementação de uma solução eficaz de "backup" e recuperação, 
incluindo planos de prevenção de desastres e planos de 
recuperação de desastres, o "backup" incremental é aquele que: 
a) captura os dados que foram alterados desde o último "backup" total. 
Necessita-se de uma fita de "backup" total e da fita incremental mais recente para 
executar uma restauração completa do sistema. Ele não marca os arquivos como 
tendo sido submetidos a "backup", ou seja, o atributo de arquivamento não é 
desmarcado.
 
 36
b) captura todos os dados, incluindo arquivos de todas as unidades de disco 
rígido. Cada arquivo é marcado como tendo sido submetido a "backup", ou seja, o 
atributo de arquivamento é desmarcado ou redefinido. Uma fita atualizada de 
"backup" incremental pode ser usada para restaurar completamente um servidor em 
um determinado momento. 
c) mantém dados redundantes, pois os dados alterados e não alterados são 
copiados para fi tas sempre que um "backup" incremental é executado. 
d) captura todos os dados que foram alterados desde o "backup" total ou 
incremental mais recente. Deve-se usar uma fi ta de "backup" total (não importa há 
quanto tempo ela tenha sido criada) e todos os conjuntos de "backups" incrementais 
subsequentes para restaurar um servidor. Um "backup" incremental marca todos os 
arquivos como tendo sido submetidos a "backup", ou seja, o atributo de 
arquivamento é desmarcado ou redefinido. 
e) pode ser utilizado em conjunto com o "backup" diferencial. Uma 
restauração completa exige no máximo dois conjuntos de fitas-a fita do último 
"backup" diferencial e a do último "backup" incremental. 
Gabarito:
5.2.1. - E
5.2.2. - C
3.3.1. - D
 37
Capítulo 6 
O que é o “Bacula”? 
“Bacula” é um conjunto de programas que permite administrar "backup", 
restauração e verificação dos dados de computadores em uma rede de sistemas 
variados.
Resumindo: o “Bacula” é um Programa de "backup" em rede.
6.1. Como ele funciona?
O “Bacula” é formado pelos seguintes componentes (módulos), que podem 
trabalhar de maneira independente em máquinas variadas, inclusive com sistemas 
operacionais diferentes:
6.1.1. “Director Daemon”:
Este serviço é responsável pela administração de todos os processos de 
“backup”, “restore”, verificação e arquivamento. O Administrador de Sistema usa o 
“Director Daemon” para efetuar agendamentos de “backup” e recuperar arquivos. 
 38
6.1.2. “Console Manager”: 
Este programa ajuda o administrador ou o usuário a se comunicar com o 
“Director Daemon”, pode ser executado em qualquer computador da rede e em 
sistemas operacionais diferentes, atualmente existem 3 versões do Console Manager: 
em texto puro (TTy), em interface gráfica usando bibliotecas do “Gnome” e uma 
usando bibliotecas “wxWidgets” (tanto em formato “Unix” quanto em “Windows”). 
6.1.3. “File Daemon”:
Este serviço (ou programa cliente) é o software que é instalado na máquina 
que vai ser protegida pelo “backup”, ou seja, ele vai ser responsável por enviar os 
arquivos solicitados pelo “DirectorDaemon” pela rede. Ele também é responsável em 
administrar a gravação dos arquivos de restauração comandados pelo “Director 
Daemon”. Existem versões do “File Daemon” para diferentes sistemas operacionais: 
Linux, *BSD, Unix, Windows (9x,NT,2000,XP,2003)e “Macintosh” (OSX). 
6.1.4. “Storage Daemon”:
Este serviço consiste em administrar a gravação e restauração dos dados e 
atributos dos "backups" fisicamente em mídias apropriadas, essas podem ser volume 
de dados gravados diretamente no disco rígido ou alguma mídia removível (Fita DAT, 
DVD, CD, etc…) 
6.1.5. “Catalog”: 
O serviço de catalogo é o programa responsável por manter uma indexação de 
todos os arquivos que são armazenados no "backup" e gerar uma base de dados dos 
volumes gerenciados pelo “Director Daemon”. O “Catalog” agiliza a busca de um 
arquivo no "backup" na hora que o administrador de sistema necessita efetuar uma 
restauração, como ele mantém uma base de indexação dos arquivos gravados, a 
busca por um arquivo no meio dos volumes é mais rápida. 
 39
Figura 1. Módulos do “Bacula”.
 40
Figura 2. Como Interagem os módulos do “Bacula”.
6.2. Principais Características do “Bacula”:
− Estrutura cliente/servidor
− Estrutura modular independente ("director, client, database", console de 
administração).
− GPL - economia de custos com licenças, conhecimento e possibilidade de 
customização da ferramenta.
− Inúmeros canais de suportes pela comunidade (“mailing lists, forums, IRC 
channel”, etc.)
− Farta documentação disponível na Internet.
− Portabilidade (módulos para diferentes sistemas operacionais – Windows, Linux, 
MAC, etc. - são compatíveis.
− Infinidade de recursos para a customização de “backups”.
 41
− Funcionalidade que permite a execução de “scripts” (ou executáveis) antes/depois 
do início de “jobs” ("backup"/restore), tanto no cliente quanto servidor “Bacula”.
− Operação via linha de comando ou GUI (inclusive, com diferentes interfaces web 
desenvolvidas pela comunidades. Destaques: webacula e o bacula-web – 
ferramentas de visibilidade gerencial, com gráficos, etc., sendo que a primeira 
ainda possibilita operações de "backup", restore...).
− Suporte a maioria dos dispositivos de storage do mercado (inclusive mídias 
ópticas).
− Funcionalidade para o envio de mensagens de "log" dos trabalhos de 
"backup"/restore ou ainda instruções para o operador de "backup" (diferentes 
perfis).
− 100% compatível com o esquema GFS.
− Única ferramenta de "backup" multi-banco-de-dados.
− Possui baixos requisitos de “hardware”.
− Pelo fato de ser livre, permite o desenvolvimento de uma série de "addons", por 
terceiros inclusive, potencializando os recursos da ferramenta. Inclusive, já existe 
“plugin” para o “Nagios” (monitoração).
O “Bacula” pode, perfeitamente, substituir as ferramentas 
proprietárias mais comuns (como, por exemplo, o “ArcServe” da 
“Computer Associates” e o “TCM”, da IBM).
 42
6.3. O que há de novo na versão 5.0?
Recentemente foi lançada a versão 5.0 do “Bacula”, que acrescentará novas 
funcionalidades de estabilidade aprimorada.
Muitos projetos foram completados e mais de 21 pessoas contribuíram com 
“patches”, além de muitas outras com o relato de “bugs”. Obrigado a todos.
“657 arquivos foram modificados, 104036 inserções(+), 
78504 deleções(-)”
As novas funcionalidades mais importantes são:
* Projeto 5: Opção de truncar o volume após o “purge” (para diminuir o uso 
de disco de volumes em HD).
* Projeto 6: Controle de arquivos duplicados – economizando espaço no 
armazenamento (File Deduplication using Base Jobs).
* Projeto 10: Restaurar de Múltiplos dispositivos de Storage (Restore from 
Multiple Storage Daemons).
* Projeto 11: Permitir definção de compressão por dispositivo 
(AllowCompression per Device).
* Projeto 23: Adicionar a opção “Maximum Concurent Jobs” para dispositivos, 
permitindo balanceamento de carga entre dispositivos (Add Maximum Concurent 
Jobs for Devices to balance load between drives).
* Nova opção “accurate” no “FileSet”, que pode ser utilizada para verificação 
de “checksum”, como exemplo (Add Accurate Fileset Options to configure accurate 
detection. Can use checksum verification for example.).
* Permite que o FD tenha permissão de leitura dos arquivos mas abandone a 
permissão de gravação (CAP).
* Adicionar “Tab-completion” para o “Baconsole”.
* Manipulação segura de senhas para o banco-de-dados.
 43
* Adicionou a API Bvfs, para fazer consultas ao catálogo sem precisar 
construir uma árvore na memória (memory tree).
* Adicionado teste de velocidade ao programa “btape”
* Adicionadas novas telas para o “Bat” (Autochanger content, Job view, Media 
view, …)
* Versão Windows do “Bat”
* Tradução Espanhola e Ucraniana do “Bacula”
* Permite que os “backups” Migrate, Copy, e Virtual Full leiam e escrevam na 
mesma pool.
* Novo comando: show disabled — mostra arquivos desabilitados.
* Melhorias na ACL
* Adicionado nível no status do FD
* Permite habilitar/desabilitar checagem de blocos de checksum por 
dispositivo.
Mais detalhes: 
http://www.bacula.org/5.0.x-
manuals/en/main/main/New_Features_in_5_0_0.html
Por que mudar diretamente da versão 3.0 para a 5.0? (Cadê 
a 4.0?)
“Você deve estar imaginando porque essa versão pula 
da 3.0.X para a 5.00, omitindo a versão 4.0.0. Nós 
fizemos isso por várias razões: primeiro, nós 
queríamos uma maneira de distinguir o sistema de 
numeração da versão Bacula System Enterprise da 
 44
versão do projeto Bacula. Para isso, decidimos que o 
primeiro número da versão do projeto Bacula será 
sempre ímpar, e o da versão Enterprise será sempre 
par. Consequentemente, o projeto Bacula está indo 
da versão 3.0.X diretamente para a versão 5.0.X. 
Além disso, nós queremos manter a numeração da 
versão do projeto Bacula superior a versão da 
Enterprise para indicar que o projeto Bacula é mais 
avançado ou tem mais features que o Enterprise. Só 
para lembrar, a versão Enterprise corrente é a 2.6.1 e 
a próxima versão (a ser lançado em alguns meses, 
antes de junho de 2010) será a versão 4.0.0.” - Kern 
Sibad, um dos fundadores do projeto “Bacula”
Atualizando para a versão 5.0
1. O “Director” e “Storage” devem ser atualizados ao mesmo tempo (os 
clientes podem ser atualizados mais tarde – mas não se deve demorar muito para 
evitar problemas).
2. O banco-de-dados deve ser atualizado através de um script que acompanha 
a versão 5 (não esqueça de fazer um “dump” do seu catálogo velho antes de rodar o 
“script”)
3. Não é possível migrar das versões 2.x diretamente para a 5. necessário 
atualizar o catálogo primeiro para a versão 3.
 45
Capítulo 7 
O “Bacula” e as Ferramentas 
Similares 
Uma grande vantagem do “Bacula” consiste no fato de que, por possuir 
variante da licença GPL, é distribuído gratuitamente pela Internet.
Além da economicidade gerada, a distribuição gratuita não impede que o 
administrador implemente o “backup” em um servidor, simplesmente porque ainda 
não tem comprada a licença do “software”. Para uma área tão crítica e dinâmica 
como é a das cópias de segurança, esta é uma característica chave.
Isto posto, vamos fazer um rápido comparativo com as ferramentas 
concorrentes mais comuns. Para um comparativo mas amplo e detalhado veja o 
anexo II desta obra.
 46
7.1. Amanda (livre):
“O Amanda, acrônimo para Advanced Maryland 
Automatic Network Disk Archiver, é um sistema de 
"backup" que permite a configuracao de um servidor 
mestre para realizacao de "backups" de múltiplos 
clientes numarede, com a possibilidade de 
armazenamento em fita, disco ou dispositivo otico (CD 
ou DVD) [Amanda 2006]. Ele usa o dump nativo do 
UNIX e/ou a ferramenta GNU tar e pode realizar 
"backups" de uma grande quantidade de máquinas 
rodando diferentes sistemas UNIX. Ele também usa 
Samba ou Cygwin para o "backups" de sistemas 
Microsoft Windows. Esta foi por muito tempo a mais 
popular ferramenta livre para realizacao e gerencimento 
de "backups", e ainda hoje e bastante usada.
Numa busca por ferramentas de "backup" no 
SourceForge [SourceForge 2006], o Amanda aparece em 
segundo lugar, com cerca de 180.000 downloads.” 
(Tássia Camões - ANALISE COMPARATIVA ENTRE O 
BRF E MÉTODOS TRADICIONAIS PARA O 
GERENCIAMENTO DE BACKUPS).
O Amanda foi superado pela seleção natural que rege a popularidade dos 
“software” livres de espécies semelhantes. As principais desvantagens relatadas 
dizem respeito à falta de um cliente nativo para Windows, operação não muito 
intuitiva e dificuldade para a implementação de um esquema customizado de rotação 
de fitas (ex.: GFS) .
Desde 2006, a comunidade do “Bacula” já possuía mais que o dobro de 
downloads que o Amanda.
 47
7.2. “Arcserve” (proprietária)
O “Arcserve” é uma ferramenta muito interessante de “backup”, na medida que 
suporta diversos sistemas operacionais (como o Bacula). Entretanto, a licença para 
um sistema só serve para aquele em específico, causando um incômodo 
aprisionamento tecnológico.
De igual sorte, a console de administração do “Arcserve” requer uma máquina 
possante e uma boa largura de banda na rede, para que o desempenho operacional 
seja satisfatório.
O licenciamento do “Arcserve”, além de demasiadamente “caro”, é dividido 
por funcionalidades – ou seja: cada vez que você necessitar de um novo recurso 
(exemplo: "backup" de arquivos abertos), será necessário adquirir novo módulo. No 
final das contas, o TCO se torna demasiadamente alto.
7.3. TSM (proprietária)
As características técnicas do TSM podem ser encontradas no próprio site do 
fabricante (abaixo - [1]).
 Trata-se de uma ferramenta com bastante recursos e, em certo ponto, similar 
ao “Bacula”.
A maior desvantagem fica, aqui, na falta de documentação aberta e, resultando 
em maior necessidade de treinamento e dificuldade em solução de problemas / 
“bugs”.
De igual sorte, possui todas as demais desvantagens em se adotar uma 
ferramenta proprietária...
Costuma ser “fornecido gratuitamente” para quem adquire um “storage” da 
IBM – o que consiste em uma venda casada (armadilha). No momento que o usuário 
começa a utilizar o TSM, cria um legado de “backups” difícil de ser migrado 
posteriormente – ou seja – a renovação da licença e do suporte, após o primeiro ano e 
para todos os demais, passa a ser praticamente obrigatória (aprisionamento 
 48
tecnológico). 
 49
Capítulo 8 
Instalando o “Bacula”
Existem várias maneiras de instalar o “Bacula” e, portanto, não há “receita” 
pronta.
Entretanto, podemos estabelecer alguns procedimentos que irão facilitar as 
escolhas do administrador.
8.1. Instalando o Banco de Dados:
Antes de tudo, é necessário escolher (e instalar) um dos bancos de dados 
suportados pelo “Bacula”.Na versão 5.xx, estas são as opções:
MySQL
PostgreSQL
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”, na medida que o seu 
banco é relativamente pequeno (se configurado adequadamente), mesmo que se 
 50
tenha uma grande quantidade de clientes instalados.
Os procedimentos de instalação também variam de acordo com a escolha, 
sendo que o PostgreSQL requer um passo adicional de configuração que será 
explicado. Existem diversos manuais na Internet, inclusive em Português, com todos 
procedimentos detalhados.
De qualquer sorte, o caminho mais rápido para instalar o banco de dados, 
consiste na utilização de um gerenciador de pacotes (apt, yum, yast, etc.).
No exemplo, vamos verificar uma instalação através do “apt-get”:
MySql:
# apt-get install mysql-server
Ele irá te perguntar o nome e a senha do usuário administrador do banco. 
Para fins de aprendizado (iniciantes), vamos manter o usuário “root” 
(default), e a senha em branco.
* Caso estabeleça uma senha, é necessário passá-la como parâmetro 
mais a frente, nos “scripts” que criam o banco, tabela e o usuário 
“Bacula” (ficam dentro de /etc/bacula). A sintaxe é: [“script” 
nome_de_usuário senha]
 51
Postgresql:
# apt-get install postgresql
Depois de instalado, provavelmente seu serviço de banco de dados já estará 
rodando.
Sqlite:
# apt-get install sqlite
8.2. Instalando o “Bacula” (Linux):
Por pacotes:
No meu sistema, estes são os pacotes disponibilizados pelo gerenciador de 
pacotes (apt):
debian:~# apt-cache search bacula
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
 52
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
De igual sorte, na Internet e/ou no site “bacula.org”, existem vários pacotes 
compilados para diferentes distribuições Linux. Mas observe que, neste caso, os 
pacotes já estão traduzidos para o idioma brasileiro.
Então, necessário saber quais pacotes devem ser instalados, de acordo com a 
 53
finalidade.
Da lista de pacotes, destaque para o bacula-console-qt, que é uma interface 
gráfica bastante funcional para administração do “Bacula”. Entretanto ela não serve 
para modificar as configurações do sistema.
Servidor de "backup":
Se apenas selecionar o pacote “Bacula” (apt-get install bacula), o sistema 
automaticamente escolheu uma série de pacotes que possibilitariam a montagem de 
um servidor de "backup". Entretanto, também escolheu o banco de dados que será 
utilizado: 
Os pacotes extra a seguir serão 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
Pacotes sugeridos:bacula-doc dds2tar scsitools sg3-utils sqlite3-doc
Pacotes recomendados:
 bacula-sd-tools
Os NOVOS pacotes a seguir serão instalados:
 bacula 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
0 pacotes atualizados, 14 pacotes novos instalados, 0 a serem 
removidos e 71 não atualizados.
É preciso baixar 3215kB de arquivos.
Depois desta operação, 7041kB adicionais de espaço em disco 
serão usados.
Você quer continuar [S/n]? 
 54
Portanto, está opção não serviria se desejássemos utilizar outro banco, que 
não o Sqlite.
Observe que, o pacote mtx e o mailx são dependências importantes para 
manipulação de fitas magnéticas e mensageria.
Assim, para instalar um servidor Bacula com o Mysql (exemplo), basta 
substituir os pacotes que contenham a expressão Sqlite, por Mysql. O mesmo 
para o Postgresql.
No mínimo, para montar um servidor, estes seriam os pacotes:
1.bacula-fd (para fazer "backup" do próprio servidor de "backup")
2.bacula-common (arquivos comuns do “Bacula”)
3.bacula-console (caso deseje administrar o “Bacula” através do próprio 
servidor)
4.bacula-director-[nome_do_banco] (o “director” é o servidor “Bacula” 
propriamente dito)
5.bacula-sd-[nome_do_banco] (“storage daemon” - ou seja, manipula os 
dispositivos de armazenamento. O [nome_do_banco] pode ser opcional).
6.Bacula-traymonitor (apenas se o servidor possuir interface gráfica, e você 
desejar usá-la para administrar o “Bacula”)
7.bacula-doc (documentação do “Bacula”).
A versão atual do repositório é a 2.4.4. A última antes da 3.*. Nas versões 3, 
existe mais uma dependência: o pacote libssl
Durante a instalação, o “apt” perguntará se você configurou alguma senha no 
seu banco de dados (em caso afirmativo, deve informá-la). Ainda, perguntará se 
deseja configurar automaticamente o banco – (sim!).
 55
Pós-instalação:
Depois de instalado, você pode iniciar os “daemons” do “Bacula”, sempre na 
seguinte ordem: 
/etc/init.d/bacula-fd 
/etc/init.d/bacula-sd
/etc/init.d/bacula-director 
Qualquer erro de sintaxe das configurações (que ficam em /etc/bacula), serão 
imediatamente demonstrados.
Se der tudo certo, basta digitar “bconsole” para ter acesso ao “director” - seu 
sistema está funcionando.
Entretanto, caso o “director” não retorne nenhum erro mas tenha sua 
execução terminada, muito provavelmente se trata de um problema de 
comunicação com o banco de dados. 
Caso isso aconteça, execute os três “scripts” a seguir:
/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)
Atenção!
Para todos os mencionados scripts, é possível passar o usuário do banco de 
dados e a senha. Ex.: create_bacula_database -u root -p123456 
Entre o -p, e a senha (neste caso 123456), não há espaço.
 56
Persistindo o erro, verifique como estão configurados o usuário e a senha do 
banco (/etc/bacula/bacula-dir.conf)
Se ainda assim o “daemon” do “bacula-director” apresentar problemas, 
consulte a “log” do “Bacula” para maiores detalhes sobre o erro.
Geralmente, a instalação por compilação apresenta 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 ou em algumas “distros”, bacula-fd.
Instalando por compilação:
Compilando o Servidor de "backup" (inclui o cliente e o storage daemons):
1. Acesse o endereço: www.bacula.com.br
2. Depois de acessar o “link” Download, clique em “Bacula”;
3. Baixe o código fonte (arquivo .tgz)
4. Descompacte o .tar.gz e vá para a pasta criada.
Antes de compilar, não esqueça de instalar os compiladores e demais 
pacotes necessários. No caso do Debian / Ubuntu: 
apt-get install build-essential
5. Se estiver instalando a versão 3 ou superior do “Bacula”, instale o 
pacote: libssl-dev
 57
6. Execute ./configure, com as possíveis opções:
CFLAGS=”-g -O2 ″
./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=your@address.com 
–-with-job-email=your@address.com 
–-with-smtp-host=localhost
7. Caso escolha o mysql, há uma dependência específica: libmysql++-
dev (no postgres, libpq-dev).
8. Provavelmente, você vai querer executar sem opções: ./configure (a 
apenas optando pelo banco Mysql -–with-mysql ou Postgresql --with-postgresql).
9. Depois, execute o comando: make
Obs.: o autostart faz com que o “Bacula” seja inicializado junto com o sistema 
operacional.
10. make install
11. cd $HOME/bacula/bin
12. ./bacula start
13./etc/bacula/create_bacula_database (cria o banco de dados Bacula – no 
caso do mysql, há um “script” específico)
/etc/bacula/create_bacula_tables (cria as tabelas do banco)
 58
/etc/bacula/grant_bacula_privileges (cria o usuário bacula e garante os 
privilégios no banco de mesmo nome)
Atenção!
Para todos os mencionados scripts, é possível passar o usuário do banco de 
dados e a senha. Ex.: create_bacula_database -u root -p123456 
Entre o -p, e a senha (neste caso 123456), não há espaço.
14. Configure os daemons do “Bacula” [próximo capítulo]
15. No caso de ter escolhido o Banco Postgresql, descomente o a linha 
que habilita o uso “dbi” driver, no arquivo: /etc/bacula/bacula-dir.conf (recurso 
Catalog {…}) e especifique o endereço e porta do Banco PostgresQL (default”: 
“5432)
Compilando apenas o Cliente “Bacula”:
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 [próximo capítulo]
Compilando apenas um dos “daemons” do “Bacula”:
As opções de compilação, para seleção dos daemons a serem instalados, 
são as seguintes:
./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)
 59
Capítulo 9 
Configurando o “Bacula”
9.1. Passo-a-passo: Configurando o “Bacula” pela 
Primeira Vez
O arquivo criado automaticamente na instalação do “Bacula” vai funcionar* 
apenas como um ambiente de testes. Indispensável fazer certas modificações para 
que seja um sistema de útil.
*Um dos erros mais comuns que podem acontecer 
na instalação do “Bacula” consiste na falha de 
autenticação como banco-de-dados (isso pode ser 
verificado através da log do “Bacula”). quando isso 
acontece, não é possível se conectar ao director 
(bacula-dir) – e o daemon deixa de estar em 
execução. Para corrigí-lo, tenha certeza de que 
rodou o script “/etc/bacula/grant_bacula_privileges” 
e que o login e senha de acesso ao Catálogo estão 
corretas (dento do recurtos Catalog em 
“/etc/bacula/bacula-dir.conf).
 60
Com o “Bacula” funcionando (ou seja – acessível através do bconsole), estas 
são as alterações básicas de customização:
1. Alterar o nome do “Director” e do “Monitor”, para um nome 
personalizado.
O instalador do “Bacula” utiliza para o nome do director o host da máquina. 
Se deseja modificar este nome, o melhor momento de fazê-lo é agora (quando você 
ainda está no início e não tem outrosclientes configurados).
Esta alteração precisa ser feita em todos os .conf do servidor (bacula-dir, 
bacula-fd, bacula-sd e bconsole.conf). Como exemplo, imaginemos que no novo nome 
será acaraje-dir (“director”) e acaraje-mon (“monitor”). As respectivas senhas são 
randômicas e deverão estar corretamente configuradas – portanto, não são 
necessárias mudanças, neste momento.
2. Dica Importante: A cada passo, reinicie os “daemons” para que as 
mudanças sejam aplicadas e, de igual sorte, verificar por erros de sintaxe.
3. Altere também o nome do seu único “Job” de "backup" até então 
configurado, para corresponder ao novo nome do seu “director”.
Ex.: (de default-job para acaraje-job). Reinicie os daemons.
4. Altere também o nome de seu JobDefs (definições de job). Ex.: 
“padraolinux”.
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, as opções constantes nos Jobs prevalecem sobre as do JobDefs. 
Você precisará alterar o nome do JobDefs também no Recurso “Job” (bacula-dir.conf). 
No nosso exemplo, também seria para “padrãolinux”. Reinicie os Daemons.
5. Para trabalhar com a estratégia GFS, crie três novas “pools” 
(copiando colando e substituindo os nomes) no Recurso “Pool” (diario, 
semanal, mensal).
 61
Depois, apague as duas “pools” até então existentes. O nome da “pool” padrão 
precisa ser alterado no “JobDefs”. Reinicie os “daemons”.
6. 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 na 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”. Nas 
próximas páginas, existe um exemplo de agendamento baseado na estratégia GFS. 
Reinicie os daemons.
7. Configure um “storage” (bacula-sd e depois no bacula-dir).
O “storage” configurado originalmente pelo “Bacula” (File, Device = /tmp) 
obviamente trata-se apenas de um laboratório. Entretanto, no próprio bacula-sd 
temos vários exemplos de configuração para outros dispositivos. Mais a frente, temos 
comentários também sobre estas configurações. Reinicie os daemons.
8. O FileSet original do bacula-dir.conf, vem configurado para 
"backupear” apenas uma pasta.
Como exemplo de uso inicial, aconselhável mudar para que seja ¨backupeado” 
toda o sistema (/ no caso do Linux). De igual sorte, vamos mudar o nome dele para 
“acarajefileset”, na medida que vamos utilizá-lo para o “backup” dos dados do 
próprio servidor “Bacula”. Essa alteração precisa ser replicada em outras partes do 
bacula-dir.conf. Reinicie os daemons. (Provavelmente, já percebeu que para novos 
servidores, indispensável criar outros FileSets. Entretanto, vários servidores com 
perfis semelhantes podem usufruir do mesmo FileSet – ex.: servidores linux nos quais 
tudo será "backup"eado – ou seja, o /).
Neste momento, nosso sistema de "backup" básico já está quase pronto. 
Obviamente novos clientes serão adicionados e customizações mais avançadas 
precisarão ser feitas.
De maneira inédita, seguem os arquivos de configuração comentados do 
“Bacula”, com as opções (variáveis) mais importantes, à medida que são inúmeras as 
 62
possibilidades. 
Observe que, se estiverem numa mesma máquina, os módulos “bacula-fd”, 
“sd” e “director” devem ser carregados exatamente nesta ordem.
9.2. bacula-dir.conf
O “Bacula Director” (ou diretor “Bacula”) é o maestro deste 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”.
Segue um arquivo customizado (inclusive com indexação), com comentários 
sobre as principais opções do “Bacula”. A ordem entre os “recursos” pode variar sem 
que haja problema na configuração (versão 5.*):
Legenda:
Recomendável alteração 
Não precisa ser alterado
 63
############ 1.0 Director ############# 
# Logo abaixo, você define quem será seu diretor. 
Director { 
Name = acaraje-dir 
# Batize – crie um nome para seu diretor. É assim que ele será 
chamado pelo fd e sd.
Description = "Sistema de "backup" Baiano" 
# Rápida descrição que aparecerá quando do acesso ao Bacula
DirPort = 9101 
# Porta padrão, na qual o bconsole (ou soluções semelhantes) 
usarão para entrar em contato com o diretor.
Password = "senha_console" 
# Senha que deve ser configurada também na ferramenta de console 
(ex.: bconsole.conf), para permitir acesso ao Bacula.
QueryFile = "/etc/bacula/scripts/query.sql" 
# Arquivo com comandos personalizados de pesquisa SQL 
[Avançado].
WorkingDirectory = "/var/bacula/working" 
# Pasta de trabalho do “Bacula”.
PidDirectory = "/var/run" 
# Diretório dos processos Bacula.
Messages = daemon-messages 
# para onde mensagens genéricas do bacula devem ser enviadas).
MaximumConcurrentJobs = 50 
# Número máximo de jobs simultâneos que podem acontecer no 
“diretor”. Obviamente, o número máximo de jobs tem de ser maior 
que 1 para os “storages” utilizados.
Heartbeat Interval = 120 
# Opção que evita erros de “time out” entre as conexões do fd e 
sd com o diretor.
} 
######### Jobs ########## 
 64
# Aqui configuramos os “jobs” individualmente. Geralmente, um 
por “cliente” “Bacula”.
# Serão aceitas as mesmas opções do “JobDefs”, sendo que as do 
“job” sobrepõem as configurações gerais de definição.
Job { 
Name = cliente1-job 
# Nome do “job” de "backup". No caso, o sufixo -job indica que 
trata-se de um “job”, mas é opcional – este nome é arbitrário.
JobDefs = jobdefs-File 
# Escolhi as definições do “job”. Neste caso, apontei para a 
definição que prevê “backup” em disco, configurada 
anteriormente.
Client = cliente1-fd 
# Este é o nome do meu cliente “Bacula”. Este nome é arbitrado 
pelo administrador, mas precisa ser igual ao nome que consta do 
bacula-fd.conf correspondente e à configuração do “Client” neste 
arquivo (mais abaixo). O sufixo (fd) do nome, é importante para 
saber que se trata de um cliente.
FileSet = fileset-client-unix 
WriteBootstrap = "/var/lib/bacula/bootstraps/cliente1-
fd.bsr" # Esta diretiva cria um arquivo que poderá ser usado, 
somente, para um “job” de “restore”, e é opcional. Ele contém 
uma lista de fitas e arquivos armazenados durante o "backup".
Enabled = Yes 
} 
 
Job { 
Name = cliente2-job 
# Observe que, praticamente copiamos toda a configuração do 
“job” anterior. Mas, no caso, trata-se de um segundo cliente 
“Bacula”. Podemos configurar uma quantidade infinita de “jobs” 
para um ou mais clientes, da mesma maneira. Ainda, importante 
 65
criar um “job” para “"backup"ear” os arquivos do próprio 
servidor “Bacula”, que também deverá ter um bacula-fd. No 
exemplo, vamos supor que este seja o cliente2-fd.
JobDefs = fileset-baculaserver 
Client = cliente2-fd 
FileSet = fileset-client-unix 
WriteBootstrap = "/var/lib/bacula/bootstraps/cliente2-
fd.bsr" 
Enabled = Yes 
} 
######################################### 
# Importante! "backup" do Catálogo# 
######################################### 
Job { 
# Este é um “job” especial, pois se trata do “backup” do Banco 
de Dados utilizadopelo “Bacula” (catálogo). Vem sempre 
configurado por padrão quando da instalação.
Name = CATALOG
JobDefs = jobdefs-changer 
Client = cliente2-fd 
Level = Full 
Priority = 99 
# Ou seja, sempre deve ser executado após todos os demais, para 
que contenham os dados do catálogo necessários para a 
restauração dos “backups” realizados anteriormente a um possível 
“crash” do banco.
FileSet = fileset-catalog 
# Deve possuir um “fileset” específico. O único objetivo deste 
“job”, é copiar um “dump” do catálogo do “Bacula”.
Pool = Tape-Daily 
Schedule = schedule-Changer 
# Geralmente possui uma schedule específica (por padrão), mas 
 66
pode compartilhar o agendamentodos demais “jobs”.
WriteBootstrap = "/var/lib/bacula/bootstraps/catalog.bsr" 
RunBeforeJob = "/etc/bacula/make_catalog_"backup" bacula 
bacula" 
# Estes scripts também vêm configurados junto com a instalação 
do “Bacula”. O “RunBeforeJob”, cria o “dump” do catálogo. O 
“RunAfterJob” (abaixo), deleta o “job” depois que foi armazenado 
para o volume.
RunAfterJob = "/etc/bacula/delete_catalog_"backup"" 
} 
Job { 
Name = "RESTORE" 
# Trata-se de um “job” opcional para a realização de “restore” 
(pré-definições). Entretanto, o mais usual é o uso do comando 
“restore”.
Client = client2-fd 
Where = "/tmp/restores" 
# Aqui é definida a pasta padrão de restore. Ela pode ser 
modificada quando da submissão do “job”.
Enabled = yes 
Type = Restore 
# Estou dizendo para o “Bacula” que é um “job” de restore.
Priority = 10 
FileSet = fileset-full 
# Deve ser o mesmo do “job” que gravou os dados ("backup").
Replace = always 
# Se houver algum arquivo com o mesmo nome, que seja 
sobrescrito. Você pode alterar esta opção quando da submissão do 
“job”.
Storage = File-Storage 
Pool = File-Daily 
Messages = job-messages 
 67
} 
Job { 
Name = "VERIFY" 
Client = client2-fd 
Type = Verify 
# Este é um “job” que permite comparar o conteúdo do catálogo 
com o do sistema de arquivos, ou o que está sendo 
“"backup"eado”. Ainda, para verificar se o que está escrito na 
fita pode ser lido. Muito útil para automatizar testes de 
restauração, e a integridade de seus sistemas. 
Level = VolumeToCatalog 
# Aqui escolhemos um tipo de verificação, dentre os seguintes:
 
Priority = 10 
FileSet = fileset-full 
Storage = File-Storage 
InitCatalog: Faz o “scan” do “fileset” especificado e armazena os atributos dos 
arquivos no catálogo. Basicamente, permite que seja verificada se houve 
modificaçõ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 em 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.
 68
Pool = File-Daily 
Messages = job-messages 
} 
######### 6.0 FileSets ########### 
# 
# No “FileSet” se encontram as informações de “o quê” deve ser 
“"backup"eado”, sendo que é fundamental para que o “job” seja 
executado. Vale salientar que, após qualquer mudança no 
“FileSet” o “Bacula” automaticamente promoverá o próximo 
“"backup"a” para “full”.
# Ainda, podem ser configuradas a compressão, encriptação e 
assinaturas a serem aplicadas a cada arquivo.
FileSet { 
Name = fileset-client-linux 
# Nome do fileset. Um fileset pode ser usado para mais de um 
servidor.
Include { 
Options { 
Signature = SHA1 
# Método de verificação dos arquivos. Pode ser MD5.
onefs=no 
# Indica que os “filesets” podem ser varridos recursivamente, 
mesmo que estejam em outro sistema de arquivos. Exemplo: 
selecionando o /,o /boot em outra partição será “"backup"eado”. 
Exclude = Yes 
# Aqui estamos excluindo arquivos pouco úteis para o “backup”.
wild = "/tmp" 
wild = "/proc" 
wild = "/mnt" 
wild = "/sys" 
wild = "/net" 
wild = "/misc" 
 69
wildfile = "*.iso" 
} 
File = / 
} 
} 
FileSet { 
Name = fileset-client-windows 
 Include {
 Options {
 WildFile = "*.obj"
 WildFile = "*.exe"
 # Aqui vem um exemplo para que não seja feito "backup" de 
alguns arquivos pouco úteis do windows:
WildDir = "[A-Z]:/Documents and Settings/*/Cookies"
WildDir = "[A-Z]:/Documents and Settings/*/Recent"
WildDir = "[A-Z]:/Documents and Settings/*/Local 
Settings/History"
WildDir = "[A-Z]:/Documents and Settings/*/Local 
Settings/Temp"
WildDir = "[A-Z]:/Documents and Settings/*/Local 
Settings/Temporary exclude = yes
}
File = "C:/My Documents"
}
FileSet { 
Name = fileset-baculaserver 
Include { 
Options { 
Signature = SHA1 
onefs=no 
Exclude = Yes 
 70
wild = "/tmp" 
wild = "/proc" 
wild = "/bacula-sql" 
wild = "/net" 
wild = "/misc" 
wild = "/sys" 
wild = "/var/bacula/working" 
wild = "/var/lib/mysql" 
wildfile = "*.iso" 
 } 
File = / 
} 
} 
FileSet { 
Name = fileset-catalog 
# Este é o "backup" do “dump” do banco de dados do “Bacula”. 
Portanto, sempre terá apenas um arquivo (bacula.sql). 
Include { 
Options { 
Signature = SHA1 
 } 
File = "/var/bacula/working/bacula.sql" 
} 
} 
############# Storages ############# 
# Aqui você configura quais são os bacula-sd (Storage Daemons) 
que serão utilizados pelo Director. Podem ser configurados 
quantos dispositivos forem necessários.
# No exemplo, este servidor possui dois “drives” manuais de 
fita, além de um robô-de-fitas (autochanger) com mais dois 
“drives” instalados.
 71
Storage { 
Name = ultrium-lto2-Tape 
# Nosso primeiro “storage”. O nome pode ser escolhido (qualquer 
um), mas tem de ser exatamente igual à configuração 
correspondente do bacula-sd. Neste caso, trata-se de um 
dispositivo de fita.
Address = 10.110.10.1 
# Endereço IP do nosso storage daemon.
Password = "senha storage" 
# Senha do “storage daemon” (constante no bacula-sd.conf).
Device = LTO2 
# Aqui poderia ser colocado qualquer nome (desde que igual ao 
constante do bacula-sd.conf), que o “backup” iria funcionar. 
Interessante que seja um nome representativo do “device”.
MediaType = LTO3 
# Da mesma forma pode ser um nome arbitrário. Entretanto, 
"backups" gravados com o “media type” x, não poderão ser lidos 
por um “device” cuja configuração esteja em “media type” y – ou 
seja, serve para “segregar” os diferentes tipos de mídia para o 
“Bacula”
MaximumConcurrentJobs = 10 
# Limita a quantidade máxima de “jobs” simultâneos para este 
“storage” em específico. Portanto, além destes 10, podem ser 
executados outros “jobs” simultâneos, desde que apontando para 
outro dispositivo e que a quantidade máxima de “jobs” do recurso 
“director” permita (no caso configuramos em 50).
} 
#Storage { 
# Name = ultrium-lto2-Tape2 
# Exemplo de um segundo “storage” (comentado). Neste caso, 
também, trata-se de um “drive” de fita.
# Address = 10.110.10.1 
# Endereço do “storage daemon” (observe que pode ser o mesmo 
 72
utilizado no drive anterior).
# Password = "senha storage"
# Outra senha de “storage”, neste caso específica para este 
segundo dispositivo.
# Device = LTO2-2 
# MediaType = LTO3 
# MaximumConcurrentJobs = 5 
#} 
Storage { 
Name = ultrium-lto2-Changer 
# As coisas ficam mais interessantes – trata-se da configuração 
para uso de um robô-de-fitas (que no nosso exemplo, independe 
dos “drives” individuais que acabamosde configurar).
Address = 10.110.10.1 
# Endereço do “storage daemon”
Password = "senha storage" 
Device = PV132T 
# Nome representativo do dispositivo robô (igual ao que consta 
no bacula-sd.conf).
MediaType = LTO3 
# Observe que, tanto os “drives” avulsos quanto os dois “drives” 
que estão no robô, estão com o mesmo tipo de fita configurado: 
“LTO3”. Assim, uma fita gravada pelo robô pode, por exemplo, ser 
lida por um dos drives manuais (e vice-versa).
MaximumConcurrentJobs = 20 
# Quantidade máxima de “jobs” para o robô-de-fitas. Observe que, 
mesmo tendo dois drives, o limite é 20 “jobs” (ou seja – 10 para 
cada, em média).
Auto Changer = Yes 
# Aqui você diz ao “Bacula”: “Este é um robô-de-fitas.”
} 
Storage { 
 73
Name = File-Storage 
# Geralmente o “Bacula” vem, por padrão, com este “backup” para 
disco configurado. O diretório de destino dos dados está 
configurado no “bacula-sd”.
Address = 10.110.10.1 
# Endereço do “storage daemon”
Password = "senha storage" 
Device = File 
MediaType = File
MaximumConcurrentJobs = 10
} 
#Storage { 
#
# Name = baculajr-sd 
# Aqui temos a configuração de um segundo “storage daemon” 
atendendo ao mesmo “director”. Observe que o endereço abaixo 
muda.
# Address = 207.230.229.89 
# Endereço do “storage daemon”
# Password = "senha storage2" 
# Esta senha está configurada no bacula-sd correspondente 
(bacula-jr).
# Device = File 
# MediaType = File 
# MaximumConcurrentJobs = 5 
#} 
############# 3.0 Pools ############### 
# Chegou a hora de executar o planejamento de seus “backups”. A 
configuração das “pools” nos dizem quanto tempo suas cópias de 
seguranças serão retidas, além de como será feita a reciclagem 
(reutilização) dos volumes.
 74
# Volumes de uma mesma “pools” possuem características 
semelhantes.
Pool { 
Name = Tape-Daily 
# Aqui, temos uma pool de fitas diárias
 PoolType = "backup" 
# Outros tipos estão planejados, mas somente “backup” 
implementado na versão atual do Bacula.
VolumeRetention = 13 Days 
# Este é um dos elementos da primeira modalidade de reciclagem 
automática de volumes no “Bacula”. Aqui, está configurado que os 
volumes desta pool deverão ser mantidos por 13 dias, depois de 
“encerrados” (status full ou used). Este encerramento poderá se 
dar por uma destas opções na caixa de texto abaixo:
Limitadores de uso dos volumes (necessários para a reciclagem):
Use Volume Once = yes # Com esta opção habilitada 
(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, do início do primeiro “job” para 
ele submetido. Após este tempo, o volume é 
automaticamente encerrado.
Maximum Volume Jobs = nnn # Quando atingido o numero 
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.
 75
Recycle = Yes 
# Permite que o “Bacula” recicle volumes automaticamente.
Purge Oldest Volume = Yes 
# Esta é uma segunda modalidade de reciclagem que não respeita 
tempos de retenção. Aqui, o “Bacula” sempre que não encontrar 
fitas disponíveis para gravação na “pool” (append, purgued, 
recycled), ele irá “purgar” o volume mais antigo 
automaticamente. Portanto, esta opção deve ser utilizada com 
cuidado.
} 
Pool { 
Name = Tape-Weekly 
PoolType = "backup" 
VolumeRetention = 28 Days 
# Em se tratando de uma “pool” semanal, observa-se que o período 
de retenção deve ser maior (aproximadamente um mês). De igual 
sorte, para reciclagem, devem ser observadas as mesmas regras 
anteriormente citadas.
Purge Oldest Volume = Yes 
Recycle = Yes 
} 
Ignorando a necessidade de Limitadores de uso dos 
volumes:
Através da próxima linha (Purge Oldest Volume = Yes), todos os 
limitadores de reciclagem de volumes mencionados sã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. Chamamos aqui de 
“Reciclagem Bruta”, que será explicada mais a frente.
 76
Pool { 
 Name = Tape-Monthly 
PoolType = "backup" 
VolumeRetention = 346 Days 
# Aqui, temos uma pool Mensal, com uma retenção bastante 
superior à semanal. No caso, a retenção é de aproximadamente um 
ano. Entretanto, tem empresas que optam por uma retenção de 2 
anos ou, ainda, pela criação de uma quarta pool (ou hierarquia) 
– a Anual.
Purge Oldest Volume = Yes 
Recycle = Yes 
} 
Pool { 
Name = ManualTapes-Daily 
# Neste momento, as pools para volumes que atenderão ao robô-de-
fitas já foram todas configuradas. Agora, vamos repetir o 
procedimento para os volumes específicos das fitas que alimentam 
os drives manuais.
PoolType = "backup" 
VolumeRetention = 12 days 
Purge Oldest Volume = Yes 
Recycle = Yes 
} 
Pool { 
Name = ManualTapes-Weekly 
PoolType = "backup" 
VolumeRetention = 28 days 
Purge Oldest Volume = Yes 
Recycle = Yes 
} 
 77
Pool { 
Name = ManualTapes-Monthly 
PoolType = "backup" 
VolumeRetention = 350 days 
Purge Oldest Volume = Yes 
Recycle = Yes 
} 
Pool { 
Name = File-Daily 
# Idem – desta vez, para os “backups” realizados em disco-
rígido.
Pool Type = "backup" 
Volume Retention = 13 Days 
Recycle = Yes 
Purge Oldest Volume = Yes 
MaximumVolumeBytes = 200G 
# Temos uma novidade! Para os “backups” em disco, é sempre 
interessante estabelecer um limite para o tamanho dos volumes. 
Desta forma, devemos ter uma quantidade necessária para que as 
retenções sejam respeitadas.
} 
Pool { 
Name = File-Weekly 
Pool Type = "backup" 
AutoPrune = yes 
Volume Retention = 60 Days 
Recycle = Yes 
Purge Oldest Volume = Yes 
MaximumVolumeBytes = 200G 
} 
 78
Pool { 
Name = File-Monthly 
Pool Type = "backup" 
AutoPrune = yes 
Volume Retention = 365 Days 
Recycle = Yes 
 Purge Oldest Volume = Yes 
MaximumVolumeBytes = 200G 
} 
#### JOBDEFS #### 
JobDefs { 
# A partir deste momento, começamos a configurar os “jobs” de 
"backup" que serão realizados no seu servidor.
# O recurso “JobDefs”, consiste numa série de características 
comuns à vários “jobs”. Na verdade, serve para que as mesmas 
linhas não sejam repetidas (no bacula-dir.conf) para cada um dos 
“jobs” que serão criados.
Name = jobdefs-File 
# Atribuímos um nome a esta definição de jobs. Aqui, as 
informações serão utilizadas para os “backups” em arquivo (disco 
rígido).
Enabled = yes 
# Aqui você pode habilitar (desabilitar) “jobs”, sem a 
necessidade de descomentar (comentar) linhas da configuração.
Type = "backup" 
# Pode ser: "backup" / restore / verify / admin
Level = Differential 
# Nível padrão do “backup”. 
Priority = 10 
# Prioridade dos “jobs” que apontam para este “JobDef”. Quanto 
 79
menor este número, maior prioridade o “job” terá em relação a 
outros.
FileSet = fileset-client-linux 
# Este “fileset” será configurado também no bacula-dir.conf 
(abaixo). Ele dirá “o quê” deve ser “"backup"eado”. Neste caso, 
iremos usar um mesmo “fileset” para vários servidores.
Schedule = schedule-File 
# Da mesma forma que o “fileset”, o “schedule” também será 
configurado adiante. Importante salientar que, no agendamento, 
podem ser modificadas algumas dessas características padrão 
definidas aqui no “JobDefs”. O exemplo mais comum, é o “level” 
(nível) do “backup”, que poderá ser “full” enquanto aqui está 
configurado como diferencial.
Storage = File-Storage 
# Já configuramos o storage no bacula-dir.conf. Aqui, estamos 
apenas apontando para ele.
RunScript { 
# Esta opção é muito interessante. Permite que o bacula execute 
“scripts”, automaticamente, antes ou depois de um “job”, tanto 
no cliente quanto no servidor “Bacula”.
Runs On Failure = No 
#Permite (ou não) que o “job” seja executado caso o “script” 
termine em erro. Se isso acontecer, todo o “job” irá falhar.
Runs On Client = No 
# Neste caso, o “script” será executado no próprio servidor 
“Bacula” (hospedeiro do “Bacula Director”). Se fosse “yes”, este 
“script” seria executado no cliente (bacula-fd.conf).
Runs When = After 
# Pode ser “Before” (antes) ou “After” (depois) do “job” de 
"backup".
Fail Job On Error = Yes 
# Se ativa, esta opção marca como “erro” o “job” de “backup”, 
mesmo que os arquivos tenham sido copiados, se o “script” houver 
 80
falhado.
Command = "/etc/bacula/scripts/postBaculaJob.pl 
-c \"%c\" -d \"%d\" -i\"%i\" -l \"%l\" -n \"%n\" -o 
/etc/bacula/status/%c_%n-status.log" 
# Aqui temos o script propriamente dito, que será executado 
depois dos “jobs” (exemplo).
 } 
Pool = File-Daily 
# Pool padrão para o “job”. Obviamente, poderá ser alterada pelo 
agendamento ou pelo usuário (no caso de job manual).
Messages = job-messages 
# Para onde devem ser direcionadas as mensagens referentes aos 
“jobs”.
} 
JobDefs { 
# Mais uma definição de “job”. Desta vez, para os “backups” 
utilizando robô-de-fita.
Name = jobdefs-changer 
# O nome que atribuímos a estas definições de “jobs” (pode ser 
qualquer um)
Enabled = yes 
Type = "backup" 
Level = Differential 
Priority = 10 
FileSet = fileset-client-unix 
Schedule = schedule-Changer # Aqui, mudamos o “storage” em 
relação às definições anteriores.
Storage = ultrium-lto2-Changer 
Pool = "Tape-Daily" 
PreferMountedVolumes = No 
RunScript { 
Runs On Failure = No 
 81
Runs On Client = No 
Runs When = After 
Fail Job On Error = No 
Command = "/etc/bacula/scripts/postBaculaJob.pl 
-c \"%c\" -d \"%d\" -i\"%i\" -l \"%l\" -n \"%n\" -o 
/etc/bacula/status/%c_%n-status.log" 
} 
Messages = job-messages 
} 
############# 5.0 Clients ############## 
# Aqui podemos configurar uma infinidade de clientes “Bacula” 
que irão se conectar com este “Director”, sejam eles “Windows” , 
“Linux” ou “MacOS”.
Client { 
Name = cliente1-fd 
# Já utilizamos este nome anteriormente na configuração de seu 
“job”.
Address = 0.0.0.0 # Endereço IP da máquina com este cliente 
instalado. 
FdPort = 9102 
# Porta padrão utilizada pelo “Bacula”.
Password = "senha_cliente1" 
# Esta senha é configurada também no bacula-fd.conf 
correspondente. Ou seja – precisa ser exatamente igual ao campo 
“Password” que lá existe.
FileRetention = 60 Days 
# Aqui limitamos o crescimento do catálogo. Com o “autoprune” 
ativo, as informações sobre os arquivos “backupeados” serão 
automaticamente excluídos do banco de dados após esse período de 
 82
tempo. Então, só será possível restaurar todo conteúdo de um 
“job” de “backup” para um mesmo cliente, sem a opção de 
selecionar apenas alguns arquivos. Entretanto, através do 
utilitário “bscan” que acompanha o “Bacula”, estas informações 
podem ser reinseridas no catálogo.
# Observe que, as informações gravadas no volume (dados) não 
sofrem alteração em nenhum momento.
 JobRetention = 1 year 
# Depois que a retenção do “job” é expirada, as informações do 
mesmo são apagadas do catálogo – ou seja, é como se não 
existissem para o “Bacula”. De igual sorte, os dados gravados no 
volume permanecerão intactos, podendo ser restaurados com o 
“bscan”.
Catalog = catalog 
AutoPrune = Yes 
# Indica que, após as retenções, as informações do catálogo 
serão eliminadas automaticamente.
} 
 
Client { 
Name = cliente2-fd 
# Aqui, repetimos as informações para configurar o segundo 
cliente. Podemos inserir quantos clientes quanto necessários no 
bacula-dir.conf.
Address = 0.0.0.0 
FdPort = 9102 
Password = "senha_cliente2" 
FileRetention = 60 Days 
JobRetention = 1 year 
Catalog = catalog 
AutoPrune = Yes 
} 
 83
########### 7.0 Catalog ########### 
Catalog { 
Name = catalog 
# Este nome geralmente não é alterado. A não ser, que esteja se 
trabalhando com dois catálogos distintos, quando estes deverão 
ter nomes distintos. Não precisa estar relacionado ao nome real 
do banco-de-dados.
DBName = bacula # Informações criada por padrão na 
instalação do Bacula.
User = bacula 
Password = "senha_catálogo" 
DB Address = localhost 
DB Port = 3306 
} 
Console { 
Name = "backup"-monitor 
# Opção restrita para uso do “tray_icon” na instalação do 
“Bacula” em interface gráfica. Configurada por padrão.
Password = "senha_monitor" 
CommandACL = status, .status 
} 
Messages { 
# Aqui se define como mensagens são tratadas e como deverão ser 
enviadas pelo “Bacula”. Cada “daemon” do “Bacula” é capaz de 
mandar mensagens. Entretanto, por uma questão de organização, 
por padrão elas são enviadas ao “director”, que as centraliza e 
repassa aos usuários configurados.
Name = daemon-messages 
# Nome arbitrário, configurado por padrão e que serve como 
 84
endereço para que o “job” e/ou “daemon” envie suas mensagens. 
Neste caso, utilizamos o “daemon-messages” para envio das 
mensagens dos daemons.
MailCommand = "/usr/sbin/bsmtp -h localhost -f \"\(Neocode 
Bacula\) %r\" -s \"Bacula daemon message\" %r" 
# Também vem configurado por padrão, e traz as opções da 
mensagem, para que sejam personalizadas. São elas:
Mail = "backups"@example.com = all, !skipped 
# Aqui inserimos um ou mais emails (separados por vírgula), para 
receber as mensagens do bacula relativas aos “jobs”. A opção 
“skipped”, ignora as mensagens que o “Bacula” não interpreta 
como erro (exemplo: arquivos excluídos no “FileSet”).
Console = all, !skipped, !saved 
# Envia as mensagens para o “bconsole”, que podem ser lidas 
através do comando messages, ou automaticamente se assim 
configurado.
Append = "/var/lib/bacula/log" = all, !skipped 
# Insere a mensagem enviada no final de um arquivo do servidor 
(append).
} 
Messages { 
%% = % 
%c = Nome do Cliente
%d = Nome do Director
%e = Código de Saída do Job (OK, Error, ...) 
%i = “Job Id” 
%j = Nome único do “Job”
%l = “Job” level 
%n = Nome do“Job”
%r = Recipentes 
%t = Tipo do “job” (e.g. Backup, ...) 
 85
Name = job-messages 
# Aqui, estamos configurando o envio de mensagens dos “jobs”. 
MailCommand = "/usr/sbin/bsmtp -h localhost -f \"\(Bacula\) 
%r\" -s \"Neocode BACULA: %t %e of %c %l\" %r" 
OperatorCommand = "/usr/sbin/bsmtp -h localhost -f \"\
(Bacula\) %r\" -s \"Neocode BACULA: Intervention needed for %j\" 
%r" 
Mail = "backups"@example.com = all, !skipped 
Mail on error = "backups"@example.com = all, !skipped 
# Faz a mesma função da opção “Mail”, mas somente se o “job” 
terminar em “erro”.
Operator = "backups"@example.com = mount 
# Diferente do “mail”, a opção operator envia a mensagem assim 
que chega ao “Director” (ou seja, não espera o término do “job”. 
É útil para o envio de mensagens de intervenção manual (exemplo: 
inserção de uma nova fita).
Console = all, !skipped, !saved 
Append = "/var/lib/bacula/log" = all, !skipped 
catalog = all, !skipped, !saved 
# Armazena as mensagens do catálogo, permitindo que sejam 
adquiridas e exibidas por programas específicos (ex.: interfaces 
gráficas – bweb).
} 
Schedule { 
# Começa o recurso de agendamento. Necessário que haja pelo 
menos um “schedule”, para que “jobs” sejam executados de maneira 
automática.
Name = schedule-Changer 
Run = Level=Differential Pool="Tape-Daily" Monday-Thursday 
at 18:00 
# Estas são as opções básicas do agendamento (Level e Pool 
definidas). Mas outras opções podem ser modificadas aqui 
 86
(storage, spooldata, etc.). Neste caso, será executado um “job” 
diferencial, de segunda a quinta-feira, diariamente às 18:00h.
Run = Level=Full Pool=Tape-Weekly 2nd 3rd 4th 5th Friday 
at 18:00 
# Aqui está configurado o “backup” semanal”. Todas as sextas-
feiras do mês estão contempladas, excetoa primeira, na qual 
será feito o “"backup" full” mensal (abaixo).
Run = Level=Full Pool=Tape-Monthly 1st Friday at 18:00 # 
“backup” mensal. Sempre na primeira sexta-feira de cada mês.
} 
Schedule { 
Name = schedule-File 
# Um segundo schedule – para o “backup” em disco. Entretanto, 
nada impedediria que todos os "backups" utilizassem apenas um 
agendamento.
Run = Level=Differential Pool=File-Daily Monday-Thursday at 
18:30
Run = Level=Full Pool=File-Weekly 2nd 3rd 4th 5th Friday at 
18:30
Run = Level=Full Pool=File-Monthly 1st Friday at 18:30 
} 
### Fim do bacula-dir.conf ###
 87
9.3. 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 
qual (ou quais) dispositivos sejam utilizados. Um “Bacula Director” pode controlar 
vários “Storage Daemons” em máquinas diferentes.
Storage { 
Name = 
pelourinho-sd 
# Batizamos este “storage daemon” com um nome arbitrário mas que 
seja significativo, principalmente se for utilizar mais de um, 
ligado ao mesmo “director”. 
SdAddress = 
0.0.0.0 
# Opcional. Só necessária se a máquina que hospeda o “Storage 
Bacula” possuir mais de um ip, e se deseje direcionar o tráfego 
para um deles.
SdPort = 9103 
WorkingDirectory = "/var/bacula/working" 
 88
PidDirectory = 
"/var/run" 
Heartbeat 
Interval = 120 
MaximumConcurrentJobs = 50 
} 
Director { 
Name = soter-
dir 
Password = 
"senha storage" 
# senha que o “Director” irá utilizar para contactar os 
dispositivos ligados a este “storage daemon”.
} 
Messages { 
Name = job-
messages # Estamos apontando as mensagens deste “sd” para o 
“director”.
Director = 
acaraje-dir = all 
} 
Device { 
Name = File 
# No bacula-sd.conf, são detalhadas as configurações de cada 
dispositivo. Neste caso, trata-se de um "backup" em disco rígido 
(arquivos).
Media Type = 
File 
# Precisa ser igual ao que está no bacula-dir.conf.
 89
 Archive Device = /mnt/disk_array/disk_"backup" 
# Como se trata de "backup" em “HD”, deve apontar para a pasta 
onde serão criados os volumes.
 AutomaticMount = yes 
# Permite que o “Bacula” monte o dispositivo de maneira 
automatizada.
 AlwaysOpen = yes 
# O “Bacula” sermpre abrirá o dispositivo quando em execução.
 RemovableMedia = no 
# Informo que não se trata de mídia removível (ex.: fita 
magnética).
 RandomAccess = yes 
# Informa que o dispositivo suporta “lseek” (DVD, USB, discos 
rígidos). No caso de fitas ou “named pipes”, deve ser utilizada 
a opção “No”.
 LabelMedia = no 
# Solicito que o “Bacula” não crie volumes automaticamente.
} 
AutoChanger { 
# Configuramos aqui um robô-de-fitas. É necessário que haja uma 
configuração para o dispositivo de trocas (esta), e outras para 
os drives de fita existentes (mais abaixo).
Name = PV132T 
# Este é o nome que representa nosso robô.
Device = 
CHGDRV1, CHGDRV2
# Estes são os nomes que atribuímos aos dois drives de fita que 
são alimentados pelo robô. A ordem deles, implica na prioridade 
que o “Bacula” seguirá para usá-los.
Changer Device 
= /dev/changer 
# Dispositivo do robô.
 90
Changer 
Command = "sh -c '/etc/bacula/mtx-changer %c %o %S %a %d'" 
# Padrão – comando usado pelo “Bacula” para manipulação de 
fitas.
} 
Device { 
 Name = CHGDRV1 
# Primeiro drive de fita do robô.
 Drive Index = 0
# Índice do drive de fita. Começa em zero e cada drive constante 
do robô deverá possuir um número único, sem intervalos. 
 Media Type = LTO3 
 Archive Device = /dev/nst1
# Dispositivo do drive.
 Autochanger = yes 
# Indica que é alimentado por um robô.
 LabelMedia = no; 
 AutomaticMount = yes; 
 AlwaysOpen = yes; 
 Maximum Job Spool Size = 10G 
# Volume máximo de “spool” para cada “job” executado neste 
dispositivo.
 Maximum Spool Size = 35G 
# Volume global de “spool” para este dispositivo, somados todos 
os “jobs”.
 Spool Directory = /mnt/spool 
# Diretório de “spool”
} 
Device { 
Name = CHGDRV2 
# Segundo drive do robô.
 91
Drive Index = 1
Media Type = LTO3 
Archive Device = /dev/nst2
Autochanger = yes 
LabelMedia = no; 
AutomaticMount = yes; 
AlwaysOpen = yes; 
Maximum Job Spool Size = 10G 
Maximum Spool Size = 35G 
Spool Directory = /mnt/spool 
} 
Device { 
Name = LTO2 
# Temos um drive avulso de fita-magnética. No bacula-sd original 
do “Bacula”, existem diversos modelos comentados de configuração 
de dispositivos (DVD, etc.).
Media Type = LTO3 
Archive Device = /dev/nst0 
AutomaticMount = yes; 
AlwaysOpen = yes; 
RemovableMedia = yes; 
RandomAccess = no; 
Maximum Job Spool Size = 15G 
Maximum Spool Size = 25G 
Spool Directory = /mnt/spool 
} 
### Fim do bacula-sd.conf ###
 92
9.4. bacula-fd.conf
O bacula-fd (ou “Bacula File Daemon”) é o “vampiro” do sistema de "backup". 
Trata-se do responsável em “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”.
FileDaemon { 
Name = cliente1-fd 
# deve ser exatamente o mesmo nome fornecido no recurso 
“Clients”, do bacula-dir.conf.
FdPort = 9102 
FdAddress = 0.0.0.0 
 93
# Opcional. Só necessária, se o cliente “Bacula” possuir mais de 
um ip e se deseje direcionar o tráfego para um deles.
WorkingDirectory = "/var/bacula/working" 
PidDirectory = "/var/run" 
MaximumConcurrentJobs = 15 
SDConnectTimeout = 30 Minutes 
HeartbeatInterval = 60 Seconds 
} 
Director { 
Name = acaraje-dir 
Password = "senha_cliente1" 
} 
Messages { 
Name = job-messages
Director = acaraje-dir = all 
}
9.5. bconsole.conf
O último de nossos módulos do “Bacula” é o bconsole. Trata-se da ferramenta 
 94
que abre as portas para acesso e administração do sistema de “backups”.
Para os administradores e operadores, interessante que tenham o “bconsole” 
instalado em seus equipamentos, pois trata-se de um acesso mais seguro que o “ssh”, 
na medida que só permite o acesso, apenas, ao diretor “Bacula” em si.
Aqui apresentamos a forma mais simples de configuração do bconsole.conf. 
Entretanto, 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.). A configuração das interfaces gráficas como o wxconsole e o bat (bacula-
console-qt), são bem semelhantes à do bconsole:
Director { 
Name = 
acaraje-dir 
Address = 
0.0.0.0 
# Endereço do director.
DirPort = 9101 
Password = 
"senha_console" 
# A primeira senha configurada no bacula-dir.conf.
}
9.6. 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 da seguinte maneira 
(exemplo):
 @/etc/bacula/bacula-dir-filesets.conf
 @/etc/bacula/bacula-dir-jobs.conf
 95
 @/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
9.7. Configurando: 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” de dados. Em outras palavras: você não programou o “Bacula” para 
automaticamente reciclar os volumes (por exemplo, após determinado período de 
tempo).
 Por isso, necessário adotar uma das estratégias de reciclagem abaixo:
1. 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 houverem 
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.
 96
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.
2. Reciclagem por Tempos de Retenção
Através da opção abaixo, é possível estabelecer um tempo de retenção para os 
volumes de determinado grupo (pool):
bacula-dir.conf, recurso “Pool” (exemplo):
VolumeRetention = 6 Days 
Ocorre que, para que este tempo de retenção comece a ser contabilizado, 
necessário encerrar o volume para gravação (lembra-se que o comportamento 
natural dele é de gravação contínua, enquanto não estiver cheio?).
Desta maneira, as opções abaixo podem ser utilizadas (também no bacula-
dir.conf, recurso “Pool”):
Use Volume Once = yes 
Com esta opção habilitada (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, 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".
Maximum Volume Jobs = nnnn 
Quando atingido o numero máximo de “jobs” do volume, o mesmo é 
 97
encerrado.
Maximum Volume Bytes = mmm 
Número máximo de “bytes por volume”. Quando atingido, de igual sorte, o 
volume se encerra. 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 HD 
inteiro (o mínimo recomendado são 4 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 o 
status append para o full, passanto a correr o Volume Retention.
Como exemplo, suponhamos que deseja-se obter uma retenção de 7 dias 
(volume gravado numa segunda-feira seja sobrescrito na próxima segunda, 
considerando a realização de "backup" diários). Desta forma, poderíamos ter:
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.
9.8. Configurando: Exemplo de “GFS” no “Bacula”
A implementação da estratégia GFS clássica no “Bacula” se dá através de 
duas configurações:
 98
3. Ao menos 03 (três) “pools” distintas (no bacula-
dir.conf).
“Pools” diaria, 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” diários).
Variações:
a) Quem desejar GARANTIR que o “Bacula” sempre utilize a mesma fita para 
determinado dia do mês (ex.: VOL1 sempre ser gravado às segundas-feiras), deve 
criar “pools” específicas para cada dia da semana (ex.: diario_seg, diário_ter, etc.), e 
assim sucessívamente. Observer que, isso só é útil se estiver trabalhando com um 
drive de fitas manual e o operador não tiver acesso á console do “Bacula”, para saber 
qual fita deve inserir.
b) Você pode desejar 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 (incialmente a “default”), e alterar seu nome. Não esqueça de configurá-la 
(tempo de retenção, tempo de uso do volume, reciclagem – “yes/no”, etc.) —> tudo 
isso lá no bacula-dir.conf.
4. 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”.
Schedule {
Name = agenda_gfs
Run = Level=Differential Pool=Diaria Monday-Thursday at 19:00
Run = Level=Full Pool=Semanal 2nd 3rd 4th 5th 
 99
Friday at 19:00
Run = Level=Full Pool=Mensal 1st Friday at 19:00
}
No exemplo, teremos “backups” diários de “segunda às quinta-feiras“, 
semanais nas “segundas, terças, quartas e quintas sextas-feiras dos mês“, e mensais 
na “primeira sexta-feira do mês“.
9.9. Configurando: Retenções do Bacula
Trata-se de um conceito muito importante para quem precisa trabalhar com 
“backups”. Ainda, 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 da console. Em linhas gerais: a 
retenção é “o 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 do 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 foi previamente configurada um dos limitadores “limitação” em sua 
 100
gravação.
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”
Vamos explicar essas duas opções que aparecem no Recurso “Client” do 
bacula-dir.conf:
 Client {
 Name = bruxaria-fd
 Password = "senhadabruxaria"
 Address= x.x.x.x
 FDPort = 9102
 Catalog = MyCatalog
 AutoPrune = yes
 File Retention = 30 days
 Job Retention = 6 months
 }
As duas retenções em negrito servem apaenas para preserva 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“.
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 de terminado “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
 101
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.
Conclusão
Cuidado com essas duas opções. Se vc tem um bom espaço em disco para o 
seu banco de dados “Bacula” deve 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.
9.10. Configurando: Novos Clientes Bacula
a) bacula-dir.conf:
1. Criar um novo job para o cliente a ser criado.
2. Criar um novo recurso ”Client”. A senha (password) será a mesma que 
consta do 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 utilizada / (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”.
b) bacula-fd.conf:
1. Colocar o nome do “director” (você pode também adicionar um novo 
recurso Director {..} para permitir o acesso de dois ou mais 
“directors”).
 102
2. Modificar a senha que o “director” irá utilizar para se conectar ao cliente. 
3. Reiniciar o “daemon” ou serviço (bacula-fd). 
Obs.1: no Windows, acessar o Gerenciador de Serviços (services.msc) para reiniciar 
os serviços do “Bacula”. 
Obs.2: caso o serviço “Bacula” no Windows termine em erro, execute o comando 
correspondente (botão direito no serviço, Propriedades, neste caso retirando o trecho 
“/services”), na linha de comando (CMD), para visualizar a mensagem de erro
9.11. Configurando: Compressão dos "backups"
compression=GZIP
Insira esta linha em uma das “options” do “FileSet” (bacula-dir.conf) no qual 
deseje comprimir os dados do “backup”.
Utilize compressão apenas para "backup" em disco, pois a maioria dos drives 
de fita modernos fazem compressão via “hardware”.
Você pode estabelecer diferentes níveis de compressão (exemplo: GZIP6 = 
level 6), com níveis variando de 1 a 9, sendo que 1, consiste na menor compressão e 
consequente menor consumo de recursos de processamento.
Níveis maiores que 6, geralmente consomem muitos recursos (e tempo), mas 
trazem pouca economia de espaço.
Para cada um dos “storages” utilizados, você pode permitir ou não a 
compressão, através da opção “AllowCompression” (recurso storage, dentro do 
bacula-dir.conf).
9.12. Configurando: Migração e Cópia de Volumes
O termo migração, contexto do Bacula, significa mover os dados de um volume 
para o outro. Trata-se de um job específico, que inclusive apaga (purge) as 
 103
informações do volume originário.
O processo de Cópia é essencialmente idêntico à migração, exceto que o 
volume original permanece inalterado. Cria duas cópias idênticas de um "backup".
Entretanto, a restauração da cópia só será possível assim que o volume 
original for purgado ou deletado do catálogo.
Ambos não requerem a presença (conexão) do “file daemon” correspondente 
aos dados.
A seleção do “job” a ser migrado pode se passar em:
* um job apenas
* um Volume
* um “Client”
* uma expressão regular
* quando o “job” esteve em um volume
* ocupação de uma pool
* tamanho do volume
Para executar um “job” de migração, deve definir um recurso “job”, bem 
similar a um de "backup", mas o tipo (Type =) será Migrate, ao invés de "backup". 
A “pool” especificada deve conter os “jobs” que deseja migrar, de maneira geral. A 
pool onde o novo volume será gerado, deverá ser informado com a opção: “Next Pool 
=”.
Diretivas de Migração e Cópia:
As diretivas seguintes se aplicam no recurso Job:
Pool =
É importante pois define que pool será examinada para localizar os jobs (ids) a 
serem migrados.
 104
Type = Migrate
Novo tipo que define um job de migração.
Type = Copy
Novo tipo que define um job de cópia.
Selection Type =
Determina como será a seleção dos JobIds para migrar. Os valores possíveis 
são:
SmallestVolume
Seleciona o menor volume a ser migrado.
OldestVolume
Seleciona o volume mais antigo.
Client
Seleciona todos os clientes que foram "backupeados” na pool 
especificada, então aplica a “Selection Pattern” (abaixo) como uma expressão regular 
para a lista de nomes de clientes.
Volume
Primeiro verifica os volumes da pool. Depois, usa o “Selection Pattern” 
como uma expressão regular para encontrar os volumes.
Job
Verifica todos os jobs da pool, e aplica a “Selection Pattern” nos jobs.
SQLQuery
Utiliza uma SQLQuery para obter os jobids a serem migrados.
PoolOccupancy
 105
Computará o tamanho de todos os volumes combinados na pool. Se 
exceder o Migration High Bytes definido na Pool, o job de migração irá 
migrar todos os JobIds começando pelo volume mais velho – até a pool 
voltar ao limite definido.
PoolUncopiedJobs
Seleciona os jobs que nunca foram copiados.
Selection Pattern =
Para o OldestVolume e SmallestVolume,esta opção é ignorada.
Para a opção Client, Volume e Job, esta “pattern” deve ser uma expressão 
regular válida para filtrar os nomes encontrados na pool.
Diretivas para a pool de onde os volumes serão migrados:
Migration Time =
Define um tempo após o qual os jobs realizados serão migrados.
Migration High Bytes =
Numero de bytes após o qual os jobs excedentes serão migrados..
Migration Low Bytes =
 Mínimo de bytes para que a migração ocorra.
Next Pool (indispensável!)=
Específica para qual pool os jobs serão migrados.
Storage =
Especifica um storage específico para a migração (terá prioridade sobre todas 
as outras especificações de storage. Ex.: “schedule”, jobs, etc.)
Considerações importantes:
 106
* Cada pool de migração deve ter volumes de apenas um “Media Type”.
* Jobs em “append” nunca serão migrados.
Exemplo de “Jobs” de migração: 
 # Default pool definition
 Pool {
 Name = Default
 Pool Type = "backup"
 AutoPrune = yes
 Recycle = yes
 Next Pool = Tape # fundamental para a migração – é o destino 
dos dados
 Storage = File
 LabelFormat = “File”
 }
 # Tape pool definition
 Pool {
 Name = Tape
 Pool Type = "backup"
 AutoPrune = yes
 Recycle = yes
 Storage = DLTDrive
 }
Nestes exemplos, foram incluídos apenas informações essenciais. E.: FileSet, 
“Catalog”, “Client”, “Schedule” – foram omitidos.
Se adicionarmos o seguinte no bacula-dir.conf:
 Job {
 107
 Name = “migrate-volume”
 Type = Migrate
 Level = Full
 Client =rufus-fd
 FileSet = “Full Set”
 Messages = Standard
 Pool = Default
 Maximum Concurrent Jobs = 4
 Selection Type = Volume
 Selection Pattern = “File”
 }
 …E executarmos o “job migrate-volume”, todos os volumes na “Pool 
Default” serão migrados para o storage DLTDrive.
9.13. Configurando: Label Automático de Volumes 
no Bacula
O label automático de fitas pode ser feito tanto para HD quanto para fitas.
Para robôs, o label automático não funciona, pois o Bacula não acessa “slots” 
desconhecidos. Neste caso, deve ser usado o comando “label barcodes”, para 
etiquetar várias novas fitas.
O label automático é ativado inserindo opções no recurso pool (bacula-
dir.conf) e no recurso “device” (bacula-sd.conf), como demonstrado abaixo. No 
recurso pool, deve ser provido um formato de label utilizado para criar novos 
volumes, no qual o “Bacula” irá adicionar um dígito numérico. Ele começa em 0001, 
 108
sendo incrementado para cada volume. Exemplo:
 Pool {
 Name = File
 Pool Type = "backup"
 Volume Use Duration = 23h
 LabelFormat = “Vol”
 }
Bacula irá criar Vol0001, Vol0002, sempre que novos volumes forem 
necesários. Labels mais complexos podem ser criados através de variáveis.
A segunda opção necessária, simplesmente permite que o Storage etiquete os 
volumes. Adicione a opção LabelMedia = yes para o Device no bacula-sd.conf:
 Device {
 Name = File
 Media Type = File
 Archive Device = /home/bacula/"backups"
 Random Access = Yes;
 AutomaticMount = yes;
 RemovableMedia = no;
 AlwaysOpen = no;
 LabelMedia = yes
 }
 Variáveis do Bacula são suportadas na elaboração do nome automático do 
 109
volume6.
9.14. Configurando: Desduplicação de Arquivos
Um “job” de base é com um “job full” normal, exceto pelo fato de que é 
desejável salvar apenas arquivos que dificilmente serão mudados no futuro (ex.: um 
servidor recém instalado). Depois de um “job” de base realizado, os próximos 
trabalhos de “backup” normais deverão especificar o “job” de base como parâmetro. 
Desta forma, os arquivos que já foram “backupeados” pelo base, não serão 
novamente gravados nos novos trabalhos. Para o “restore”, os “jobs” de base serão 
automaticamente requisitados quando necessários.
Esta funcionalidade traz grande economia de tempo e dinheiro. Basicamente, 
imagine que existem 100 servidores Windows ou Linux de versões semelhantes, 
contendo apenas arquivos de usuários e dos sistemas operacionais. Os arquivos do 
sistema operacional serão “backupeados” uma única vez, ao invés de 100 (uma para 
cada servidor). 
Os “jobs” base, devem ser especificados no recurso “Job” do bacula-dir.conf. 
É recomendável que estes “jobs” sejam submetidos para uma “pool” específica:
Job {
 Name = backupLinux
 Level= Base
 Pool = “base”
 ...
}
Uma nova diretiva de “job” (Base=Jobx, Joby...) permite especificar a lista de 
6 http://www.bacula.org/en/dev-manual/Variable_Expansion.html
 110
“jobs” base que serão utilizados em conjunto com o “job” de “backup” usual:
Job {
 Name = backupZog4
 Base = backupZog4, backupLinux
 Accurate = yes
 ...
}
Neste exemplo, backupZog4 usará a versão mais recente de todos os arquivos 
gravados em backupZog4 e backupLinux jobs. “Jobs” de base precisam ter sido 
executados com a opção “level=Base”.
Adições no FileSet:
FileSet {
 Name = Full
 Include = {
 Options {
 BaseJob = pmugcs5
 Accurate = mcs5
 Verify = pin5
 }
 File = /
 }
}
 111
9.15. Configurando: Criptografia das 
Comunicações do Bacula (TLS)
Bacula TLS (Transport Layer Security) é um modo de criptografia nativo para 
profer transporte seguro das informações, similar ao stunnel ou ssh. Nesta opção, os 
dados gravados no Storage Daemon não são criptgrafados mas, sim, a comunicação.
Recursos:
* Negociação Client/Server TLS
* Conexões TLSv1 com validação via certificado para Servidor e Cliente
A configuração incial do bacula deverá conter as opções de uso do OpenSSL, 
se indicado pelo ./configure, atrav[es da opção: –with-openssl
Ainda, opções adicionais precisam ser adicionadas a todos os daemons 
(Director, File daemon, and Storage daemon) como nas consoles de administração. 
São elas:
TLS Enable =
Permite o suporte a TLS (yes/no)
TLS Require =
Requer que o Bacula utilize sempre conexões TLS.
TLS Certificate =
Caminho completo do arquivo do certificado TLS PEM. Pode ser utilizado 
tanto o certificado de um cliente quanto de um servidor. PEM se refere a como os 
certificados são cifrados.
TLS Key =
Caminho completo da chave prifada de um PEM TLS cifrado.
 112
TLS Verify Peer =
Verifica a configuração de um certificado dos pares.
TLS Allowed CN =
Atributo “Common name” dos certificados dos pares válidos.
TLS CA Certificate File =
Caminho para um certificado CA PEM TLS. Múltiplos certificados são 
permitidos neste arquivo. Na opção CA Certificate File ou a TLS CA Certificate Dir 
são necessárias no contexto do servidor se o TLS Verify Peer (acima) tiver sido 
especificada. No contexto do cliente é sempre necessário.
TLS CA Certificate Dir =
Parecido com o anterior.
TLS DH File =
Caminho para o arquivo de parâmetros PEM Diffie-Hellman. Se especificado, 
será utilizada para o chaveamento, adicionando um maior nível de segurança, pois as 
chaves utilizadas para criptografia/decriptografia serão computadas em ambos. Essa 
opção só é válida no bacula-dir.conf.
Para gerar o arquivo de parâmetro, você pode utilizar o openssl: 
 openssl dhparam -out dh1024.pem -5 1024
 
Criando um certificado auto-assinado
Você pode criar um certificado auto-assinado para o uso do Bacula TLS, mas 
que não permitirá a validação do certificado. O arquivo .pem conterá ambos o 
certificado e a chave válida por 10 anos, pode ser feito através do seguinte comando:
 113
 openssl req -new -x509 -nodes -out bacula.pem -keyout bacula.pem -days 
3650
Neste caso, o certificado só irá funcionar se o daemon a ser conectado 
confiar explicitamente no certificado usado.
Podem ser utilizados, ainda, um certificado de uma autoridade certificadora 
(CA ou “Certificate Authority signed certificate”)
Ainda, vocë pode utilizar o programa gráfico TinyCA, permitindo que você 
mesmo abra uma autoridade certificadora —> http://tinyca.sm-zone.net/.
Exemplos de Configuração do TLS:
O exmplo abaixo mostra a conexão entre Director e Storage. A técnica é a 
mesma entre o director e cliente, assim como bconsole e director. 
bacula-dir.conf
 Director { # define myself
 Name = "backup"1-dir
 …
 TLS Enable = yes
 TLS Require = yes
 TLS Verify Peer = yes
 TLS Allowed CN = “bacula@"backup"1.example.com”
 TLS Allowed CN = “administrator@example.com”
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 # This is a server certificate, used for incoming
 # console connections.
 114
 TLS Certificate = /usr/local/etc/ssl/"backup"1/cert.pem
 TLS Key = /usr/local/etc/ssl/"backup"1/key.pem
 }
 Storage {
 Name = File
 Address = "backup"1.example.com
 …
 TLS Require = yes
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 # This is a client certificate, used by the director to
 # connect to the storage daemon
 TLS Certificate = /usr/local/etc/ssl/bacula@"backup"1/cert.pem
 TLS Key = /usr/local/etc/ssl/bacula@"backup"1/key.pem
 }
 Client {
 Name = "backup"1-fd
 Address = server1.example.com…
 TLS Enable = yes
 115
 TLS Require = yes
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 }
bacula-fd.conf
 Director {
 Name = "backup"1-dir
 …
 TLS Enable = yes
 TLS Require = yes
 TLS Verify Peer = yes
 # Allow only the Director to connect
 TLS Allowed CN = “bacula@"backup"1.example.com”
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 # This is a server certificate. It is used by connecting
 # directors to verify the authenticity of this file daemon
 TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
 TLS Key = /usr/local/etc/ssl/server1/key.pem
 }
 FileDaemon {
 Name = "backup"1-fd
 116
 …
 # you need these TLS entries so the SD and FD can
 # communicate
 TLS Enable = yes
 TLS Require = yes
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
 TLS Key = /usr/local/etc/ssl/server1/key.pem
 }
bacula-sd.conf
 Storage { # definition of myself
 Name = "backup"1-sd
 …
 # These TLS configuration options are used for incoming
 # file daemon connections. Director TLS settings are handled
 # below.
 TLS Enable = yes
 TLS Require = yes
 # Peer certificate is not required/requested — peer validity
 117
 # is verified by the storage connection cookie provided to the
 # File Daemon by the director.
 TLS Verify Peer = no
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 # This is a server certificate. It is used by connecting
 # file daemons to verify the authenticity of this storage daemon
 TLS Certificate = /usr/local/etc/ssl/"backup"1/cert.pem
 TLS Key = /usr/local/etc/ssl/"backup"1/key.pem
 }
 #
 # List Directors who are permitted to contact Storage daemon
 #
 Director {
 Name = "backup"1-dir
 …
 TLS Enable = yes
 TLS Require = yes
 # Require the connecting director to provide a certificate
 # with the matching CN.
 TLS Verify Peer = yes
 TLS Allowed CN = “bacula@"backup"1.example.com”
 118
 TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
 # This is a server certificate. It is used by the connecting
 # director to verify the authenticity of this storage daemon
 TLS Certificate = /usr/local/etc/ssl/"backup"1/cert.pem
 TLS Key = /usr/local/etc/ssl/"backup"1/key.pem
 }
9.16. Configurando: Criptografia dos dados 
Gravados no Storage
O Bacula permite criptografia na gravação dos dados no storage, a partir da 
sa[ida do cliente (file daemon). Na restauração, assinaturas de arquivos são validadas 
e qualquer inconformidade [e reportada. Em em nenhum momento, o Director ou 
Storage Daemon tem acesso aos dados criptografados.
* Esta implementação não criptografa meta-informações do arquivo.
Encriptação e validação são implementadas utilizados chaves privadas RSA, 
casadas com certificados públicos x509 auto assinados. Este esquema [e conhecido 
como PKI ou infra-estrutura de chave pública.
Cada “file-daemon” deverá ter sua própria chave pública/privada. Em adição 
a esse par, qualquer número de chaves mestres pode ser especificada — essas chaves 
podem ser utilizadas para descriptografar qualquer "backup" em caso de perda da 
chave do File Daemon. Apenas o certificado da chave pública será visível para o “file 
daemon” A chave mestre privada nunca deve ser armazenada no cliente.
As chaves mestre devem ser guardadas em segurança, preferencialmente num 
confre corta-fogo. Também não deve ser guardada na mesma máquina do Storage 
Daemon ou Director, se houver preocupação com atividade maliciosa nestas 
máquinas.
 119
Menos críticas que as chaves mestras, as chaves do File Daemon Keys também 
são candidatas a serem "backupeadas” de maneira off-site.
NOTA!!! Se as chaves de criptografia forem perdidas, os "backups" 
serão irrecuperáveis.
O algorítimo básico utilizado para cada sessão de "backup", é:
1. O file daemon gera uma chave de sessão.
2. The FD criptografa utilizando PKE para todos os recipientes (o file 
daemon e qualquer chave mestre).
3. O FD usa a chave de sessão para fazer a criptografia simétrica dos 
dados.
Implementando o suporte a criptografia
 ./configure –with-openssl …
Detalhes Técnicos da Criptografia
Esta implementaçào utiliza AES-CBC de 128 bits, com sessão simétrica 
criptografada RSA. A chave RSA é suprida pelo usuário. Se vocë estiver executando o 
OpenSSL 0.9.8r, a assinatura do arquivo utiliza SHA-256 — do contráario, SHA-1 é 
utilizado.
A informação escrita no volume suporta criptografia simétrica e assimétrica.
Criptografia simétrica:
- 128, 192, and 256-bit AES-CBC
- Blowfish-CBC
Criptografia Assimétrica (usada para criptografar as chafes de sessão):
- RSA
Algorítimos:
 120
- MD5
- SHA1
- SHA256
- SHA512
Descriptografando com a chave mestra:
* Primeiro, a chave mestra privada e a pública devem ser concatenatas num 
s[o arquivo. Ex.: cat master.key master.cert >master.keypair
* Configure a opção PKI Keypair no bacula-dir.conf:
PKI Keypair = master.keypair
* Comece o restore. A chave mestra será utilizada para descriptografar os 
dados.
Geração das chaves Públicas/Privadas:
Crie um par de chaves mestras com:
 openssl genrsa -out master.key 2048
 openssl req -new -key master.key -x509 -out master.cert
Crie um par de chaves para cada um dos File Daemons:
 openssl genrsa -out fd-example.key 2048
 openssl req -new -key fd-example.key -x509 -out fd-example.cert
 cat fd-example.key fd-example.cert >fd-example.pem
Neste caso, tipicamente a extenção .cert se refere a um certificado de 
codificação X509 que contém apenas uma chave pública.
Exemplo de Configuração:
 121
bacula-fd.conf
 FileDaemon {
 Name = example-fd
 FDport = 9102 # where we listen for the director
 WorkingDirectory = /var/bacula/working
 Pid Directory = /var/run
 Maximum Concurrent Jobs = 20
 PKI Signatures = Yes # Enable Data Signing
 PKI Encryption = Yes # Enable Data Encryption
 PKI Keypair = “/etc/bacula/fd-example.pem” # Public and Private Keys
 PKI Master Key = “/etc/bacula/master.cert” # ONLY the Public Key
 }
9.17. A função da “pool scratch”
A “pool scrach” – que vem cofigurada no arquivo padrão de configuração do 
“director” (bacula-dir.conf) permite que os novos volumes criados, que a ela estejam 
associados, sejam automaticamente migrados pelo “Bacula” para outras “pools” 
criadas, na medida que seja necessário.
Definindo a ”RecyclePool=Scratch” (ou qualquer outro nome) nas respectivas 
configurações, os volumes voltarão para a referida “pool” quando reciclados.
 122
Capítulo 10 
Primeiros Passos com Fitas 
Magnéticas
Pode-se dizer que as fitas magnéticas são as mídias mais utilizadas para 
realização de “backup” no mundo. Possuem um custo por “gigabyte” razoável, boa 
velocidade de gravação, capacidade de várias regravações, grande capacidade de 
armazenamento, além de durabilidade.
Já os discos rígidos, hoje em dia, estão com um custo cada vez menor - 
mostrando que o fim das fitas magnéticas pode estar próximo. Os “HD” permitem 
que sejam utilizados como "fitas virtuais" (tape virtualization), ou seja, seccionando-
 123
os em volumes, o que permite a aplicação de esquemas de "backup" como o GFS e 
eliminando qualquer necessidade de troca de mídias (seja manual ou automática, 
como ocorre com as fitas). Em termos de performance e capacidade, os “HD” 
também demonstram ser uma solução muito viável, apesar de que pode nãopossuírem a mesma confiabilidade das fitas. Particularmente - adoro trabalhar com 
“backups” em disco-rígido, pela agilidade na manipulação de volumes.
Entretanto, no cotidiano, temos de trabalhar com qualquer ambiente de 
hardware. Justamente por isso, seguimos com este capítulo dedicado à manipulação 
de “drives” fitas magnética e robôs-de-fitas.
10.1. Os dispositivos de Fita-Magnética
No Linux, a maioria dos dispositvos (drives e robôs-de-fita) são reconhecidos 
pelos drivers genéricos (nativamente instalados no SO).
Drives de fita: podem ser /dev/nst* (não-rebobinável) ou /dev/st* 
(rebobinável).
Robôs-de-fitas (autochangers, autoloaders, tape libraries, etc.): devem 
ser: /dev/sg*, ou /dev/changer.
Obs.: Caso seu robô esteja sendo detectado como /dev/sg*, o número 
substituído pelo * pode variar a cada “reboot” do servidor. Por isso, é aconselhável 
criar uma regra no "udev", estabelecendo um "alias" para seu dispositivo, que pode 
ser /dev/changer.
No Windows, utilize o aplicativo “list devices” que vem instalado junto ao 
“Bacula” (Menu Inciar, Todos os Programas, Bacula...), para saber o nome de seus 
dispositivos.
 124
10.2. Operações com Fitas.
O “mt”.
O mt é um aplicativo para Linux, que o Bacula leva consigo para o Windows 
quando instalado (c:\Arquivos de Programas\Bacula\bin), e permite que sejam feitas 
diversas operações com fitas magnéticas (rebobinar, posicionar em detrminado bloco, 
apagar, etc.).
Entretanto, os drives de fita moderno fazem com que algumas dessas 
operações não tenham efeito prático, na medida que sempre rebobinam as fitas antes 
de qualquer acesso.
Portanto vamos, apenas, dar três exemplos úteis de uso do mt (supondo que 
seu dispositivo seja /dev/nst0):
mt -f /dev/nst0 rewind -> para rebobinar a fita
mt -f /dev/nst0 eof -> para apagar rapidamente / reciclar a fita
mt -f /dev/nst0 erase -> para apagar literalmente a fita 
(processo lento).
São comandos utilizados muito raramente, apenas quando se quer re-utilizar 
uma fita já gravada por outros programas de "backup".
Para reciclar fitas gravadas pelo “Bacula”, pasta "purgar" o volume (comando 
purge) ou, se quiser mudar o nome do volume, dar um comando "relabel" (desde que 
o “label” atual esteja no catálogo).
10.3. Manipulando Robôs-de-fitas:
Assim que configurado, a primeira pergunta para quem trabalha com o robô 
 125
de fitas é: “como descubro quantas fitas tem no meu robo?”
No bconsole – Update > 3: Slots from autochanger:
*update
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Update choice:
 1: Volume parameters
 2: Pool from resource
 3: Slots from autochanger
 4: Long term statistics
Choose catalog item to update (1-4): 3
The defined Storage resources are:
 1: Fita
 2: File
Select Storage resource (1-2):
Escolha então o dispositivo que corresponde ao seu robô-de-fitas. O “Bacula” 
irá te perguntar, então, qual o “Drive” do robô que será utilizado para esta consulta 
(pode utilizar o padrão [0]). Então aparecerá a lista de todos os volumes inseridos:
 Enter autochanger drive[0]: 
Connecting to Storage daemon ultrium-lto2-Changer at 
207.230.229.3:9103 ... 
3306 Issuing autochanger "slots" command. 
Device "PV132T" has 24 slots. 
Connecting to Storage daemon ultrium-lto2-Changer at 
207.230.229.3:9103 ... 
3306 Issuing autochanger "list" command. 
Catalog record for Volume "BACU10" updated to reference slot 1.
 126
Catalog record for Volume "BACU13" updated to reference slot 2.
Catalog record for Volume "BACU22" updated to reference slot 3.
Catalog record for Volume "BACU17" updated to reference slot 4.
Catalog record for Volume "BACU18" updated to reference slot 5.
Catalog record for Volume "BACU16" updated to reference slot 6.
Catalog record for Volume "BACU06" updated to reference slot 7.
Catalog record for Volume "BACU03" updated to reference slot 8.
Catalog record for Volume "BACU20" updated to reference slot 9.
Catalog record for Volume "BACU25" updated to reference slot 10.
Catalog record for Volume "BACU05" updated to reference slot 11.
Catalog record for Volume "BACU01" updated to reference slot 12.
Catalog record for Volume "BACU07" updated to reference slot 13.
Catalog record for Volume "BACU09" updated to reference slot 14.
Catalog record for Volume "BACU00" updated to reference slot 15.
Catalog record for Volume "BACU02" updated to reference slot 16.
Catalog record for Volume "BACU21" updated to reference slot 17.
Catalog record for Volume "BACU19" updated to reference slot 18.
Catalog record for Volume "BACU15" updated to reference slot 19.
Catalog record for Volume "BACU08" updated to reference slot 20.
Catalog record for Volume "BACU11" updated to reference slot 21.
Catalog record for Volume "BACU14" updated to reference slot 22.
Catalog record for Volume "BACU12" updated to reference slot 23.
A próxima pergunta, deverá ser: “como consigo manipular essas fitas?”
Da mesma maneira que os drives de fitas manuais, as fitas em um robô 
também precisam ser montadas para que o Bacula possa utilizar. Entretanto, neste 
caso, além de montar a fita, o comando mount (bconsole) também fará com que o 
robô retire uma das fitas das gavetas (slots) e insira em um dos drives. Exemplo:
 127
*mount
Automatically selected Catalog: catalog
Using Catalog "catalog"
The defined Storage resources are:
 1: ultrium-lto2-Tape
 2: sata-changer
 3: ultrium-lto2-Changer 
Select Storage resource (1-12): 3
Enter autochanger drive[0]: 0
Enter autochanger slot: 1
3307 Issuing autochanger "unload slot 15, drive 0" command.
3304 Issuing autochanger "load slot 1, drive 0" command.
3305 Autochanger "load slot 1, drive 0", status is OK.
3001 Mounted Volume: BACU10
3001 Device "CHGDRV1" (/dev/nst1) is already mounted with Volume 
"BACU10"
No exemplo, escolhemos o storage 3 (o robô), o primeiro Drive (0) e a gaveta 1 
(segundo a listagem de volumes emitida previamente, se trata do Volume "BACU10"). 
A saída produzida, mostra que o “Bacula” retirou a fita do slot 15 que já estava 
inserida no mencionado drive 0 ("unload slot 15, drive 0"), e depois carregou a 
fita, como ordenamos (load slot 1, drive 0"). Então, nos confirma que a fita está 
carregada (Device "CHGDRV1" (/dev/nst1) is already mounted with Volume 
"BACU10").
Para saber quais fitas estão carregadas nos drives, utilize o comando 
Status > 2: Storage, no bconsole:
Device "CHGDRV1" (/dev/nst1) is mounted with:
 128
 Volume: BACU10
 Pool: Tape-Daily
 Media type: LTO3
 Slot 1 is loaded in drive 0.
 Total Bytes Read=64,512 Blocks Read=1 Bytes/block=64,512
 Positioned at File=0 Block=0
Device "CHGDRV2" (/dev/nst2) is not open.
 Drive 1 is not loaded.
Além de uma série de informações, ele mostra o status dos dois drives de fitas 
que pertencem ao mencionado robô (CHGDRV1 e CHGDRV2).
No primeiro drive, tempos o volume BACU10 inserido.
No segundo (CHGDRV2), o Bacula informa que não há fita carregada (is not 
loaded).
Outra pergunta possível, seria: “Como sei que estas fitas estão limpas?”
A única maneira de saber se a fita está limpa, consiste na verificação de seu 
label (no caso de robôs, Update > 3: Slots from autochanger). 
Se não houver label, é bem provável que esta seja uma fita nova (ou, em 
alguns casos extremos, que tenha sido gravada em outro sistema operacional / 
software). Em qualquer uma das hipóteses, poderá tentar proceder com o 
etiquetamento (comando label, bconsole) para que o Bacula tente utilizá-la. Se 
houver sido gravada anteriormente, o comando label falhará.
Casohaja algum label, o Bacula irá confrontar com seu catálogo para verificar 
se reconhece o volume, qundo do comando Update > 3: Slots from autochanger. 
Se o Bacula não reconhecer, é provável que esta fita:
1. Tenha sido gravada por outro software.
2. Tenha sido gravada por outra instalação do Bacula.
 129
3. Tenha sido gravada pelo servidor atual do Bacula, mas que tenha, por 
algum motivo, as informações referente a ela excluídas do catálogo.
Para as hipóteses 2 e 3, o comando bscan (explicado nos próximos capítulos) 
podera ser utilizado para verificar o real conteúdo da mídia.
Durante a operação com robôs, o comportamento ideal e natural do 
Bacula, é que realize as trocas de fitas de maneira automática, sem a 
necessidade de nenhuma intervenção manual.
O mtx-changer.
Ele é o script chamado pelo Bacula, responsável por manipular robôs de fitas 
(carregar, descarregar, listar, etc.) através do Bacula, funcionando bem com a 
maioria dos dispositivos do mercado.
Este script vem instalado junto com o Bacula (director), tanto no Linux 
(/etc/bacula) quanto no Windows.
Geralmente, o "Bacula" utiliza-o de maneira automatizada - sem nenhuma 
necessidade de intervenção humana. Entretanto é bom conhecermos esta 
ferramenta, pois ela pode ser útil em casos de contingência.
Entretanto, alguns robôs precisam de configurações específicas para que 
sejam evitados erros de operação nos volumes.
Na versão 2.4*, o mtx-changer possibilita que sejam configuradas duas 
variáveis (offline_sleep e load_sleep), que deve corrigir eventuais problemas ligados 
ao uso deste script pelo "Bacula":
Descomente as duas linhas que contém (offline e sleep) dentro do 
mtx-change. As próprias instruções do arquivo ensinam a fazê-lo.
Comandos:
O mtx-changer possui a seguinte sintaxe:
 130
mtx-changer <changer_device> <command> <slot> <tapedrive_device> 
<drive_index [está em bacula-sd.conf]>
Onde "<command>" pode ser:
unload - ejeta (descarrega) a fita que pertence ao "slot" 
(gaveta) informado, para dentro do "slot".
load <slot> - carrega (insere) a fita em um “drive”, 
identificando-a a partir do "slot".
list - lista o conteúdo de todos os “slots”.
loaded - fornece o "slot" da fita que está carregada no drive - 
0 significa que o drive está vazio.
slots - fornece o número de "slots" disponíveis.
volumes - lista os "slots" e volumes disponíveis
Exemplo:
mtx-changer load /dev/nst0 1 [carrega uma fita do slot 11]
 131
10.4. Usando robôs com múltiplos drives gravando 
simultaneamente:
No bacula-dir.conf, recurso “job”:
Prefer Mounted Volumes = <yes|no>
Se a diretiva “Prefer Mounted Volumes” (Preferir Volumes Montados) estiver 
em “yes” (default yes), o Storage daemon é solicitado para escolher volumes já 
montados nos drives de fita, em detrimento a volumes que não estejam montados. 
Isso significa que os “jobs” tentarão escrever no mesmo Volume (desde que o Volume 
seja correto, ou seja, pertença à “pool” correta, para aquele “job”). Se nenhum 
Volume adequado estiver disponível, ele escolherá o primeiro drive. Observe que any 
Volume que for montado será considerado valido para os outros “jobs”. Se múltiplos 
Jobs começam ao mesmo tempo, todos eles irão preferir múltiplos volumes. Se a 
diretiva escolhida é *no*, o “Storage daemon” vai preferir um drive não utilizado. 
Escolher “no” para “Prefer Mounted Volumes” pode ser útil no uso de autochangers 
com múltiplos drives e que preferem maximizar a taxa de transferência para 
"backup", a custa de mais volumes e drives. Isso significa que o “job” irá escolher um 
drive não utilizado, em detrimento de um drive em uso7.
10.5. “Spooling” de Dados8
O “spool” de dados consiste no armazenamento destes, em um disco rígido, 
agrupamento, e posterior gravação em outro volume (no caso fitas).
Você pode utilizar o “spooling” para:
• Pode demorar muito tempo para a informação sair do cliente de “backup” 
durante um “backup” incremental ou diferencial, fazendo com que o drive de 
fita fique “parando e reiniciando” a gravação se os dados forem gravados 
diretamente nele – causando “stress” na fita. Utilizando o “spooling”, os dados 
somente serão gravados de maneira contínua.
7 Fonte: bacula.org documentation
8 Fonte: http://www.bacula.org/en/dev-manual/main/main/Data_Spooling.html
 132
• Enquanto a informação de diversos “jobs” diferentes gravados em “spool”, os 
mesmos ficam gravados de maneira mais organizada na fita, melhorando o 
tempo de restauração. Enquanto esse processo ocorre, entretanto, o “backup” 
continua em execução.
• Escrever em fita pode ser lento. Utilizando o “spool” é reduzido o tempo no 
qual o cliente de “backup” (“file daemon”) realiza operações no cliente, 
consequentemente minimizando um impacto no uso daquele servidor 
específico. Neste caso, entretanto, o tamanho disponibilizado para “spool” tem 
de ser suficiente para armazenar, mesmo que temporariamente, toda a 
mencionada informação. 
Não se justifica o uso de “spooling” para “backups” em disco, já que a 
velocidade de gravação entre eles seria a mesma. Haveria uma perda de 
performance.
As seguintes opções podem ser usadas para configurar o “data spooling”:
 Para cada “job”, dentro da configuração do “Director”, vc pode habilitar ou 
desabilitar o “spooling” (padrão = “no”): 
SpoolData = yes/no
 Para forçar todos os “jobs” de um mesmo agendamento a utilizarem o 
“spooling”. No schedule do bacula-dir.conf: 
SpoolData = yes/no
 Submetendo “jobs” manualmente, dentro do bconsole, pode usar como 
argumento para habilitar o “spooling”: 
SpoolData=yesno
 Paral imitar o tamanho máximo do arquivo de “spool” para cada “job”, no 
recurso “Job” dentro do bacula-dir.conf: 
Spool Size = [tamanho em bytes, gigabytes, etc.]
 133
 Para limitar o tamanho máximo para cada “device” (no bacula-sd.conf, recurso 
“storage”). O padrão é “ilimitado”:
Maximum Spool Size = [tamanho em bytes, gigabytes, etc.]
 
 Para limitar o tamanho máximo para cada “job”, qualquer que seja, dentro de 
um mesmo “device” (no bacula-sd.conf, recurso “storage”). O padrão é 
“ilimitado”:
Maximum Job Spool Size = [tamanho em bytes, gigabytes, etc.]
 Definir o diretório de armazenamento do “spool”. Configurado no recurso 
“storage”, do bacula-sd.conf. O padrão (em caso de omissão) é o diretório de 
trabalho do “Bacula”:
 Spool Directory = diretório
Obs: Nunca apague o diretório ou arquivos de “spool”, durante um 
“backup”.
Obs 2.: Sempre é recomendável estabelecer um tamanho máximo do 
“spool”, para que o disco não encha completamente. 
 134
Capítulo 11 
Comandos do “Bacula”
11.1. Lista Alfabética dos Comandos do 
“bconsole”:
Lista dos comandos atualmente implementados:
Add:
add [pool=<pool-name> storage=<storage> jobid=<JobId>] 
Este comando adiciona volumes para uma pool existente. Os nomes dos 
volumes serão adicionados ao catálogo. Entretanto, este comando não é muito 
utilizado, pois o comando "label" nomeia as fitas logicamente - não apenas no 
catálogo. Este comando é mais usado para colocar vários volumes numa mesma pool 
para serem "labelados" (etiquetados) nas fitas em outro horário. Pode também ser 
utilizado se você estiver "importando" a fita de outro servidor “Bacula”.
 135
Autodisplay:
autodisplay on/off 
Este comando liga/desliga o aparecimento automático das mensagens de 
"backup"/restore no console (assim que recebidas). O "default" do console é off, 
significando que você receberá apenas uma notificação de mensagens, mas terá 
digitar o comando"messages" para lê-las.
Automount:
automount on/off
Liga/desliga o montagem automática de volumes, pelo Bacula, depois de um 
comando "label". O "default" é "on". 
Cancel:
cancel [jobid=<number> job=<job-name> ujobid=<unique-jobid>] 
Cancela um job. Se você digitar apenas “cancel”, o “Bacula” perguntar qual 
job em execução deverá ser cancelado. Porém, ele aceita jobid=nnn ou job=xxx como 
argumentos, nos quais nnn é substituído pelo JobID e xxx pelo nome do job. Uma vez 
que o job é cancelado, pode demorar um tempo (geralmente até um minuto) para ele 
realmente ser cancelado e não mais aparecer no “status > director”. 
Delete:
delete [volume=<vol-name> pool=<pool-name> job jobid=<id>]
O comando "delete" é utilizado para deletar um registro de volume, pool ou 
job a partir do "catálogo", bem como informações associadas. Este comando opera 
apenas no catálogo e não tem efeito no volume escrito propriamente dito. Este 
comando pode ser perigoso, e deve ser utilizado apenas se souber o que faz. Se 
digitar apenas o comando delete, o Bacula vai te perguntar o que queres deletar. 
 136
Exemplos: 
Ex. 1: delete pool=<pool-name> ...ou
Ex. 2: delete volume=<volume-name> pool=<pool-name> ...ou
Ex. 3: delete JobId=<job-id> JobId=<job-id2> ... or
Ex. 4: delete Job JobId=n,m,o-r,t ...
O comando "delete" é utilizado para deletar um registro de volume, pool ou 
job a partir do "catálogo", bem como informações associadas. Este comando opera 
apenas no catálogo.
Disable:
disable job<job-name> 
Este comando permite que seja desativado um “job” do agendamento 
automático. O “job” precisa ter sido ativado previamente com a opção 
"enabled=yes" na seção do respectivo “job”, ou com o ativado com a o comando 
"enable", para poder desativar o job. Mas opserve que se o Bacula for reiniciado, 
irá prevalecer a opção constante do bacula-dir.conf (enabled=yes/no). Pode ser 
executado apenas o comando disable, e o console irá te perguntar qual o job 
deverá ser desativado.
Enable:
enable job<job-name>
Este comando ativa um "job" para execução agendada. Obviamente, o "job" 
precisa estar desativado. É o oposto do comando accima (disable job). Pode ser 
executado apenas o comando enable, e o console irá te perguntar qual o job deverá 
ser ativado.
 137
Estimate 
estimate 
Usando este comando, se tem uma idéia de quantos arquivos serão 
"backupeados” ou ter uma idéia dos arquivos que serão armazenados com o "fileset" 
escolhido, sem ter de fazer um "backup" real. Por "default", ele assume que se trata 
de um "backup" full. Você pode modificar especificando o "level=Incremental" ou 
"level=Differential" na linha de comando. Um nome de job precisa ser especificado 
ou será perguntado, da mesma forma um Client e FileSet (opcionalmente).
Então, ele contata o cliente e calcula a quantidade de arquivos e “bytes” que 
serão armazenados. Observe que, apenas os blocos são lidos, podendo variar com o 
tamanho do “backup” real. O formulário completo é:
Ex.: estimate job=<job-name> listing client=<client-name> 
fileset=<fileset-name> level=<level-name>
Mas apenas a especificação do “job” é suficiente.
Exemplo:
@output /tmp/listing
estimate job=NightlySave listing level=Incremental
@output
Que mostrará uma lista completa de todos os arquivos a serem “backupeados” 
para o “Job NightlySave” durante um “backup” incremental, salvando a saída no 
arquivo “/tmp/listing”.
Help:
help 
Este mostra todos os comandos disponíveis na console “Bacula”.
 138
Label:
label
Comando utilizado para etiquetar fisicamente os volumes. Se quiser 
especificar todos os atributos, esta é a forma completa:
Ex.: label storage=<storage-name> volume=<volume-name> 
slot=<slot>
Se qualquer uma das opções for deixada de lado, você será perguntado por 
ela. O tipo de mídia é automaticamente pego da definição do “Storage” que “você” 
escolher. Daí, o programa do Console entra em contato com o storage daemon e pede 
que a fita seja etiquetada. Uma vez que tudo ocorra bem, o volume será criado no 
catálogo.
Só podem ser utilizados letras, números e os caracteres especiais hífen (-), 
“underscore” (_), dois-pontos (:), e ponto (.). Todos os outros caracteres, inclusive o 
espaço, são ilegais. 
Observe que, quando etiquetando uma fita em branco, “Bacula” irá receber 
erros de I/O quando tentar saber se a fita já está etiquetada. Para evitar estas 
mensagens, basta escrever uma marca EOF antes de tentar etiquetar a fita 
(comandos do próximo quadro).
O comando label pode falhar por uma série de motivos:
1. O nome do volume que você especificar já existe no banco de dados. 
2. Já existe uma fita montada no device (neste caso você deve desmontar, inserir a 
fita em branco e usar o comando label). 
3. A fita no "device" já é uma fita com "label" no catálogo (Bacula nunca vai mudar 
o label de uma fita já etiquetada, a não ser que seja reciclada ou através do 
comando "relabel"). 
 139
4. Não há fita no drive. 
Existem duas maneiras de re-etiquetar um volume que já tem label do 
“Bacula”. Usando a força bruta, basta colocar um EOF na fita através do programa 
mt. Exemplo:
mt -f /dev/st0 rewind 
mt -f /dev/st0 weof
E então, usar o comando label. Mas observe que, as informações do volume 
que você acabou de apagar, permanecerão no catálogo (então, terá também de usar o 
comando "delete" no “bconsole”, para apagá-lo).
O método indicado para mudar o "label" de um volume é - pimeiro purgar o 
volume (comando purge) e então usar o comando "relabel".
Se seu robô-de-fitas suporta etiquetas com código de barras, você pode 
etiquetar todas as fitas inseridas através do comando "label barcodes". Para cada 
fita, o Bacula irá montá-la e etiquetá-la com o mesmo nome do código de barras. A 
informação também será transferida para o catálogo. Qualquer código que comece 
com os mesmos caractéres da opção "CleaningPrefix=xxx" dentro de uma Pool, será 
tratada como uma fita de limpeza, e não etiquetada. Entretanto, uma entrada para a 
fita de limpeza será feita no catálogo. Exemplo:
Pool {
Name ...
Cleaning Prefix = "CLN"
}
Qualquer slot que contenha um código de barras CLNxxxx será tratado como 
uma fita de limpeza, e nunca montada.
 140
A forma completa do comando é:
update storage=xxx pool=yyy slots=1-5,10 barcodes
List:
list
O comando "list" lista o conteúdo do Catálogo selecionado. Assim, existem 
várias formas para este comando:
list jobs
Para descobrir o que significam os códigos de “status” dos “jobs”, consulte o 
Anexo I desta obra.
list jobid=<id>
list ujobid<unique job name>
list job=<job-name> 
list jobname=<job-name> 
list jobmedia
list jobmedia jobid=<id>
list jobmedia job=<job-name>
list files jobid=<id>
 141
list files job=<job-name>
list pools
list clients
list jobtotals
list volumes
list volumes jobid=<id>
list volumes pool=<pool-name>
list volumes job=<job-name>
list volume=<volume-name> 
list nextvolume job=<job-name>
list nextvol job=<job-name>
list nextvol job=<job-name> days=nnn
Obviamente, não é necessário especificar todos estes argumentos, bastando 
apenas o comando "list", para que o "Bacula" faça as perguntas necessárias.O 
comando "list nextvol" irá mostrar o próximo volume a ser utilizado para um job 
específico. Existem uma série de fatores que interferem nessa escolha, incluindo o 
 142
"tempo" e "prioridades" dos jobs. Assim, esse comando é uma estimativa, mas não 
uma resposta definitiva. Ainda, existe uma opção na qual pode se descobrir qual a 
fita a ser utilizada para um job daqui a 5 dias (exemplo). Assim, deve ser utilizado: 
"list nextvol job=MyJobdays=3".
Como outro exemplo deste comando, o "list pools" produz o seguinte 
“output”:
+------+---------+---------+---------+----------+-------------+
| PoId | Name | NumVols | MaxVols | PoolType | LabelFormat |
+------+---------+---------+---------+----------+-------------+
| 1 | Default | 0 | 0 | "backup" | * |
| 2 | Recycle | 0 | 8 | "backup" | File |
+------+---------+---------+---------+----------+-------------+
Reiterando - o comando "list" mostra o que há no banco de dados. Algumas 
coisas são inseridas nela imediatamente quando o "Bacula" é executado - mas, em 
geral, a maioria só acontece quando a ação correspondente é executada pela 
primeira vez (exemplo: adição de um novo cliente na configuração).
O "Bacula" deverá criar uma entrada no catálogo para o cliente, assim que 
for submetido um job pela primeira vez. Apenas o comando "status" não causará 
nenhuma inserção no banco. O registro do cliente no banco de dados acontecerá 
mesmo que o job termine em falha. Além disso, quando o cliente é contactado pela 
primeira vez, informações adicionais são coletadas e adicionadas ("uname -a" 
output).
Se quiser saber quais Clientes estão configurados no bacula-dir.conf, basta 
usar o comando do console "show clients".
“Status” dos Volumes no “Bacula”
Através do comando list media, é possivel identificar o estado (status) dos 
volumes do Bacula. São eles:
* Append: é o primeiro “status” que uma mídia recém etiquetada (através do 
 143
comando label) recebe. Neste estado o volume pode ser gravado mas apenas no 
espaço livre que ainda resta. O que já estaria gravado não é sobrescrito.
* Full: o volume está cheio. Neste caso não é mais possível gravá-lo sem que 
haja perda de informações. Para gravá-lo novamente, é necessário que o volume seja 
reciclado (seja automaticamente pelo bácula, seja através do comando “purge”).
* Used: O volume ainda possui espaço, mas neste caso não pode mais ser 
gravado. A mudança de append para used é importante pq, só neste momento, o 
tempo de retenção irá começar a contar. Esta mudança, pode ser feita de maneira 
manual ou automática pelo bacula, através da configuração de limites (jobs, bytes, 
tempo de uso – tudo isso por volume).
* Error: Por algum motivo o volume terminou em erro – o que não significa 
que não possa ter seus arquivos restaurados. Se vc tiver certeza que não se trata de 
um problema físico, pode simplesmente mudar seu status manualmente para “used”, 
e esperar que ele seja reciclado.
* Recycled: O volume foi reciclado e está pronto para ser sobrescrito pelo 
Bacula.
* Archive: o administrador explicitamente informa que aquele volume 
deve ser mantido intacto – ou seja, não será reciclado. Útil para preservar 
"backups" marcos (ex.: primeiro "backup" de um servidor).
* Disabled: o volume está completamente indisponível para o uso do “Bacula” 
(ex.: fitas que foram retiradas do robô, e que portanto não podem ser acessadas de 
maneira automática).
* Cleaning: indica que é uma fita de limpeza.
* Read-only: o “Bacula” poderá ler, mas não sobrescrever a fita.
Llist:
llist
O comando "llist" ou "lista longa" aceita todos os argumentos do comando 
"list". A diferenção é que o "llist" lista o conteúdo completo de cada registro do banco 
 144
selecionado. Ele faz isso visitando os vários campos do registro verticalmente, um 
campo por linha, podendo produzir um número muito largo de linhas em "output". Se 
ao invés do "list pools" (exemplo anterior), fosse usado o "llist pools", este seria o 
resultado:
 PoolId: 1
 Name: Default
 NumVols: 0
 MaxVols: 0
 UseOnce: 0
 UseCatalog: 1
 AcceptAnyVolume: 1
 VolRetention: 1,296,000
 VolUseDuration: 86,400
 MaxVolJobs: 0
 MaxVolBytes: 0
 AutoPrune: 0
 Recycle: 1
 PoolType: "backup"
 LabelFormat: *
 PoolId: 2
 Name: Recycle
 NumVols: 0
 MaxVols: 8
 UseOnce: 0
 UseCatalog: 1
 AcceptAnyVolume: 1
 VolRetention: 3,600
 VolUseDuration: 3,600
 MaxVolJobs: 1
 MaxVolBytes: 0
 AutoPrune: 0
 Recycle: 1
 PoolType: "backup"
 LabelFormat: File
Messages:
messages 
Qualquer mensagem pendente no console seja imediatamente exibida (pode 
ser abreviado - exemplo: m).
Mount:
mount
 145
O comando mount é utilizado para que o "Bacula" possa ler um volume em 
determinado dispositivo físico. É uma maneira de dizer ao "Bacula" que uma "fita" foi 
inserida e que ele deve examiná-la. Se você possui um robô de fitas, o comando 
"mount", além de montar a fita, irá carregá-la no drive (passo lógico e fundamental 
para que haja a montagem). Da mesma forma o comando "umount", descarregará a 
fita do drive.
Ex. 1: mount storage=<storage-name>
Ex. 2: mount [ jobid=<id> | job=<job-name> ]
Se a opção "Automatic Mount = yes" estiver configurada no recurso do 
"storage daemon", na maioria das vezes o "Bacula" irá montar automaticamente o 
volume, ao menos que um comando "umount" seja explicitamente aplicado no 
console.
Python:
python
O comando python aceita um único argumento: "python restart"
Isso faz com que o interpretador Python no "Director" seja reinicializado. Isso 
pode ser útil para testes na medida que o "director" inicia em conjunto com o 
interpretador, sendo que não há outra maneira de aceitar mudanças no "script" de 
inicialização DirStartUp.py.
 
Prune:
prune
O comando prune permite que você remova, com segurança, registros 
expirados do banco de dados, referente a "jobs" e "volumes". Este comando só afeta o 
catálogo, nunca os volumes. Em todos os casos, o comando "prune" aplica o tempo de 
retenção para os mencionados registros. Você pode "prunar" informações sobre os 
arquivos nos registros de "jobs"; pode "prunar" jobs expirados; pode "prunar" ambos, 
registros de "files" e "jobs".
 146
Sintaxe: prune files|jobs|volume client=<client-name> 
volume=<volume-name>
Para um volume ser prunado, seu status precisa ser "full", "used" ou "append".
Purge:
purge
O comando purge deleta informações sobre "jobs" e "volumes" do catálogo, 
sem respeitar o tempo de retenção. De igual sorte, só confere modificações no banco 
de dados, sem alterar os dados escritos nos volumes. Este comando pode ser 
perigoso poque informações ainda gravadas nos volumes podem ter seu reflexo no 
banco de dados apagado.
As formas permitidas do “purge” são:
purge files jobid=<jobid>|job=<job-name>|client=<client-name>
purge jobs client=<client-name> (of all jobs)
purge volume|volume=<vol-name> (of all jobs)
Para que funcione, o status do volume deve ser: "Append", "Full", "Used", or 
"Error".
Relabel:
relabel
Este comando é utilizado para modificar o "label" (etiqueta) dos volumes 
físicos. A forma completa deste comando é:
relabel storage=<storage-name> oldvolume=<old-volume-name> 
volume=<newvolume-name>
Se esquecer qualquer parte, será perguntado por ela. Para que o volume 
 147
(antigo) seja "reetiquetado" é necessário que exsta no catálogo e seu status seja 
"purgued ou recycled" Isso aconte automaticamente quando os tempos de retenção 
são expirados, ou você pode "forçar" através do comando "purge".
Uma vez que o comando "relabel" é executado com sucesso, as informações 
antigas do volume não podem ser restauradas.
Release:
release
Este comando faz com que o "storage daemon" rebobine a fita atual do drive e 
leia novamente seu volume na próxima vez que a fita for usada.
Ex.: release storage=<storage-name>
Após o comando "release", o dispositivo continua aberto pelo Bacula, então 
continua não podendoser utilizado por outro programa. Para liberar completamente 
o drive, necessário utilizar o comando "umount".
Reload:
reload
O comando "reload" faz com que o "director" releia seu arquivo de 
configuração e aplique os novos valores. Os novos valores terão efeito imediatamente 
para todos os novos jobs.
Apesar de ser possível usar o "reload" "on the fly", enquanto jobs estão sendo 
executados, é uma operação complexa e que pode trazer efeitos colaterais. Assim, se 
você o fizer, deve reiniciar o "director daemon" assim que possível.
Restore:
restore
O coamndo "restore" permite que sejam selecionados um ou mais "JobIds" 
(número que identifica os jobs) para serem restaurados, utilizando vários métodos. A 
partir de quando os jobs são selecionados, os registros de arquivos são colocados 
numa árvore interna de diretório do "Bacula", e assim podem ser escolhidos os 
 148
arquivos/diretórios que devem ser restaurados. Este modo é similar ao modo 
interativo de seleção do Unix (apesar de que podem ser utilizadas ferramentas 
gráficas para o restore - ex.: Webacula). Sintaxe:
Ex.: restore storage=<storage-name> client=<client-name> 
where=<path> pool=<pool-name> fileset=<fileset-name> select 
current all done
Se especificado, a opção "current" diz para o "Bacula" automaticamente 
escolher o "backup" mais recente para ser restaurado. Caso contrário, será 
perguntado. A opção "all", diz para selecionar todos os arquivos do "backup" para o 
"restore". Caso não seja especificado, será aberto o "prompt" para seleção de 
arquivos.
Run:
Este comando permite que sejam agendados "jobs" para que sejam executados 
imediatamente. A forma completa deste comando é:
run job=<job-name> client=<client-name> fileset=<FileSet-name> 
level=<level-keyword> storage=<storage-name> where=<directory-
prefix> when=<universal-time-specification> yes
Qualquer informação necessária não especificada será listada para seleção e, 
antes do início do "job", aparecerá uma tela de confirmação, na qual é possível 
aceitar, rejeitar ou modificar os parâmetros do "job" a ser executado, a menos que 
você tenha especificado o "yes", quando o job é imediatamente iniciado.
Como exemplo, quando executado o comando "run", aparecerá:
A job name must be specified.
The defined Job resources are:
 1: Matou
 2: Polymatou
 3: Rufus
 4: Minimatou
 5: Minou
 6: PmatouVerify
 7: MatouVerify
 8: RufusVerify
 9: Watchdog
Select Job resource (1-9):
 149
Se selecionado o 5:
Run "backup" job
JobName: Minou
FileSet: Minou Full Set
Level: Incremental
Client: Minou
Storage: DLTDrive
Pool: Default
When: 2003-04-23 17:08:18
OK to run? (yes/mod/no):
Se "yes", o "job" irá começar. Se for digitado "mod", poderão ser modificadas 
as seguintes configurações:
Parameters to modify:
 1: Level
 2: Storage
 3: Job
 4: FileSet
 5: Client
 6: When
 7: Pool
Select parameter to modify (1-7):
De igual sorte, é possível programar o "job" para começar em um outro 
horário "mais tarde", bastando apenas configurar a opção "when" (no. 6). O tempo 
desejado deve estar no formato: YYYY-MM-DD HH:MM:SS.
Setdebug:
setdebug
Configura o level de "debug" em cada "daemon". A forma completa deste 
comando é:
Ex.: setdebug level=nn [trace=0/1 client=<client-name> | dir | 
director | storage=<storage-name> | all]
Se for configurado "trace=1" a investigação será habilitada, e o "daemon" na 
qual o "setdebug" se aplica será colocado em "trace mode". Assim, todo o "output" do 
"debug" irá para o arquivo "bacula.trace", no mesmo diretório do "daemons". 
Normalmente, "tracing" somente é usado para clientes "Win32" onde o "output" do 
"debug" não pode ser escrito para um terminal ou redirecionado para um arquivo. Os 
arquivos gerados precisam ser deletados manualmente.
 150
Show:
show
O comando show listará os registros do "Director" como definidos no ser 
arquivo de configuração (bacula-dir.conf). Este comando é principalmente usado com 
o propósito de deteccção de "bugs". Basicamente, mostra como o "Bacula" está 
interpretando seu arquivo de configuração e, portanto, não se confunde com o 
comando "list" (que traz informações do catálogo). Estas são as opções aceitas: 
"catalogs, clients, counters, devices, directors, filesets, jobs, messages, pools, 
schedules, storages, all, help."
Sqlquery:
sqlquery
Este comando coloca a console em modo "query SQL", no qual cada linha 
digitada é concatenada coma última linha, até que um ponto-e-vírgula (;) seja visto. O 
ponto-e-vírgula termina o comando, que é passado diretamente para a "engine" do 
banco de dados "SQL". Quando a saída do "engine SQL" é mostrada, a formação de 
um novo comando "SQL" começa. Para terminar o "query mode", basta digitar um 
ponto (.) na primeira coluna. Importante ter cuidado para não utilizar comandos que 
danifiquem o banco.
Dependendo no banco usado (MySQL, PostgreSQL ou SQLite), os comandos 
podem variar.
Status:
status
Irá mostrar o "status" do "daemon especificado. A forma completa deste 
comando é:
Ex.: The full form of this command is:status [all | dir=<dir-
name> | director | client=<client-name> | storage=<storage-name> 
 151
| days=nnn]
Se escolher "status dir", o console irá listar qualquer "job" em execução, um 
sumário dos "jobs" agendados para as próximas 24 horas. A lista dos "jobs" 
agendados inclui os volumes que serão usados. Duas coisas devem ser ditas: 1.para 
obter o nome do volume, o código é o mesmo do utilizado quando o "job" é 
executado; 2. O volume listado é apenas um bom palpite. O volume utilizado pode 
variar com o tempo (podem expirar retenções até o momento do "job" começar). 
Ainda, outro "job" poder completar o volume, necessitando de outro novo.
Na listagem "Running Jobs", você deve encontrar informação deste tipo:
2507 Catalog MatouVerify.2004-03-13_05.05.02 is waiting execution
5349 Full Catalog"backup".2004-03-13_01.10.00 is waiting for higher
 priority jobs to finish
5348 Differe Minou.2004-03-13_01.05.09 is waiting on max Storage jobs
5343 Full Rufus.2004-03-13_01.05.04 is running
Olhando a listagem, de baixo para cima, "JobId 5343" (Rufus) está rodando. 
"JobId" 5348 (Minou) está aguardando o "JobId 5343" terminar, para poder utilizar o 
mesmo "Storage" (provavelment, limitado a 01 "job" máximo). "JobId" 5349 tem uma 
prioridade menor que todos os outros "jobs" e, portanto, está esperando que eles 
terminem. Finalmente, o "JobId" 2508 (MatouVerify) está esperando porque, nesta 
configuração, apenas um "job" pode rodar em determinado momento.
Se você quiser saber, através do "status dir", os "jobs" agendados para os 
próximos 3 dias, você pode adicionar a opção "days=3 option".
Se você parece estar bloquado, terá uma idéia geral do problema através do 
"status dir", mas pode ainda mais informação específica através do "status 
storage=xxx". Por exemplo, num sistema ocioso, tenho:
status storage=File
Connecting to Storage daemon File at 192.168.68.112:8103
rufus-sd Version: 1.39.6 (24 March 2006) i686-pc-linux-gnu redhat (Stentz)
Daemon started 26-Mar-06 11:06, 0 Jobs run since started.
Running Jobs:
No Jobs running.
====
Jobs waiting to reserve a drive:
====
 152
Terminated Jobs:
 JobId Level Files Bytes Status Finished Name
======================================================================
 59 Full 234 4,417,599 OK 15-Jan-06 11:54 kernsave
====
Device status:
utochanger "DDS-4-changer" with devices:
 "DDS-4" (/dev/nst0)
Device "DDS-4"(/dev/nst0) is mounted with Volume="TestVolume002"
Pool="*unknown*"
 Slot 2 is loaded in drive 0.
 Total Bytes Read=0 Blocks Read=0 Bytes/block=0
 Positioned at File=0 Block=0
Device "Dummy" is not open or does not exist.
No DEVICE structure.
Device "DVD-Writer" (/dev/hdc) is not open.
Device "File" (/tmp) is not open.
====
In Use Volume status:
====
Agora, o que me diz que nenhum "job" está sendo executado, está no fato de 
que nenhum dispositivos está em uso. Neste momento, se um dispositivo for 
desmontado e um "job" for executado para este "file device", o trabalho ficará 
bloqueado. Se for solicitado um comando "status storage", então esta será a 
mensagem: 
status storage=File
...
Device status:
Autochanger "DDS-4-changer" with devices:
 "DDS-4" (/dev/nst0)
Device "DDS-4" (/dev/nst0) is not open.
 Device is BLOCKED. User unmounted.
 Drive 0 is not loaded.
Device "Dummy" is not open or does not exist.
No DEVICE structure.
Device "DVD-Writer" (/dev/hdc) is not open.
Device "File" (/tmp) is not open.
 Device is BLOCKED waiting for media.
====
...
Algumas vezes, o volume estará "blocked" porque o "Bacula" não tem ou não 
pode escrever em nenhum dos volumes existentes na pool para qual foi submetido o 
“job”.
 153
Unmount:
unmount
Este comando faz com que o "storage daemon" indicado desmonte o 
dispositivo especificado. A forma completa deste comando é:
unmount storage=<storage-name>
unmount [ jobid=<id> | job=<job-name> ]
Update:
update
Este comando irá atualizar o catálogo a respeito de uma "pool" 
específica, de um volume ou dos "slots" de um robô-de-fitas. No caso de 
atualizar o registro de uma "pool", a nova informação será automaticamente obtida 
da configuração correspondente do Director. Ela pode ser utilizada para aumentar 
o número de volumes máximo permitido. As palavras chaves podem ser 
configuradas:
 media, volume, pool, slots
No caso de atualizar um volume, você será perguntado qual valor deseja 
mudar:
 Volume Status
 Volume Retention Period
 Volume Use Duration
 Maximum Volume Jobs
 Maximum Volume Files
 Maximum Volume Bytes
 Recycle Flag
 Slot
 InChanger Flag
 Pool
 Volume Files
 Volume from Pool
 All Volumes from Pool
Para o "update slots", o "Bacula" irá obter a lista dos volumes a partir do 
"storage daemons", e automaticamente irá atualizar no registro "media" do catálogo. 
 154
Essa funcionalidade é muito útil quando são retiradas ou colocadas fitas diferentes 
dos magazines. Quanto realizado este "update", o "InChanger flag" também muda, 
indicando se a fita está ou não no robô.
Se seu robô não suportar código de barras, o comando "update slots scan" irá 
fisicamente montar cada fita e descobrir seu nome do volume.
Para "pool" - "update pool", "Bacula" irá mover o registro do volume de uma 
"pool" para a especificada.
Para "Volume from Pool" e "All Volumes from Pool", todos os seguintes valores 
são atualizados, a partir do arquivo de configuração: Recycle, VolRetention, 
VolUseDuration, MaxVolJobs, MaxVolFiles, and MaxVolBytes.
Forma completa do comando:
update volume=xxx pool=yyy slots volstatus=xxx VolRetention=ddd 
VolUse=ddd MaxVolJobs=nnn MaxVolBytes=nnn Recycle=yes|no 
slot=nnn
 
Use:
use
Permite especificar qual "catálogo" (banco de dados) usar. Normalmente, você 
irá usar apenas um banco, então será feito automaticamente. Caso esteja utilizando 
dois, este comando servirá para alternar entre eles. Sintaxe completa: use 
<database-name>
Var:
var
Este comando pega uma "string" ou “quoted string” e faz expansão da 
variável, da mesma forma que utilizando a opção “LabelFormat” no arquivo de 
configuração. Assim diferentes “strings” para etiquetamento de volumes podem ser 
testadas. 
 155
Version:
version
Mostra a versão do "director".
Quit:
quit
Sai do bconsole graciosmente (aguardando processos que eventualmente 
estejam pendentes. O comando .quit deixa o “Bacula” imediatamente.
Query:
query
Este comando lê pesquisas SQL pré-definidas a partir de um arquivo "query" 
(cuja localização está definida pelo recurso "QueryFile", no bacula-dir.conf. Ele te dá 
então uma lista das consultas possíveis, e então o comando é submetido para o 
catálogo (banco de dados). Estas são as consultas padrão (versão 1.24):
Available queries:
 1: List Job totals:
 2: List where a file is saved:
 3: List where the most recent copies of a file are saved:
 4: List total files/bytes by Job:
 5: List total files/bytes by Volume:
 6: List last 20 Full "backups" for a Client:
 7: List Volumes used by selected JobId:
 8: List Volumes to Restore All Files:
 9: List where a File is saved:
Choose a query (1-9):
Wait:
wait
Faz com que o "director" pause até que nenhum job esteja rodando. Este 
comando é útil quando é desejado começar um "job", apenas, quando os outros 
terminem.
 156
11.1. Comandos especiais com Arroba (@) 
Unindo ao “shell script”, o “Bacula” se torna, praticamente, uma 
ferramenta de infinitas possibilidades. Os comandos abaixo permitem esta interação :
@input <filename>
Lê e executa comandos de um arquivo especificado.
@output <filename> w/a
Manda todo a saída seguinte para um arquivo, se especificado, com as opções 
de sobrescrita (w), ou “append” (a). Ainda, pode se redirecionar a saída para o 
terminal, se não especificado nenhum arquivo. 
@tee <filename> w/a 
Manda a saída seguinte para o arquivo especificado e para o terminal. 
@sleep <seconds> 
Dormir por uma quantidade de segundos.
@time
Dá um “print” do horário atual. 
@version 
Mostra a versão atual do “Bacula”.
@# anything
Comentários.
 157
11.2. Executando o bconsole por Shell Script
Várias tarefas do bconsole podem ser executadas através de “shell script”. Por 
exemplo:
./bconsole -c ./bconsole.conf <<END_OF_DATA
unmount storage=DDS-4
quit
END_OF_DATA
mt -f /dev/nst0 eject
Quando executado, este “script” irá desmontar o storage “DDS-4” e ejetar a 
fita do dispositivo /dev/nst0 (exemplo). Você pode querer executar este “script” após 
o último job (no caso de drives de fita manuais), através da opção “RunAfterJob”.
 158
Capítulo 12 
Restaurando Arquivos
Para realização de “restore”, o “Bacula” traz uma série de opções para que 
seja localizada a informação necessária. Acesse a console e execute o comando:
* restore
O sistema então, perguntará qual o método utilizado para pesquisa:
To select the JobIds, you have the following choices:
 1: List last 20 Jobs run
 2: List Jobs where a given File is saved
 3: Enter list of comma separated JobIds to select
 4: Enter SQL list command
 5: Select the most recent "backup" for a client
 6: Select "backup" for a client before a specified time
 7: Enter a list of files to restore
 8: Enter a list of files to restore before a specified time
 159
 9: Cancel
Select item: (1-9):
Entre as diversas opções para restore, pode-se selecionar os "backups" mais 
recentes (opção 5) ou um Job específico (opção 3). Selecione, por exemplo, a opção 5:
Defined Clients:
 1: suse-fd
 2: scott2-fd
Select the Client (1-2):
Selecione o cliente desejado.
The defined FileSet resources are:
 1: Catalog
 2: Full Set
Select FileSet resource (1-2):
Selecione o FileSet.
You have selected the following JobIds: 43,55,56,59
Building directory tree for JobId 43 ... ++++++++++++++++++++++
+++++
Building directory tree for JobId 55 ...
Building directory tree for JobId 56 ... +
Buildingdirectory tree for JobId 59 ...
4 Jobs, 342,907 files inserted into the tree.
Após a construção da árvore de diretórios, há a direcionamento para o 
 160
ambiente do restore.
You are now entering file selection mode where you add (mark) 
and remove (unmark) files to be restored. No files are initially 
added, unless you used the "all" keyword on the command line.
Enter "done" to leave this mode.
cwd is: /
$
Digite “?” para exibir a lista de comandos:
$ ?
 Command Description
 ======= ===========
 cd 
change current directory
 count 
count marked files in and below the cd
 dir 
list current directory
 done 
leave file selection mode
 estimate 
estimate restore size
 exit 
 161
exit = done
 find 
find files -- wildcards allowed
 help 
print help
 ls 
list current directory -- wildcards allowed
 lsmark 
list the marked files in and below the cd
 mark 
mark dir/file to be restored -- recursively in dirs
 markdir 
mark directory name to be restored (no files)
 pwd 
print current working directory
 unmark 
unmark dir/file to be restored -- recursively in dir
 unmarkdir unmark directory name only -- no recursion
 quit 
quit
 ? 
 162
print help
Primeiramente, é necessário acessar o diretório o qual encontram-se os 
arquivos a serem restaurados, utilizando o comando cd. Em seguida, marque os 
arquivos através do comando mark “nome_do_arquivo”. Caso todos os arquivos do 
diretório necessitem ser restaurados, digite o comando abaixo:
$ mark *
346,620 files marked.
Após marcar os arquivos, execute o comando done para ir à tela de 
confirmação:
Run Restore job
JobName: RestoreFiles
Bootstrap: /var/bacula/working/dhcp-dir.restore.1.bsr
Where: /tmp/bacula-restores
Replace: always
FileSet: dhcp
"backup" Client: dhcp-fd
Restore Client: dhcp-fd
Storage: changer
When: 2009-05-21 16:23:05
Catalog: MyCatalog
Priority: 0
OK to run? (yes/mod/no):
As mais importantes opções, são:
Where: em que pasta os arquivos serão restaurados.
 163
Replace: Se você deseja sobrescrever arquivos durante a restauração.
"backup" Client: Você está restaurando arquivos de que cliente?
Restore Client: Em que cliente você vai restaurar os arquivos? (permite 
restauração cruzada).
Depois das modificações, digite “yes” para submeter o “job”.
Restauração Cruzada
Para restaurar os dados "backupeados” de uma máquina, em outra, 
necessário fazer o seguinte:
Realize os procedimentos de restauração normais para o cliente dos quais os 
arquivos foram "backupeados”…. Comando “restore” > seleção dos “jobids” > 
seleção dos arquivos. Na tela de confirmação do restore…:
Run Restore job
 JobName: RestoreFiles
 Where: /tmp/bacula-restores
 Replace: always
 FileSet: Full Set
 "backup" Client: rufus-fd
 Restore Client: rufus-fd
 Storage: File
 When: 2005-07-10 17:33:40
 Catalog: MyCatalog
 164
 Priority: 10
 OK to run? (yes/mod/no):
 …basta modificar o “Restore Client”, escolhendo então o cliente para qual 
seja restaurar os arquivos.
Atenção! Jamais altere o “"backup" Client” (que é o cliente de onde os 
arquivos foram copiados originalmente), pois provavelmente seu “job” retornará 
um erro.
 165
Capítulo 13 
Restaurando Informações do Catálogo 
13.1. Restaurando catálogo MySQL a partir do 
arquivo .sql ("backup")
Para restaurar o catálogo do Bacula (MySQL), de um arquivo de “dump” 
(*.sql):
mysql (comando para entrar na console do MySQL)
create database bacula (se ainda não criado)
use bacula (seleciona a database do Bacula)
\. bacula.sql (faz o restore) 
 166
 
Ainda, podemos fazer desta outra maneira:
mysql bacula < bacula.sql
Você pode também querer utilizar “nohup” e em “background, pois pode se 
tratar de um processo demorado…
nohup mysql bacula < bacula.sql &
Exercício:
Apague seu banco-de-dados do Bacula e o reataure através de um dump 
.sql.
13.2. bscan
Algo deu errado e as informações do catálogo foram perdidas. 
O “Bacula” possui uma poderosa ferramenta que restaura as informações da 
fita gravada pelo “storage”, no catálogo.
Deve ser executada sem nenhum dos “daemons” em execução. Assim: 
bscan -s -m -c bacula-sd.conf -v -V Vol001 /dev/st0
[command] [bacula sd. conf. File][volumes][tape storage device]
bscan -s -m -c bacula-sd.conf -v -V Vol001 /mnt/backups
[command] [bacula sd. conf. File][volumes][HD storage device]
Este procedimento leva um certo tempo pois vai “varrer” toda a fita em busca 
de informações.
 167
Se por um acaso não conseguir usar o bscan, a última ferramenta para restore 
de uma fita seria o bextract, que utiliza todos os dados da mídia.
Exercício:
Apague um volume com dados de seu catálogo e depois restaure através do 
“bscan”.
 168
Capítulo 14 
Upgrade de Versões do Bacula
 
5. Considerações gerais:
Este manual deverá servir para qualquer upgrade – não só das versões 3.x 
para a 5x.
Entretanto, se você tem uma versão inferior 2.x, deverá atualizar para a 3.x, 
rodar o “script” (/etc/bacula/update_bacula_tables), atualizar para a versão 5.x e, 
novamente, rodar o mencionado “script”.
Você deve atualizar o “director” e “storage” ao mesmo tempo. Entretanto, os 
clientes podem ser atualizados gradativamente.
Os arquivos de configuração das versões antigos podem ser mantidos sem 
problemas.
6. Atualizando o “director” e “storage” (Servidor Bacula… Que 
inclui também seu próprio File Daemon):
2.1. Faça “backup” de sua pasta /etc/bacula. Ex.:
 mkdir /updatebkp
 cp -r /etc/bacula /updatebkp/
 169
 2.2. Faça "backup" de seu banco de dados (catálogo):
 /etc/bacula/make_catalog_"backup" -u bacula -p[senha do banco]
 2.3. Faça o “download” do tar.gz do “Bacula”, para a pasta /tmp. No caso da 
versão 5.0: 
cd /tmp
wget 
http://downloads.sourceforge.net/project/bacula/bacula/5.0.0/bac
ula-5.0.0.tar.gz?use_mirror=ufpr
2.4. Ainda no /tmp, descompacte o .tar.gz. Ex.:
tar -xzvf bacula-5.0.0.tar.gz
2.5. Entre no diretório criado:
cd /tmp/bacula-5.0.0
2.6. Então (observe que o ./configure pode requerer opções… Ex.: –with-mysql, 
para indicar que estará usando o banco-de-dados Mysql):
./configure
make
make install
2.7. Agora, atualize também seu banco de dados:
/etc/bacula/update_bacula_tables
 170
2.8. Reinicie seu banco-de-dados.
2.9. Reinicie o “Bacula”:
/etc/bacula/bacula restart
Pronto! Agora acesse o “Bacula” através do “bconsole” e realize um “backup” 
como forma de teste. Não esqueça de testar a comunicação com algum cliente, 
através do comando status > client.
7. Atualizando um cliente:
3.1. Faça “backup” de sua pasta /etc/bacula. Ex.:
mkdir /updatebkp
cp -r /etc/bacula /updatebkp/
3.2. Faça o “download” do tar.gz do “Bacula”, para a pasta /tmp. No caso da 
versão 5.0:
cd /tmp
wget 
http://downloads.sourceforge.net/project/bacula/bacula/5.0.0/bac
ula-5.0.0.tar.gz?use_mirror=ufpr
3.3. Ainda no /tmp, descompacte o .tar.gz. Ex.:
tar -xzvf bacula-5.0.0.tar.gz
3.4. Entre no diretório criado:
cd /tmp/bacula-5.0.0
3.5. Então (mude agora a opção do ./configure para –enable-client-only, para 
indicar que estará apenas compilando o “file daemon” do “Bacula”):
 171
./configure –enable-client-only
make
make install
3.6. Reinicie o“file daemon”:
/etc/bacula/bacula-ctl-fd restart
Pronto! Agora acesse o servidor do “Bacula” e verifique o funcionamento do 
cliente recém atualizado através do comando: status > client > nome do cliente.
 172
Capítulo 15 
Acessórios para o “Bacula”
Os programas (ou “scripts”) abaixo são desenvolvidos por terceiros em relação 
à comunidade do “Bacula”, mas podem ser muito úteis.
15.1 Interfaces Gráficas
BAT (Bacula Administration Tool)
Trata-se da GUI mais avançada para o bacula: a Ferramenta de Administração 
Bacula (BAT -- Bacula Administration Tool Console), que funciona tanto no Linux 
quanto Windows.
Esta interface foi desenhada para facilitar operações de restauração o máximo 
possível em comparação ao console de texto básico. 
Dentre as funcionalidades, é possível a submissão de “jobs”, visualização de 
estatísticas, mudança dos estados e atributos dos volumes, comandos como o 
“purge”, etc.
 173
Sua instalação pode ser facilmente realizada através do comando:
# apt-get install bacula-console-qt
Esta interface GUI foi desenhada para facilitar operações de restauração o máximo 
possível em comparação ao console de texto básico. 
Ainda, você pode compilar o BAT em conjunto com “Bacula”, através da 
opção –enable-bat, no “configure”. Assim: ./configure –enable-bat. [dependência: 
qt4-dev-tools]
Depois de instalado, necessário configurar o arquivo /etc/bacula/bat.conf, de 
acordo com as configurações do seu “director” (de maneira semelhante ao 
bconsole.conf, podendo um ser cópia do outro). Abaixo, foto da BAT:
Webacula 
Uma interface em php para monitoração e restauração de arquivos - que será 
 174
detalhada no próximo capítulo (A php web interface for monitoring and restoring 
files)
http://webacula.sourceforge.net/
Recursos básicos:
• Restaurar total ou paricalmente arquivos de um “job”.
• Montar ou desmontar “storages”
• Mostra “jobs” com erros nos últimos 7 dias
• Mostra a condição dos volumes
• Mostra os “jobs” agendados pelas próximas 24 horas
• Mostra todos os “jobs” em execução.
• Mostra “jobs” terminados (últimas 24 horas)
• Informação detalhada sobre volumes, “pools”, “storages” e clientes.
brestore
http://brestore.webhop.info
Interface gráfica para restore. Esta disponível no CVS “Bacula”
bweb
http://brestore.webhop.info/web
Trabalha em conjunto com o “brestore” e permite a execução de “jobs”, 
acompanhar a execução, administrar volumes e até robôs-de-fitas. Também está 
disponível no CVS do “Bacula”.
 175
15.2. Variados 
Jbacula
http://philippe.martin.name/jbacula/
Ferramenta Java que cria formulários para facilitar a configuração do 
“Bacula”.
ddrescue
http://www.gnu.org/software/ddrescue/ddrescue.html
Programa desenhado para tentar restaurar dados de um fita defeituosa. 
15.2. Monitoração
Bacuview
Um monitor baseado em “Ruby on Rails” (http://bacuview.rubyforge.org/).
Plug-in para o Nagios
[1] http://linux.softpedia.com/get/System/System-Administration/nagios-check-
bacula-23898.shtml
[2] http://www.devco.net/pubwiki/Bacula/MonitoringWithNagios
 176
Capítulo 16
16.1. Instalação do Webacula (GUI) – 
Versão: 3.*
Esta ferramenta merece um tópico específico, pois trata-se de uma interface 
bastante amigável para monitoração, administração e/ou operação do “Bacula”. 
inclusive, possui tradução para o Português.
Exercício:
Instale o “Webacula” de acordo com os procedimentos que começam 
abaixo...
Requerimentos:
- Bacula 3.0 ou superior.
- Zend Framework versão 1.8.3 ou superior.
- PHP 5.2.4 ou superior com a extensão PDO ativa. Detalhes: 
 177
http://framework.zend.com/manual/en/requirements.html
- Apache com mod_rewrite.
- Pacote php-gd package.
- Criação de um banco “webacula” para restauração de arquivos e para o 
recurso de “Logbook”.
16.1. Instalação e Configuração:
apt-get install apache2 php5 libapache2-mod-php5 php5-mysql 
php5-gd
E então:
mkdir /var/www/
Entre no site oficial do webacula (http://webacula.sourceforge.net/) faça o 
download e descompacte o arquivo dentro do diretório, depois acesse o site oficial do 
zend (http://framework.zend.com/) baixe a verão mínima do framework e decompacte 
a subpasta “library” do pacote dentro do dentro do seguinte diretório 
“/var/www/webacula/“). Dessa maneira: /var/www/webacula/library/
A árvore de diretórios deve ficar assim:
/var/www/webacula/
 |– application
 | |– controllers
 | |– models
 | `– views
 |– docs
 |– install
 |– html
 178
 |– languages
 `– library
 . |– Other
 . |– MyClass
 . |
 . `– Zend (this is Zend Framework package)
 . |– Acl
 . |– Auth
 . |– Cache
 . |– Config
 . …
Agora vamos criar o banco de dados e tabelas:
/var/www/webacula/install/webacula_mysql_create_database.sh 
passando os parâmetros de usuário e senha do banco (-u root 
-p[senha])
/var/www/webacula/install/webacula_mysql_make_tables.sh 
(passando os parâmetros de usuário e senha do banco (-u root 
-p[senha]
Em seguida
#chown -R www-data. /var/www/webacula (não esquecer o “ponto” 
depois de “www-data”)
Especifique os parâmetros para a conexão do catálogo, e modifique seu idioma 
no arquivo:
#vi /var/www/webacula/application/config.ini
 179
Verifique se as seguintes linhas estão inseridas corretamente:
db.adapter = PDO_MYSQL
db.config.host = localhost
db.config.username = root
db.config.password = <password> (coloque a senha do root do 
banco mysql-server)
db.config.dbname = bacula
procure pela linha (; locale = “en”) descomente ela e coloque para o português 
do Brasil:
locale = “pt_BR”
mais abaixo troque as seguintes linhas e deixe como abaixo:
bacula.sudo = “”
bacula.bconsole = “/sbin/bconsole”
Crie o grupo bacula, caso não esteja criado, e adicione o apache ao mesmo:
#groupadd bacula
#usermod -aG bacula www-data
Então altere as permissões dos seguintes arquivos:
 180
#chown root:bacula /sbin/bconsole
#chmod u=rwx,g=rx,o= /usr/bin/bconsole
#chown root:bacula /etc/bacula/bconsole.conf
#chmod u=rw,g=r,o= /etc/bacula/bconsole.conf
#chmod 0+r /usr/lib/libbac*
Crie uma configuração para o Apache:
#vi /etc/apache2/conf.d/webacula.conf
E insira as seguintes linhas:
Alias /webacula /var/www/webacula/html
<Directory /var/www/webacula/html>
Options FollowSymLinks
AllowOverride All
Order deny,allow
Allow from 127.0.0.1
# Coloque sua rede
Allow from 192.168.0.0/255.255.255.0
AuthType Basic
AuthName “Webacula”
 181
AuthUserFile /etc/apache2/webacula.users
Require valid-user
</Directory>
Depois crie a senha de acesso ao webacula:
#htpasswd -c /etc/apache2/webacula.users bacula
Configure o mod_rewrite:
#a2enmod
e habilite o modulo “rewrite”, digitando “rewrite”.
Saia da console do a2enmod e aumente estes valores no 
/etc/php5/apache2/php.ini:
memory_limit = 128M
max_execution_time = 600
Adicione a seguinte linha (em negrito) no seu /etc/bacula/bacula-dir.conf:
Messages {
Name = Standard
…
catalog = all, !skipped, !saved
por fim reinicie os serviços:
 182
#/etc/init.d/apache2 restart
#/etc/init.d/mysql restart
#/etc/init.d/bacula-director restart
Verifique o funcionamento do mod_rewrite:
#apache2ctl -t -D DUMP_MODULES 2>&1 | grep rewrite
a resposta deve ser algo como:
rewrite_module (shared)
Pronto! Digite o endereço http://ip_do_servidor/webacula para ter acesso.
 183
Capítulo 17
“Backup” de Aplicações Específicas 
com o “Bacula”17.1. "backup" de Máquinas Virtuais
1.“backup” de Máquinas Virtuais “VirtualBox”
Para “backup” dessas máquinas virtuais, recomendo a instalação um cliente 
do “Bacula” em cada, ou seja: trate elas como se fossem máquinas dedicadas 
(físicas).
A cópia integral das máquinas, pode ser feita numa periodicidade menor (ex.: 
semanalmente ou mensalmente) para fins de “disaster recovery”.
Entretanto, não é possível fazer a cópia direta dos arquivos de máquinas (.vdi) 
do VirtualBox. Solução? Faça um clone, através da ferramenta nativa de cópias, que 
deverá ser executada em um script “ClientRunBeforeJob” do Bacula:
VBoxManage clonevdi ~/.VirtualBox/VDI/WindowsXP.vdi 
~/WindowsXP_backup.vdi
No exemplo, ~/.VirtualBox/VDI/“ é a pasta dos arquivos das máquinas, e a 
~/ (home) é a pasta de destino dos clones.
 184
2.“backup” de Máquinas Virtuais “Xen”
Em relação às máquinas virtuais, continuo adepto da estratégia: instalação um 
cliente do “Bacula” em cada uma das máquinas virtuais – ou seja: trate elas como se 
fossem máquinas dedicadas (físicas).
A questão aqui, novamente, reside no “backup” dos arquivos que 
correspondem às máquinas virtuais em si (para fins de disaster recovery), que 
aparentemente não podem ser diretamente “backupeados” com a máquina virtual em 
execução.
Assim, pesquisamos alguns métodos utilizados:
I. Pausar a Máquina Virtual Xen para a cópia dos arquivos9:
A desvantagem desse processo é óbvia: a indisponibilidade temporária da 
máquina virtual. Se isso não é um problema, estes seriam os procedimentos:
a) Pausar o “domU” utilizando o comando “xm pause” (script RunBeforeJob 
do “Bacula”)
b) Sincronizar o “domU” utilizando o comando “xm sysrq” (num segundo 
script “RunBeforeJob”)
c) Faça o “backup” das configurações do Xen e do arquivo correspondentes à 
máquina virtual.
d) Despause o “domU” através do comando “xm unpause”
Este “"backup" completo” da máquina virtual pode ser executado numa 
peridiocidade menor (Ex.: semanalmente ou mensalmente).
II. Criar um Snapshot LVM10:
Parece se tratar do método mais popular entre os administradores de Xen. O 
LVM é utilizado como uma camada intermediária entre a máquina virtual e o disco 
rígido, permitindo a cópia integral da VM com a mesma em produção.
9 Fonte: [http://lists.xensource.com/archives/html/xen-users/2006-10/msg00476.html]
10 Fonte: [http://wiki.sepsoftware.com/wiki/index.php/Online_"backup"_of_virtual_XEN_machines]
 185
Para isso, vários scripts estão na Internet (que devem ser chamados pelo 
“Bacula” com um RunBeforeJob). Exemplos podem ser conseguidos no site: 
http://www.bacula.com.br/?p=219
Você deverá incluir a pasta de geração dos snapshots no “FileSet” do 
“Bacula”, além dos arquivos de configuração do XEN.
Opcionalmente, crie um “RunAfterJob” para limpar (apagar) os snapshots 
criados, economizando espaço em disco.
3."backup" de Máquinas Virtuais do Vmware
Em relação às máquinas virtuais do “VMWare”, surgem duas opções:
I. Utilização da Solução do Fabricante – o VMWare Consolidated "backup"
Este seria o procedimento nativo do VMWare – uma maneira de criar imagem 
das máquinas ou extrair arquivos delas, mesmo que estejam desligadas. Este método, 
requer a integração com uma ferramenta de "backup" – exemplo: o Bacula, para 
executar scripts que coloquem o Vmware Consolidated "backup" para extrair os 
dados das máquinas e depois jogar para o armazenamento.
Foram levantados alguns questionamentos sobre este método:
a) Seria criada uma camada a mais de "backup" para administrar e para 
operar manualmente, no momento do “restore”, gerando maior complexidade;
b) consistiria assim mais um ponto de falha.
c) o fabricante sugere o uso opcional de um servidor proxy (que só funciona no 
Windows), para diminuir a carga de processamento do "backup" consolidado, levando 
a crer que não se trata de um procedimento eficiente;
d) O uso da solução nativa só se justificaria se não fosse fazer "backup" das 
máquinas virtuais inteiras com uma margem de segurança, para a recuperação de 
desastres. No entanto ele mesmo admite que é possível, ainda mais com o Bacula que 
faz "backup" de arquivos abertos:
 186
“Run "backup" clients from the ESX Server 
Service Console, backing up virtual machines in 
their entirety as .dsk and .vmdk files residing in 
the ESX Server host VMFS file system.”
Ele diz aqui, que se mostra possível fazer “backup” dos arquivos .dsk e .vmdk 
(máquinas virtuais) diretamente do servidor hospedeiro das mesmas.
II. Métodos Tradicionais
O método tradicional de “backup” (indicado pela documentação do 
desenvolvedor11) consistiria, mais uma vez, na instalação dos “clientes” do “Bacula” 
(por exemplo) em cada uma das máquinas virtuais – ou seja: seriam tratadas como se 
máquinas dedicadas fossem.
O grande mérito seria a manutenção de um banco de dados único de controle, 
administração, ponto de falha e operação do “backup”. E de forma alguma haveria 
prejuízo à eficiência e integridade dos dados. 
Como mecanismo complementar (útil para a recuperação de desastres rápida, 
quando uma máquina virtual se corrompa), a própria documentação citada sugere 
que você faça “backup” dos arquivos .dsk e .vmdk, como fora citado, isso numa 
periodicidade menor (ex.: semanalmente ou mensalmente), conforme a citação:
É altamente recomendável que o “Director” do “Bacula” seja instalado em 
uma máquina dedicada, obviamente diversa da que hospeda as máquinas virtuais, 
para que um eventual desastre não comprometa simultaneamente os dados originais 
e a ferramenta de cópias de segurança (esta recomendação também é feita no 
supramencionado Guia).
17.2. "backup" de Bancos de dados
As metodologias de "backup" variam bastante de acordo com cada Banco. 
Como exemplo, o PostgreSQL tem uma maneira bem eficiente de cópia (on-line – ou 
11 Guia oficial para "backup" das máquinas virtuais VMware 
[http://www.vmware.com/pdf/vi3_301_201_vm_"backup".pdf]
 187
seja, o banco não pára), muito útil para grandes bases.
Já para o MySQL, o dump é a funcionalidade de "backup" padrão – realizando 
um espelhamento fiel das informações do banco. 
Entretanto, em alguns testes realizados, a simples cópia dos arquivos que 
contém o banco de dados MySQL (utilizando o Bacula em sistema operacional Linux), 
foi suficiente para restauração íntegra do banco (apesar de não ser um procedimento 
recomendável).
O Oracle possui funcionalidade4 parecida com o PostgreSQL, permitindo que 
esteja configurado em modo de arquivamento e que, dessa maneira, seja colocado em 
“modo "backup"” por um script antes do trabalho de "backup", e depois retornar ao 
estado anterior, através de um script pós-trabalho de "backup". É considerado um 
“backup” quente, na medida que o banco de dados continua disponível.
No caso do Microsoft SQL, a maneira encontrada para "backup" (a exemplo do 
MySQL) consiste na realização dos dumps através de scripts executados pelo Bacula 
também no Windows (arquivos .bat). No momento do restore, o Microsoft SQL dispõe 
de uma interface texto e outra gráfica para a reconstituição a partir daquele dump 
gravado.
1. "backup" do Banco Postgresql12
Ao invés do mais popular “dump”, o método abaixo consiste numa melhor 
maneira de fazer o "backup" do Postgresql, principalmente por se tratar de um 
"backup" on-line (ou seja, o banco não para). Muito útil para grandes bases.
Para isso, ative o WAL (write ahead log) do Postgresql. Dentro do 
postgresql.conf, deve haver a seguinte linha:
archive_command = 'cp -i %p /mnt/server/archivedir/%f 
</dev/null'
Logicamente, /mnt/server/archivedir é apena o diretório destino do 
arquivamento, devendoser alterado para um ponto de montagem no qual tenha 
espaço suficiente para armazenar os logs.
12 Fonte: http://www.postgresql.org/docs/8.1/static/"backup"-online.html
 188
Atenção! Teste o comando. Caso o cp -i não funcione, deve realizar uma 
verificação de execução correta no script. Verifique a documentação do Postgresql no 
link mais abaixo.
Então:
Crie no Bacula um RunBeforeJob script que execute na console do Postgres, 
com superusuário do banco:
SELECT pg_start_"backup"('label');
Onde label será um nome que você atribuirá para esta transação de "backup".
Exemplo do script – put_pgsql_bkp_mode.sh:
exec 6>&1
exec > /etc/bacula/status_script.log # grava um log do script 
[records script log]
sudo -u postgres psql<<END
SELECT pg_start_"backup"('bacula');
END
exec 1>&6 6>&-
#"\q"
exit
O "backup" do Bacula deverá então rodar, copiando os arquivos do banco, 
apenas. Nunca deve ser "backup"eado o arquivo do banco em conjunto com o 
"backup" dos logs arquivados (pasta de “archive”, definida acima).
Já no RunAfterJob – e isso é muito importante, deve criar um script que 
 189
execute a seguinte rotina no banco do Postgresql:
SELECT pg_stop_"backup"();
Exemplo do script - exit_pgsql_bkp_mode.sh:
exec 6>&1
exec > /etc/bacula/status_script.log # grava um log do script 
[records script log]
sudo -u postgres psql<<END
SELECT pg_start_"backup"('bacula');
END
exec 1>&6 6>&-
#"\q"
exit
2. "backup" do Banco Mysql
Como já citado, o "backup" de banco Mysql deve ser feito através de dump. 
Exemplo de RunBeforeJob:
mysqldump -u usuario -psenha –all-databases 
/var/bacula/working/dump.sql
A pasta de destino do arquivo .sql pode ser diferente, mas tenha certeza de 
que ela seja “"backup"eada” pelo Bacula – ou seja: esteja inclusa no “FileSet” 
correspondente.
 190
Obs.: não há espaço entre a opção -p e a senha do banco.
3. "backup" de banco Oracle
I. Configure o modo de arquivamento13:
Para que o modo de "backup" funcione adequadamente, necessário configurar 
o banco Oracle no modo de arquivamento de Logs. 
Na console do Oracle (com usuário administrativo - SYSDBA), utilize o 
comando ALTER DATABASE com a cláusula ARCHIEVELOG. Entretanto, todos os 
bancos e instâncias devem ser fechados antes dessa operação.Da seguinte maneira:
1. Desligue a instância do banco de dados:
 SHUTDOWN
2. Faça "backup" do banco.
Antes de mudar para ARCHIVE log, faça uma cópia do seu banco.
3. Configure o logal de armazenamento através do seguinte exemplo de 
comando:
 LOG_ARCHIVE_DEST = '/disk1/arc'
 A pasta /disk1/arc é o local de destino dos logs. 
 4. Comece a nova instância, monte, mas não abra o banco:
 STARTUP MOUNT
 5. Mude o banco para o modo de arquivamento e depois a abra:
 ALTER DATABASE ARCHIVELOG;
 ALTER DATABASE OPEN;
13 http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/archredo.htm#i1006184
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/archredo004.htm
 191
 6. Deligue o banco:
 SHUTDOWN IMMEDIATE
 7. Faça nova cópia de "backup" do seu banco. 
II. Colocando o Oracle em modo "backup"14:
Crie um script (ex.: start-"backup"-mode.sh em /opt/oraappl/scripts), com o 
seguinte conteúdo:
#!/bin/bash
sqlplus /nolog <<EOF
conn sys/managger as sysdba
alter database begin backup;
exit
EOF
Este script deve ser executado antes do “job” de "backup", pelo Bacula 
(ClientRunBeforeJob)
III. Tirando o Oracle do modo "backup":
Crie um script stop-backup-mode.sh, na mesma pasta:
sqlplus /nolog <<EOF
conn sys/managger as sysdba
alter database end backup;
exit
EOF
IV. Execução de Scripts com o Bacula:
Bacula precisa executar os mencionados scripts como usuário do Oracle. Para 
isso, acrescente essas linhas ao arquivo /etc/sudoers da máquina hospedeira do 
14 http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/archredo.htm#i1006184
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/archredo004.htm
 192
Banco Oracle:
Cmnd_Alias "backup"_ORACLE = /bin/su - oracle -c 
/opt/oraappl/scripts/start-"backup"-mode.sh, /bin/su - oracle -c 
/opt/oraappl/scripts/start-"backup"-mode.sh
bacula LOCAL = NOPASSWD: "backup"_ORACLE
 
V. Configuração do Bacula:
Muito provavelmente, seu FileSet deverá conter essas pastas:
FileSet {
 Name = "Linux-Oracle"
 Include {
 Options { signature = SHA1 }
 File = /mnt/snap/var/oradata
 File = /mnt/snap/opt/oraappl
 File = /usr/local/bin/
 File = /var/"backup"/oracle/arch/
 File = /etc/oratab
 }
 }
E seu job deverá chamar os scripts:
Job {
 Name = "oracle-hot"backup""
 Client = oracleserver-fd
 JobDefs = "DefaultJob"
 Schedule = "Oradata-Cycle"
 RunBeforeJob = "sudo /bin/su - oracle -c 
 193
/opt/oraappl/scripts/start-"backup"-mode.sh"
 RunAfterJob = "sudo /bin/su - oracle -c 
/opt/oraappl/scripts/stop-"backup"-mode.sh"
 FileSet = "Linux-Oracle"
 Write Bootstrap = "/var/lib/bacula/oracle-hot"backup".bsr"
}
17.3. Servidores Web
Um cliente Windows do Bacula será capaz de copiar o conteúdo dos arquivos 
do IIS (Internet Information Services) sem nenhuma dificuldade6 – entretanto as 
configurações do servidor web são omitidas. A Microsoft provê o script “iisback.vbs”, 
que é bem documentado na ajuda da Console de Administração do IIS (sendo 
executado, mais uma vez, no RunBeforeJob do Bacula).
No caso do Apache, a simples cópia de suas pastas com o Bacula (que faz 
"backup" de arquivos abertos), seria suficiente para a restauração do serviço.
17.4.Serviços de Email
Ainda que seja possível fazer "backup" da aplicação Microsoft Exchange 
diretamente através de seus arquivos, trata-se de um método incompleto por não 
suportar "backups" diferenciais ou incrementais, além de dificultar a restauração de 
uma única base de dados, por exemplo. 
Esta aplicação organiza seu armazenamento através de “Grupos de Storage”, 
que contém bancos de dados em si. A comunidade disponibiliza um plugin que 
permite o "backup" de todos esses grupos ou bases, podendo ser restauradas 
individualmente.
 194
Em relação ao Expresso, o "backup" com o Bacula também se mostrou viável. 
Trata-se, na verdade de um conjunto de aplicações que precisam ser protegidas: 
banco de dados (no caso o PostgeSQL), Base do LDAP, “Cyrus” e os próprios emails 
da solução. 
1. Restaurando Emails/Mailboxes Individuais no 
Cyrus/Expresso
I. Emails individuais:
Pergunta: Deletei alguns emails por acidente – e preciso restaurá-los a partir 
de um "backup". Utilizamos o Cyrus / Expresso como servidor IMAP e tenho uma 
cópia do diretório /var/spool/imap/. O que fazer?
Resposta: O Cyrus salva os emails no seguinte diretório:
/var/spool/imap/user/<user_name>/
Existe um arquivo para cada mensagem. O nome do arquivo consiste de uma 
série de números, seguidas de um ponto. Para evitar que mensagens sejam 
sobrescritas, é aconselhável criar um diretório adicional para a cópia do "backup".
Use a interface de administração web para criar uma noa pasta, dentro do 
usuário específico (ex.: "backup").
/var/spool/imap/user/<user_name>/"backup"/
(não crie a pasta manualmente no bash – caso contrário o Cyrus irá ignorá-la)
Copie as mensagens do "backup" para o novo diretório. Reinicie a caixa de 
email para que o Cyrus reconheça as novas mensagens:
cyrus@slox:~> reconstruct -r user/<user_name>
ou simplesmente utilize o “reconstruct” sem nenhuma opção, para reiniciar 
 195
todas as mailboxes.
Fonte15: http://www.novell.com/coolsolutions/qna/1748.htmlII. Restauração Mailbox16:
“Restaurar uma caixa de email é trivial. Apenas o restaure para um 
subdiretório dentro da caixa de email primária e execute:
reconstruct -r -f on the mailbox
Para descobrir a caixa restaurada e prover meios de recuperar as mensagens 
desejadas.
2. "backup" do Zimbra
I. Script antes do “job”:
Mude as variáveis quando necessárias. A lógica é simples: parada de serviços, 
cópia do conteúdo do Zimbra dentro de /opt/ para uma localidade alternativa (no caso 
/var/"backups"), reinício dos serviços do Zimbra.
/usr/local/bin/zimbra_pre_back.sh (deve ser chamado no 
ClientRunBeforeJob do Bacula)
#!/bin/sh
my_user=zimbra
stop_zimbra=zmcontrol
my_prefix="/opt/zimbra/bin/"
my_stop_option=stop
my_start_option=start
my_date=`date +%d-%m-%Y`
my_logdir="/opt/zimbra/"backup"/"
15 Outras documentações consultadas: 
http://wiki.kolab.org/index.php/"backups"_for_kolab2#IMAP_store_recovery_.28cyrus.29
16 Fonte 1: http://lists.andrew.cmu.edu/pipermail/info-cyrus/2005-September/019620.html
Fonte 2: http://oreilly.com/catalog/mimap/chapter/ch09.html
 196
my_logfile=zm_"backup"-$my_date.log
if [ -x $my_prefix$stop_zimbra ]; then
 su - $my_user -c "$my_prefix$stop_zimbra 
$my_stop_option" \
 2>&1 >>$my_logdir$my_logfile && echo -e "*****\tSHUTDOWN 
COMPLETE\t*****" \
 >> $my_logdir$my_logfile && echo -e "*****\t`date +%H:
%M:%S`\t\t\t*****" \
 >> $my_logdir$my_logfile
fi
if [ -e $my_logdir/zm_"backup"-$my_date.log ]; then
 echo "" && \
 cp -r /opt /var/"backups" 2>&1 >>$my_logdir$my_logfile 
&& \
 echo -e "*****\tCOPY COMPLETE\t\t*****" 
>>$my_logdir$my_logfile && \
 echo -e "*****\t`date +%H:%M:%S`\t\t\t*****" >> 
$my_logdir$my_logfile
fi
if [ -x $my_prefix$stop_zimbra ]; then
 su - $my_user -c "$my_prefix$stop_zimbra $my_start_option" \
 2>&1 >>$my_logdir$my_logfile && echo -e "*****\tSTARTUP 
COMPLETE\t*****" \
 >> $my_logdir$my_logfile && echo -e "*****\t`date +%H:
 197
%M:%S`\t\t\t*****" \
 >> $my_logdir$my_logfile
 echo "" >> $my_logdir$my_logfile
 echo ""backup" completed on: $my_date at: `date +%H:%M:
%S`" >> $my_logdir$my_logfile
fi
exit 0
/usr/local/bin/zimbra_post_back.sh (deve ser chamado no ClientRunAfterJob 
do Bacula)
#!/bin/sh
my_date=`date +%d-%m-%Y`
my_logdir="/opt/zimbra/"backup"/"
my_logfile=zm_"backup"-$my_date.log
error=ERROR
if [ -e $my_logdir/zm_"backup"-$my_date.log ]; then
 echo "***** `date +%H:%M:%S` *****" >> 
$my_logdir$my_logfile && \
 rm -rf /var/"backups"/opt 2>&1 >>$my_logdir$my_logfile 
&& \
 echo "*****Delete of Data complete *****" 
>>$my_logdir$my_logfile && \
 echo "***** `date +%H:%M:%S` *****" >> 
$my_logdir$my_logfile
 198
else
 echo "No previous log file found for $my_date" >> 
$my_logdir$error$my_logfile
 exit 2
fi
echo ""backup" to tape completed on: $my_date at: `date +%H:%M:
%S`" >> $my_logdir$my_logfile
exit 0
17.5. Serviços de Diretório
Para configurações mais simples do OpenLDAP, utilizando apenas um backend, 
apenas o comando slapcat seria suficiente para criar um dump completo para 
"backup". Para cenários mais elaborados (com múltiplos backends), o slapcat 
precisará do DN (distinguish name) de cada um dos backends locais – o que também 
pode ser realizado através de script antes do job de "backup".
Atenção! Seu slapd deve estar PARADO durante a execução do 
slapcat (ou ao menos em modo de leitura-escrita), sob o risco de 
comprometer a consistência do banco.
Outro popular aplicativo da área seria o “Serviço de Diretório 389”, que 
consiste no novo nome do “Fedora Directory Server” cujo o “Red Hat Directory 
Server” seria uma versão certificada pela RedHat, embora os dois compartilhem do 
mesmo código. A metodologia de "backup" consiste também na execução de script e 
produção de dump, através de ferramenta fornecida pela própria aplicação. 
 199
Capítulo 18
“Bacula Disaster Recovery” no Linux
18.1. “Bare Metal Recovery” usando um Disco de 
Emergência do “Bacula” 
Esta seção contempla estações que estejam somente, executando o “bacula-
fd”.
 200
Uma restauração "Bare Metal" ocorre quando se tem apenas um disco rígido 
vazio na mão, no qual é necessário restaurar todos os dados da máquina. Entretanto, 
estes procedimentos podem ser utilizados no caso de perda de alguma pasta 
essencial do sistema, etc.
Para isso, o “Bacula” traz a possibilidade da criação de discos CDROM, que 
permitam a rápida inicialização do equipamento sem dados no HD e restauração do 
mesmo.
Objetivos do Disco de Emergência do “Bacula”: 
• Não é um disco universal de emergência. 
• Objetiva restaurar um ambiente único, na qual haja um cliente de "backup" 
“Bacula”.
• Capturar o estado atual dos discos rígidos do sistema, para que ele seja 
fácilmente restaurado através de “scripts” pré configurados. 
• Facilidade de criação. Na maioria dos casos, basta digitar make all no diretório 
rescue/linux/cdrom directory, e criar o CD com a imagem ISO criada. 
Uma das vantagens deste CD, é que contem uma cópia inicializável de seu 
sistema. 
Este tipo de restauração, necessita dos seguintes items: 
• O CDROM de emergência do Bacula.
• Um “"backup" full” de seu cliente “Bacula”, no mínimo. 
• O sistema que hospeda o “Bacula Director” funcional. 
Diretórios
Para construir o CDROM de Emrgência “Bacula”, é necessário ter uma cópia 
dos arquivos de resgate (rescue). Estes arquivos são distribuídos no “site” oficial do 
“Bacula”, no formato bacula-rescue-xx.yy.zz.tar.gz. Entretanto, a maneira mais fácil 
de fazê-lo, é através do arquivo “.rpm” (/etc/bacula/rescue) .
 201
Se optar pelo “.tar.gz”, necessário usar o “configure” antes de criar o arquivo 
do CD.
Os “scripts” necessários estarão dentro do subdiretório linux/cdrom do código 
fonte. Se instalado por rpm, o bacula-rescue terá os “scripts” dentro de 
/etc/bacula/rescue/linux/cdrom. 
Criando um CDROM Bacula Rescue
Deve ser criado o CD, toda vez que ocorrer uma grande atualização do 
“Bacula” ou um re-particionamento de seu sistema. 
Para construir o CDROM a partir do fonte, você deve primeiro pré configurar 
o código fonte da instalação de um cliente “Bacula”: 
cd <bacula-source>
./configure \
 --prefix=/usr \
 --sbindir=/usr/sbin \
 --sysconfdir=/etc/bacula \
 --with-scriptdir=/etc/bacula \
 --enable-smartalloc \
 --enable-client-only \
 --enable-static-fd
 --disable-libtools
make
Ainda, para copiar o src/filed/static-bacula-fd, e uma cópia válida de seu 
bacula-fd.conf atual, você deverá proceder: 
cd <bacula-rescue>
./configure \
--with-static-fd=<diretório-contendo-static-bacula-fd*> \
--with-bacula-scripts=/etc/bacula
 202
cd linux/cdrom
su 
(enter root password)
make
* src/filed/static-bacula-fd
Este foi o procedimento para a criação do CD a partir do bacula-rescue-
xx.yy.zz.tar.gz.
De maneira mais prática, é possível que os “scripts” de emergência criem, 
automaticamente, um “File daemon” estático: 
cd <bacula-rescue>
./configure \
--with-bacula=<bacula-source-directory>
cd linux/cdrom
su 
(enter root password)
make
Em caso de kernels múltiplos no sistema, pode ser especificado um em 
específico: 
cd <bacula-rescue>
./configure \
--with-kernel=<kernel-version> \
...
É possível, também, indicar qual o dispositivo de CDROM que será utilizado 
para a gravação do CD: 
cd <bacula-rescue>
 203
./configure \
--with-dev=<device> \
...Para a instalação via .rpm do “bacula-rescue”, o arquivo “bacula-fd” já estará 
em /etc/bacula/rescue/linux/cdrom/bin/, junto com o link simbólico para seu 
arquivo /etc/bacula/bacula-fd.conf. Isto é essencial para o bom funcionamento do 
“restore”.
cd /etc/bacula/rescue/linux/cdrom
su (become root)
make
Neste ponto, você já terá realizado o seguinte: 
• Uma cópia do seu kernel e arquivos essenciais. 
• Copiado vários arquivos binários do sistema e bibliotecas necessárias..
• Feito uma versão “linkada” do seu “File daemon” e copiado para a área de 
construção do CD. 
• Feito uma imagem do CD denominada bootcd.iso 
Então, chegou a hora de gravar a imagem criada no CD:
make burn
Se não funcionar, tente este passo para detectar seu gravador de cd e 
configurar o arquivo Makefile corretamente: 
make scan
 204
Restaurando o sistema cliente: 
Procedimentos:
1. Inicialize seu servidor de emergência “Bacula”.
2. Inicialize a rede local. 
3. Re-particione o HD como antigamente. 
4. Re-formate as partições.
5. Restaure o “Bacula File daemon” (verssão static) 
6. Faça um restore de todos os arquivos através do “Bacula” 
7. Re-instale o gerenciador de “boot”.
8. Reinicie o equipamento.
Agora os detalhes... 
1.Inicializando o CDROM
Quando o CDROM inicializa, este é o modelo de tela que se apresenta: 
Welcome to the Bacula Rescue Disk 2.0.0
To proceed, press the <ENTER> key or type "linux <runlevel>"
 
linux 1 -> shell
linux 2 -> login (default if ENTER pressed)
linux 3 -> network started and login (network not working 
yet)
linux debug -> print debug during boot then login
No caso, vamos simplesmente presumir que foi pressionada a tecla ENTER.
Uma vez inicializado, aparecerá algo assim: 
 205
bash-3.1#
Você estará no diretório root de seu sistema. 
A parte de emergência do cd estará no diretório: /bacula-hostname
2.Inicializando a rede: 
Neste ponto, a rede deve ser inicializada. Existe um “script” que facilita este 
processo: 
cd /bacula-hostname
./start_network
Você pode testá-la efetuando um “ping” para outra estação. 
3.Particionamento dos discos (se necessário): 
Assumindo de seu disco quebrou e precise de reparticionamento, prossiga: 
./partition.hda
Se forem vários discos, faça o mesmo para cada um deles. Para discos SCSI, o 
“script” será nomeado: partition.sda. Se o “script” retornar que o disco está em uso, 
utilize o comando df e “umount” até que não tenha mais o disco montado. 
Se o “script” não funcionar de nenhuma maneira, utilize a informação do 
arquivo partition.hda e reparticione automaticamente utilizando o fdisk. 
4.Formatação dos discos (se necessária): 
Para cada disco:
./format.hda
5.Montagem dos discos: 
./mount_drives
 206
df
O comando df informará quais drives estão montados. A repetição do “script” 
pode ser necessária. 
6.Restaurando e Inicializando o File Daemon: 
Verifique se seus arquivos bacula-fd and bacula-fd.conf estão dentro do 
diretório /bacula-hostname/bin. 
Mova ambos os arquivos para o diretório /mnt/disk/tmp, e execute o seguinte 
comando: 
chroot /mnt/disk /tmp/bacula-fd -c /tmp/bacula-fd.conf
Se o “Bacula” não inicializar, corrija o problema e tente novamente.
Para testar o cliente, utilize o comando “status” através do “bconsole” ligado 
ao diretor Bacula. 
7.“Restore” dos arquivos: 
No “Director”, execute o “job” de restore dos arquivos necessários 
(geralmente todos). Você deverá restaurar os arquivos na raiz (/). 
8.Finalizando: 
Neste ponto, após o “restore” com êxito dos arquivos, necessário 
reestabelecer o gerenciador de boot. Para o lilo: 
./run_lilo
Ou se utilizar o GRUB: 
./run_grub
No caso do GRUB, podem ser retornados alguns erros. Neste caso, os 
comandos deste “script” devem ser executados de maneira automatizada no “shell” 
 207
normal. 
Este comando pode ser tentado:
/sbin/grub-install --root-directory=/mnt/disk /dev/hda
No caso, /dev/hda deve ser substituído pelo dispositivo de boot. Caso não 
saiba, o “script” run_grub irá dizer.
No caso do GRUB não conseguir escrever os dados, fornecendo este erro: 
/dev/hdx does not have any corresponding BIOS drive.
A solução é assegurar que os discos estão montados: 
chroot /mnt/disk
mount /dev/pts
Edite o arquivo /boot/grub/grub.conf e descomente a linha:
#boot=/dev/hda
Então, entre com os seguintes comandos: 
grub --batch --device-map=/boot/grub/device.map \
 --config-file=/boot/grub/grub.conf --no-floppy
root (hd0,0)
setup (hd0)
quit
Ele deve então indicar que escreveu corretamente no MBR (“master 
boot record”). 
 208
9.Reboot: 
Primeiro, desmonte todos os discos rígidos. Então, de quit e ctrl-d até 
retornar ao menu do CD. Reinicie o equipamento.
Capítulo 19
Bacula no “Windows”” 
 209
Seguem os procedimentos para instalação do cliente para Windows. A mesma 
foi testada no Win95, Win98, WinMe, WinNT, e Win2000. 
Uma vez instalado, o “Bacula” roda como um “serviço do Windows”. Isso 
significa que ele é automaticamente inicializado, mesmo que nenhum usuário se 
autentique. 
19.1. Instalando um Servidor Bacula no “Windows”
O “download” do instalador “Bacula” para Windows, pode ser feito a partir do 
próprio site oficial da ferramenta (www.bacula.org).
Acesse o site: [http://www.bacula.org/en/?page=downloads] e baixe o 
arquivo executável (ex.: winbacula-3.0.3.exe), que encontra-se na tabela 
(Win32_64). Observe que existem arquivos para Windows 32 ou 64 bits.
• Então, como administrador, inicie o programa de instalação: winbacula-
3.x.x.exe 
• Uma vez lançado, o “wizard” irá guiar pelas demais etapas de instalação. 
*Neste momento, se desejar utilizar um banco-de-dados que não seja o 
SQLite, faça o “download” do mesmo e o instale, antes de Instalar o “Bacula”. 
Pare este manual, adotamos o SQLite por não requerer nenhum 
procedimento adicional de instalação.
a) Dê um duplo-clique no arquivo baixado. 
b) Inciada a instalação, clique no botão Next e, daí, aceite os termos da 
licença.
 210
c) Escolha o tipo de instalação “Automática” na tela em que pode escolher 
entre “Automatic” ou “Custom” (customizada). 
d) Na tela de escolha dos módulos marque TODOS, na medida que estaremos 
instalando um servidor de “backup” (director), ao contrário do exemplo mostrado 
abaixo que só instalaria um cliente do “Bacula”: 
e) Na tela seguinte você poderá:
I – Definir uma senha para seu “Director (neste caso, a senha que os consoles 
terão em seus arquivos de configuração para se conectar ao Director) ou você pode 
deixar que seja criada uma senha randômica gerada pelo instalador.
II – Configurar um servidor de email para envio das mensagens de “backup” 
do “Bacula” – OPCIONAL – pode ser configurado posteriormente no bacula-
dir.conf.
III – Digitar uma lista de endereços, entre vírgulas, para receber os citados 
“emails” – OPICIONAL – idem.
IV – Escolher um dos bancos-de-dados suportados pelo “Bacula”. Como já dito, 
escolhemos o “SQLite”.
 
 211
f) Adiante, deverá aparecer a tela de instalação concluída. Sucesso!
19.2. Botando para Funcionar
a) Através do Windows Explorer, acesse a pasta: C:\Arquivos de 
programas\Bacula\bin e execute (duplo-clique) os seguintes arquivos, exatamente 
nesta ordem (o primeiro cria o banco-de-dados do “Bacula”, o segundo as tabelas, o 
terceiro o usuário bacula no banco):
 create_database.cmd
 make_tables.cmd
 grant_privileges.cmd
b) Vá em Painel de Controle > Desempenho e Manutenção > Ferramentas 
administrativas > Serviços. Irá aparecer umatela parecida com esta:
 
c) Localize o serviço Bacula Director Service, clique com o botão-direito, 
clique em iniciar.
d) Pronto! Botão Inciar > Todos os Programas > “Bacula” > bconsole e você já 
estará na dentro do “Bacula Director” (servidor), através da console de texto.
e) A bwx-console também deverá estar funcionando – que consiste num misto 
entre interface texto e gráfica.
19.3. Configurando o “Bacula”
Para alterar os arquivos “.conf”, basta acessar a pasta do “Bacula” em: “Menu 
Iniciar” / “Programas” / “Bacula” / “Configuration” .
Depois de configurado, reinicie o serviço do “Bacula” para que as alterações 
 212
tenham efeito (botão direito em Meu Computador, Gerenciar, Serviços).
A configuração do “Bacula” para “Windows” é bem semelhante a do “Bacula” 
para “Linux”. Obviamente, algumas configurações padrões (ex.: pastas de instalação, 
armazenamento de “logs”, etc.) são diferentes.
O conselho que fica aqui é sempre manter seus sistema funcionando – ou seja: 
a cada modificação que for feita, reinicie os “daemons” para aplicar as alterações e 
verificar se o “Bacula” aceita a nova configuração – ou seja, não retorna erro.
Uma boa maneira de verificar erros de configuração é através da linha de 
comando (cmd) do Windows, na qual pode se visualizar a saída (erro). Você pode 
inciar os serviços do “Bacula” através dos seguintes comandos (sempre nesta ordem):
File-daemon (cliente): “C:\Arquivos de programas\Bacula\bin\bacula-fd.exe” 
/service -c “C:\Documents and Settings\All Users\Dados de aplicativos\Bacula\bacula-
fd.conf”
Storage-daemon (armazenamento): “C:\Arquivos de 
programas\Bacula\bin\bacula-fd.exe” /service -c “C:\Documents and Settings\All 
Users\Dados de aplicativos\Bacula\bacula-fd.conf”
Director: “C:\Arquivos de programas\Bacula\bin\bacula-dir.exe” /service -c 
“C:\Documents and Settings\All Users\Dados de aplicativos\Bacula\bacula-dir.conf”
Agendamento e “Pools”:
Você deve provavelmente querer alterar o agendamento padrão (contido em 
bacula-dir.conf), para um agendamento convencional (ex.: no padrão GFS, criando 
também novas “pools”). Para fazer alterações nos .conf, acesse: Botão Iniciar > Todos 
os Programas > Bacula > Configuration. Para um exemplo de agendamento, clique 
aqui.
Storage:
No bacula-sd.conf existem diversos exemplos comentados de dispositivos de 
armazenamento. Por padrão, o “Bacula” vem configurado com um “dispositivo de 
armazenamento para disco”, em C:\tmp. Você deve alterar este caminho dentro do 
mesmo arquivo se quiser utilizar o HD para fins de “backup” – no final das contas o 
 213
c:\tmp é uma pasta volátil.
Para dispostivos SCSI, o “Bacula” traz um mini-aplicativo em Botão Iniciar > 
Todos os Programas > Bacula > Configuration > List Devices, que lhe fornecerá o 
nome do Dispositivo para preenchimento no bacula-sd.conf (”Archive Device”)
19.4. Operando o “Bacula”
Depois de ter feito as mencionadas primeiras configurações (sempre 
reiniciando os “daemons”), seu “Bacula” deve estar pronto para os primeiros 
“backups”.
Primeiramente você deve usar o comando “label” para criar novos volumes (e 
para que seja possível a realização do “backup”), através do bconsole ou do 
wxconsole (ambos acessíveis através do Menu Iniciar > todos os Programas > 
“Bacula”).
Depois de criados alguns volumes, você pode submeter um “backup” avulso 
através do comando “run”, de maneira a testar o seu sistema.
Não esqueça de escolher uma “pool” na qual existam volumes que possam ser 
gravados (para verificar, comando: “list media”). Caso contrário, seu “backup” ficará 
parado – sem nenhum volume para gravar.
Observe que, o ícone aparecerá no “system tray” ; 
Quando há "backup" do cliente sendo feito, a core do ícone fica verde , se 
houver algum erro, as luzes ficam vermelhas . 
 214
19.5. Clientes “Windows”
A configuração dos clientes “Windows” se mostra praticamente identica a de 
clientes Linux. Para acessá-la: Menu Iniciar > todos os Programas > Bacula > 
Arquivos de Configuração (não esquecer de reiniciar o serviço bacula-fd, no 
Gerenciador de Serviços, sempre que houver alguma alteração no .conf).
Para a conectar o novo Cliente “Windows” ao Director, basta acrescentar as 
informações do cliente no bacula-dir.conf de seu servidor Bacula.
Para o "backup" deste sistema operacional, o comando abaixo se mostra 
bastante recomendável (deve estar inserido em um script .bat):
ntbackup backup systemstate /F c:\systemstate.bkf
Ele deve ser executado sempre antes do "backup" de cada estação Windows, 
através da opção:
ClientRunBeforeJob:
...no respectivo "Job", no "bacula-dir.conf".
Este comando, irá salvar algumas informações importantes (registro, 
arquivos abertos, etc.), apesar de que nas versões mais novas do “Windows” 
(algumas do 2000, em diante), o Bacula já realiza cópia de arquivos abertos.
Para finalizar, certifique-se de que o arquivo gerado (systemstate.bkf) seja 
gravado junto com o "backup" dos dados.
19.6. Modificações no Servidor Específicas para os 
Clientes Windows
Além da adição de um novo recurso “Client” {…} e “Job” {…}, um novo 
FileSet deve ser criado para as estações “Windows”. Exemplo17:
17 http://www.bacula.org/5.0.x-manuals/en/main/main/Configuring_Director.html 
 215
FileSet {
 Name = "Windows 2000"
 Enable VSS = Yes # habilita a cópia de arquivos abertos.
 Include {
 Options {
 signature = MD5
 Exclude = yes # Indicaremos, primeiramente, arquivos que não 
serão copiados no “backup” 
 IgnoreCase = yes 
 # “Exclude” do cache dos programas da Mozilla 
 WildDir = "[A-Z]:/Documents and Settings/*/Application 
Data/*/Profiles/*/*/Cache"
 WildDir = "[A-Z]:/Documents and Settings/*/Application 
Data/*/Profiles/*/*/Cache.Trash"
 WildDir = "[A-Z]:/Documents and Settings/*/Application
Data/*/Profiles/*/*/ImapMail"
 # “Exclude” de registros do usuário (sempre em uso):
 WildFile = "[A-Z]:/Documents and Settings/*/Local 
Settings/Application
Data/Microsoft/Windows/usrclass.*"
 WildFile = "[A-Z]:/Documents and Settings/*/ntuser.*"
 # Excluindo do “backup” Pequenos arquivos inúteis.
 WildDir = "[A-Z]:/Documents and Settings/*/Cookies"
 WildDir = "[A-Z]:/Documents and Settings/*/Recent"
 WildDir = "[A-Z]:/Documents and Settings/*/Local 
Settings/History"
 216
 WildDir = "[A-Z]:/Documents and Settings/*/Local 
Settings/Temp"
 WildDir = "[A-Z]:/Documents and Settings/*/Local 
Settings/Temporary
Internet Files"
# Sempre em uso pelo sistema e impossíveis de ser “backupeados”
 WildFile = "[A-Z]:/Documents and Settings/All Users/Application
Data/Microsoft/Network/Downloader/qmgr[01].dat"
 # Arquivos do “Windows” que queremos ignorar:
 WildFile = "[A-Z]:/WINNT/security/logs/scepol.log"
 WildDir = "[A-Z]:/WINNT/system32/config"
 WildDir = "[A-Z]:/WINNT/msdownld.tmp"
 WildDir = "[A-Z]:/WINNT/Internet Logs"
 WildDir = "[A-Z]:/WINNT/$Nt*Uninstall*"
 WildDir = "[A-Z]:/WINNT/sysvol"
 WildFile = "[A-Z]:/WINNT/cluster/CLUSDB"
 WildFile = "[A-Z]:/WINNT/cluster/CLUSDB.LOG"
 WildFile = "[A-Z]:/WINNT/NTDS/edb.log"
 WildFile = "[A-Z]:/WINNT/NTDS/ntds.dit"
 WildFile = "[A-Z]:/WINNT/NTDS/temp.edb"
 WildFile = "[A-Z]:/WINNT/ntfrs/jet/log/edb.log"
 WildFile = "[A-Z]:/WINNT/ntfrs/jet/ntfrs.jdb"
 WildFile = "[A-Z]:/WINNT/ntfrs/jet/temp/tmp.edb"
 WildFile = "[A-Z]:/WINNT/system32/CPL.CFG"
 WildFile = "[A-Z]:/WINNT/system32/dhcp/dhcp.mdb"
 WildFile = "[A-Z]:/WINNT/system32/dhcp/j50.log"
 217
 WildFile = "[A-Z]:/WINNT/system32/dhcp/tmp.edb"
 WildFile = "[A-Z]:/WINNT/system32/LServer/edb.log"
 WildFile = "[A-Z]:/WINNT/system32/LServer/TLSLic.edb"WildFile = "[A-Z]:/WINNT/system32/LServer/tmp.edb"
 WildFile = "[A-Z]:/WINNT/system32/wins/j50.log"
 WildFile = "[A-Z]:/WINNT/system32/wins/wins.mdb"
 WildFile = "[A-Z]:/WINNT/system32/wins/winstmp.mdb"
 # Arquivos temporários:
 WildDir = "[A-Z]:/WINNT/Temp"
 WildDir = "[A-Z]:/temp"
 WildFile = "*.tmp"
 WildDir = "[A-Z]:/tmp"
 WildDir = "[A-Z]:/var/tmp"
 # lixeiras:
 WildDir = "[A-Z]:/RECYCLER"
 # Arquivos de “Swap” 
 WildFile = "[A-Z]:/pagefile.sys"
 }
 # Drives Incluídos no Backup (recursivamente):
 File = "C:/"
 File = "D:/"
 }
}
 218
19.7. VSS Shadow
Trata-se do serviço do Windows responsável por permitir a cópia de arquivos 
abertos no sistema Operacional Windows – portanto, sempre é recomendável sua 
ativação pelo “Bacula”.1
Assim, todos os “FileSet” de clientes “Windows”, devem possuir a opção:
Enable VSS = yes
...No recurso “FileSet”, como demonstrado no .conf acima.
Em todos os “jobs” com o VSS ativado, haverá uma mensagem informando sua 
atuação.
Obs.: O uso do VSS não elimina a necessidade de backup do systemstate.
19.8. Disaster Recovery no Windows
Versão Longa
Aconteceu um desastre! E você tem um HD em branco (“bare metal recovery”) 
para restaurar seu sistema.
1. Instale seu sistema operacional a partir do CD (ou DVD).
2. Instale e configure o bacula-fd (cliente).
3. Faça o “restore” completo dos arquivos, através do Bacula.
4. Restaure o "systemstate.bkf", com o nt"backup".
Pronto! Seu sistema deverá estar funcionando normalmente.
 219
Versão Curta
1. Utilize uma espécie de LiveCD do Windows, que você necessariamente 
tenha produzido anteriormente, que pode ser feita através do software livre BartPE.
2. Faça o restore completo dos arquivos, através do Bacula (ainda, existe um 
plugin do BartPE para facilitar este processo
3. Restaure o "systemstate.bkf", com o nt"backup".
 220
REFERÊNCIAS 
BIBLIOGRÁFICAS
Capítulo 19 Bacula no “Windows”” - 221
E. L. Heiberger, Karsten Koop, Dorian J. Cougias. The "backup" Book. Network Frontiers, 2003.
T. C. Araújo. Análise comparativa entre o BRF e outros sistemas para gerenciamento de "backup" 
livres.
A. Oliva, C. Taurion, C. Anderson, J. Sena, M. Ferreira, P. Michelazzo, P. Mizukami, P. Rezende, R. 
Queiroz. A Revolução do Software Livre. Comunidade Sol de Software Livre. 2009.
E. Araújo. Livro Entendendo os Conceitos de "backup". 2008
Gestão de Produção do SERPRO. Levantamento da Estrutura de "backup" do Serpro. Novembro / 
2008.
Centro de Especialização de Segurança do SERPRO. Política de "backup" do SERPRO Versão 1.2. 
Julho / 2006.
SERPRO. Missão e Objetivos Organizacionais do SERPRO
SERPRO. Estrutura Organizacional do Serviço Federal de Processamento de Dados 
TANENBAUM, A. Redes de Computadores. Editora Campos.
RIBEIRO, U. Certificação Linux. Editora Excel.
MINASI, M. Dominando o Windows 2000 Server, Editora Makron.
FITZGERALD, B. Hissam, S. A. Lakhani, K. R. Perspectives on Free and Open Source Software. Editora 
do “MIT”. 2005.
FELNER, M. Weichinger, S. Linux Magazine. Linux New Media. Edição nº 54 – Reportagem: “dados em 
Risco”.p. 53 – 60.
Capítulo 19 Bacula no “Windows”” - 222
COMUNIDADE. “Wikipedia – A Enciclopdia Livre.” Disponível em: http://pt.wikipedia.org/ 
Acesso em 17 de janeiro de 2010.
GUISE, P. "backup" & Recovery: Inexpensive "backup" Solutions for Open Systems. O'Reilly. 2007.
GUISE, P. "backup" & Recovery: A Corporate Insurance Policy. CRC Press. 2007.
CURTIS P. Using SANs and NAS: Help for Storage Administration. O'Reilly. 2002.
LITTLE, D. B., CHAPA,D. A. Implementing "backup" and Recovery. Wiley. 2003.
FAUSTINI, R. Segurança é Investimento? Disponível em: 
http://www.faustiniconsulting.com/artigo10.htm Acesso: 28 de janeiro de 2010.
VERAS, M. ITIL - Gerenciamento da Capacidade. Disponível em: 
http://infraestruturadati10.blogspot.com/2008/12/gerenciamento-da-capacidade.html 
Acesso: 26 de agosto de 2009.
MUHAMMAD, H. H., JEFFMAN, R. G. Portabilidade e flexibilidade em software livre: a experiência 
do GoboLinux . Disponível em:
http://www.gobolinux.org/doc/wsl2003/portabilidade_wsl2003.pdf Acesso: 15 de outubro 
de 2009.
Governo Brasileiro. O que é Interoperabilidade?. Disponível em: 
https://www.governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-de-
interoperabilidade/o-que-e-interoperabilidade Acesso: 01 de novembro de 2009.
COMUNIDADE. “dd man pages”. Disponível em: http://linux.die.net/man/1/dd Acesso: 11 
dezembro.
MEFFE, Corinto. Computerworld: O Software Público e a economia dos bens intangíveis. Disponível 
em: http://softwarelivre.org/portal/colunistas-do-psl-brasil/o-software-publico-e-a-
economia-dos-bens-intangiveis Acesso: 05 de maio de 2008.
Capítulo 19 Bacula no “Windows”” - 223
HASS, J. 1 Million Downloads of Bacula. Disponível em: http://linux.about.com/b/2010/01/27/1-
million-downloads-of-bacula.htm Acesso: 20 de agosto de 2009.
SIBBAD, K. LANGUILE, D. Bacula Systems. Disponível em: http://www.baculasystems.com/ 
Acesso: 18 de dezembro de 2009.
Mitchell, D. Computer Associates ARCserve "backup" 12.5. Disponível em: 
http://www.pcpro.co.uk/reviews/software/253609/computer-associates-
arcserve-"backup"-12-5 Acesso: 13 de agosto de 2009.
FARIA, H. M. “Cases” de Sucesso com o “Bacula” (Bacula “cases”). Disponível em: 
http://www.bacula.com.br/?p=75 Acesso: 12 de julho de 2009.
SIBBAD, K. Testemonial. Disponível em: http://www.bacula.org/en/?
page=testimonial&offset=5&limit=5 Acesso: 19 de agosto de 2009.
VMWARE. VMware Consolidated "backup" 1.0.3 Release Notes. Disponível em: 
http://www.vmware.com/support/vi3/doc/releasenotes_vcb103.html Acesso: 29 de agosto 
de 2009.
BACULA DOKUWIKI. Application Specific "backups":Oracle. Disponível 
em:http://wiki.bacula.org/doku.php?id=application_specific_"backups":oracle Acesso: 29 
de agosto de 2009.
STACKOVERFLOW. What is a simple command line program or script to "backup" SQL server 
databases? Disponível em: http://stackoverflow.com/questions/122690/what-is-a-simple-
command-line-program-or-script-to-"backup"-sql-server-databases Acesso: 29 de agosto de 
2009.
COMUNIDADE ZIMBRA. Bacula pre/post cold "backup" scripts. Disponível em: 
http://wiki.zimbra.com/index.php?title=Bacula_pre/post_cold_"backup"_scripts Acesso: 
29 de agosto de 2009.
Capítulo 19 Bacula no “Windows”” - 224
COMUNIDADE EXPRESSO. Rotina de "backup". Disponível em: 
http://www.expressolivre.org/html/expressolivre/downloads/documents/rotinade"back
up".pdf 
Acesso: 29 de agosto de 2009.
CAMÕES, T. Análise Comparativa entre o BRF e Métodos Tradicionais para o Gerenciamento de 
"backups". UFBA, 2007.
SINEMA. 80% das empresas no futuro usarão software livre. Disponível em: 
http://sisnema.com.br/Materias/idmat018350.htm Acesso: 28 de agosto de 2006.
MEFFE, C. O software público e suas qualidades extrínsecas. Disponível em: 
http://computerworld.uol.com.br/negocios/corinto_meffe/idgcoluna.2010-01-
29.0296050978/ Acesso: 29 de agosto de 2009.
PETRELEY, N. Security Report: Windows vs Linux. Disponível em: 
http://www.theregister.co.uk/2004/10/22/security_report_windows_vs_linux/ Acesso :28 
de agosto de 2009.
BREENES, B. Zombie machines used in 'brutal' SSH attacks. Disponível em: 
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1094140,00.htm
l Acesso: 13 de julho de 2009.
TAPSCOTT, D., WILLIAMS, D. A. Wikinomics: How Mass Collaboration Changes Everything . 2007.
AZENHA, L. C. MADDOG: O BRASIL É UMA ESTRELABRILHANTE DO SOFTWARE LIVRE". 
Disponível em: http://www.viomundo.com.br/voce-escreve/maddog-o-brasil-e-uma-
estrela-brilhante-do-software-livre/ Acesso: 29 de agosto de 2009.
A. OLIVA, C. TAURION, C. ANDERSON, J. SENA, M. FERREIRA, P. MICHELAZZO, P. REZENDE, P. 
MIZUKAMI, R. QUEIROZ, T. MELO.. A Revolução do Software Livre. 2009. Comunidade Sol.
E. ARAÚJO. Entendendo os Conceitos de Backup. 2008
Capítulo 19 Bacula no “Windows”” - 225
Anexo I
Códigos de “status” do “Bacula”18 
Código do Nível de 
Backup Significado
F “backup” completo (“full”) 
I “backup” incremental
D “backup” diferencial
C Verificação do catálogo
V Verificação do “init db” 
O Verificação de Volume para Catálogo 
d Verificação de Disco para Catálogo
A Verificação de dados no volume
B “job” de base 
Restore ou “job” 
administrativo
18 http://wiki.bacula.org/doku.php?id=faq#what_do_all_those_job_status_codes_mean 
Capítulo 19 Bacula no “Windows”” - 226
Código do Tipo 
de Backup Significado
B “Backup” 
M “Job” anterior foi migrado
V Verificação (Verify) 
R “Restore” 
c “Console” 
C “Copy” 
I Sistema Interno de Arquivos
D “Job” administrativo
A Arquivamento (“archive” 
C Copia 
g Migração 
S “Scan”
Capítulo 19 Bacula no “Windows”” - 227
Código de Status 
do “Job” Significado
A Cancelado pelo Usuário
B Bloqueado
C Criado, mas não está rodando
c Esperando pelo cliente
D Verificando Diferenças
d Esperando pelo Número Máximo de “Jobs”
E Terminado em Erro
e Erro não fatal
f Erro Fatal
F Esperando pelo “File Daemon”
j Esperando pelo recurso “job”
M Esperando pela montagem da fita
m Esperando por uma nova mídia
p Esperando pelo término de “jobs” com maior prioridade
R “Job” rodando
S Escaneando
s Esperando pelo “Storage”
T Terminado Normalmente
t Esperando pelo horário de início
Capítulo 19 Bacula no “Windows”” - 228
Anexo II
Comparativo Entre as Ferramentas de 
“Backup”19
1. Livres:
Package License
Available 
for 
Windows
?
Available 
for Mac 
OS X?
Available 
for 
Linux?
Has a 
Graphical 
user 
interface?
Has a Web 
interface
?
Has a 
Webmin 
module?
AMANDA BSD Yes Yes Yes No ?
Yes 
(separate 
download)
Areca 
Backup GPL v2.0 Yes Yes Yes Yes ? No
Attix5 Online 
Backup GPL v2.0 Yes Yes Yes Yes Yes Yes
BackupPC GPL v2.0 Yes Yes Yes Yes Yes No
Bacula GPL v2.0 Yes Yes Yes Yes Yes Yes
cpio GNU
Yes(with 
Gnuwin32
)
No Yes No ?
Yes 
(separate 
download)
Create 
Synchronicity GPL v3.0 Yes Partial[1] Partial[1] Yes No No
Cobian 
Backup MPL Yes No No Yes No ?
DirSync Pro GPL Yes Yes Yes Yes ? No
DAR GNU GPL 3 Yes Yes Yes No ? ?
dd GNU Yes Yes Yes No No No
dump GNU No No Yes No ? ?
duplicity GPL Yes (with Cygwin) Yes Yes No ? No
19 Wikipédia: http://en.wikipedia.org/wiki/List_of_backup_software
Capítulo 19 Bacula no “Windows”” - 229
FlyBack GPL No No Yes Yes ? No
luckyBackup GNU GPL 3 No No Yes Yes No No
Mondo GPL No No Yes Yes ? No
rdiff-backup GPL Yes Yes Yes Yes Yes Yes
rsync GPL Partial[2] Yes Yes No ?
Yes (2 
(separate 
downloads)
)
tar GPL
Yes(with 
Gnuwin32
)
Yes Yes
Yes(GUI_Ta
r and Tar 
GUI [1])
? ?
Zmanda 
Recovery 
Manager
GPL Yes No Yes No ? No
2. Proprietárias:
Package Publisher
Available for 
Windows?
Available 
for Mac 
OS X?
Available 
for 
Linux?
Has a 
Graphical 
user 
interface?
.Mac Backup Apple Inc. No Yes No
Acronis True 
Image Acronis Yes No Yes Yes
BackupChain FastNeuron Inc. Yes No No Yes
ARCserve Backup CA, Inc. Yes Yes Yes Yes
Aggregate Backup 
And Recovery 
System
IBM
Backup Express 
(BEX™) Syncsort Yes Yes Yes Yes
Backup4all Softland Yes No No Yes
BackupAssist Cortex IT Labs Yes No No Yes
CDP Server R1Soft Yes No Yes Yes
Crashplan Code 42 Software, Inc. Yes Yes Yes Yes
Disco
Austin Sarner, 
Jasper Hauser and 
Jason Harris
No Yes No
Druva InSync Druva Software Yes Yes Yes Yes
EMC Legato EMC Yes Yes Yes Yes
Capítulo 19 Bacula no “Windows”” - 230
NetWorker Corporation
Retrospect Roxio Yes Yes Yes (client only) Yes
Genie Backup 
Manager Genie-Soft Yes No Yes Yes
GRBackPro GRSoftware Yes No No Yes
Handy Backup Novosoft LLC Yes No No
HP Data Protector HP Software & Solutions Yes No Yes Yes
IBM Tivoli Storage 
Manager IBM Yes Yes Yes Yes
IBM Tivoli Storage 
Manager FastBack IBM Yes No Yes Yes
IBM Aggregate 
Backup And 
Recovery System
IBM
InMage DR-Scout InMage
Image for 
Windows
TeraByte 
Unlimited Yes No Yes Yes
Langmeier Backup Langmeier Software
Macrium Reflect Paramount Software UK Ltd Yes No No
Mozy Mozy Yes Yes No Yes
System Center 
Data Protection 
Manager
Microsoft Yes No No
NTBackup Microsoft Yes No No
SOS Backup SOS Backup Yes Yes
ShadowProtect StorageCraft Yes No No Yes
SyncBack 2BrightSparks Yes No No Yes
SyncToy Microsoft Yes No No Yes
Backup Exec Symantec Yes Yes Yes Yes
NetBackup Symantec Yes No Yes
Norton 360 Symantec Yes No Yes
Norton Ghost Symantec Yes No Yes
Time Machine Apple Inc. No Yes No Yes
Tonido Backup CodeLathe Yes Yes Yes Yes
UltraBac UltraBac Software Yes No No Yes
Unitrends Unitrends Yes Yes Yes Yes
Uranium Backup Freesoft Srl Yes No No Yes
Ventis VentisPro ApS
Capítulo 19 Bacula no “Windows”” - 231
BackupSuite 2008
Windows Home 
Server Computer 
Backup
Microsoft Yes Yes[3] No
Windows Backup 
and Restore 
Center
Microsoft Yes No No
Windows Live 
OneCare Microsoft Yes No No
Yosemite Server 
Backup
Barracuda 
Networks Yes No Yes Yes
	Capítulo 1 
Conceitos Básicos de “backup”
	1.1. Mitos do "backup"
	1.2. Conceitos
	1.3. Tipos de “backup”
	1.4. Mídias de “Backup”
	Capítulo 2 
Desenhando um Sistema de “backup”
	Capítulo 3 
Políticas e Melhores Práticas 
	3.1. Políticas de "backup":
	3.2. Melhores Práticas de "backup":
	Capítulo 4 
Estratégias de "backup" e o Esquema GFS 
	4.1. Vantagens de um sistema de "backup" Centralizado (viabilizado pelo “Bacula”):
	Capítulo 5 
Questões sobre “backups” em Concursos
	Capítulo 6 
O que é o “Bacula”? 
	6.1. Como ele funciona?
	6.2. Principais Características do “Bacula”:
	6.3. O que há de novo na versão 5.0?
	Capítulo 7 
O “Bacula” e as Ferramentas Similares 
	7.1. Amanda (livre):
	7.2. “Arcserve” (proprietária)
	7.3. TSM (proprietária)
	Capítulo 8 
Instalando o “Bacula”
	8.1. Instalando o Banco de Dados:
	8.2. Instalando o “Bacula” (Linux):
	Capítulo 9 
Configurando o “Bacula”
	9.1. Passo-a-passo: Configurando o “Bacula” pela Primeira Vez
	9.2. bacula-dir.conf
	9.3. bacula-sd.conf
	9.4. bacula-fd.conf
	9.5. bconsole.conf
	9.6. Utilizando “Include” para organizar os arquivos de Configuração do “Bacula”
	9.7. Configurando: Ciclo de Vida dos Volumes
	9.8. Configurando: Exemplo de “GFS” no “Bacula”
	9.9. Configurando: Retenções do Bacula
	9.10. Configurando: Novos Clientes Bacula
	9.11. Configurando: Compressão dos "backups"
	9.12. Configurando: Migração e Cópia de Volumes
	9.13. Configurando: Label Automático de Volumes no Bacula
	9.14. Configurando: Desduplicação de Arquivos
	9.15. Configurando: Criptografia das Comunicações do Bacula (TLS)
	9.16. Configurando: Criptografia dos dados Gravados no Storage
	9.17. A função da “pool scratch”
	Capítulo 10 
Primeiros Passos com Fitas Magnéticas
	10.1. Os dispositivos de Fita-Magnética
	10.2. Operações com Fitas.
	10.3. Manipulando Robôs-de-fitas:
	10.4. Usandorobôs com múltiplos drives gravando simultaneamente:
	10.5. “Spooling” de Dados8
	Capítulo 11 
Comandos do “Bacula”
	11.1. Lista Alfabética dos Comandos do “bconsole”:
	11.1. Comandos especiais com Arroba (@) 
	11.2. 	Executando o bconsole por Shell Script
	Capítulo 12 
Restaurando Arquivos
	Capítulo 13 
Restaurando Informações do Catálogo 
	13.1. Restaurando catálogo MySQL a partir do arquivo .sql ("backup")
	13.2. bscan
	Capítulo 14 
Upgrade de Versões do Bacula
	Capítulo 15 
Acessórios para o “Bacula”
	15.1 Interfaces Gráficas
	15.2. Variados 
	15.2. Monitoração
	Capítulo 16
16.1. Instalação do Webacula (GUI) – Versão: 3.*
	16.1. Instalação e Configuração:
	Capítulo 17
“Backup” de Aplicações Específicas com o “Bacula”
	17.1. "backup" de Máquinas Virtuais
	17.2. "backup" de Bancos de dados
	17.3. Servidores Web
	17.4.Serviços de Email
	17.5. Serviços de Diretório
	Capítulo 18
“Bacula Disaster Recovery” no Linux
	18.1. “Bare Metal Recovery” usando um Disco de Emergência do “Bacula” 
	Capítulo 19
Bacula no “Windows”” 
	19.1. Instalando um Servidor Bacula no “Windows”
	19.2. Botando para Funcionar
	19.3. Configurando o “Bacula”
	19.4. Operando o “Bacula”
	19.5. Clientes “Windows”
	19.6. Modificações no Servidor Específicas para os Clientes Windows
	19.7. VSS Shadow
	19.8. Disaster Recovery no Windows
	REFERÊNCIAS 
BIBLIOGRÁFICAS
	Anexo I
Códigos de “status” do “Bacula”18 
	Anexo II
Comparativo Entre as Ferramentas de “Backup”19