Manual do Bacula

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 outros