Você está na página 1de 231

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.................................................................................186
17.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 elemento da
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 salvaguarde informaçõ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


FULL "backup"
Diff Diff* Diff Diff Diff Diff

*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ção que 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 “Director Daemon” 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 numa rede, 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 clientes 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 utilizado pelo “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:

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.

Priority = 10
FileSet = fileset-full
Storage = File-Storage
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 acabamos de 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.

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.

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
}
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:

%% = %
%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, ...)

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 {
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, exceto a 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
volume .6

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ão
possuí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á.

Caso haja 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=MyJob days=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 podendo ser 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 ... +

Building directory 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, devendo ser 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.html

II. 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 uma tela 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 ESTRELA BRILHANTE 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
Significado
Backup
“backup” completo
F
(“full”)
I “backup” incremental
D “backup” diferencial
C Verificação do catálogo
V Verificação do “init db”
Verificação de Volume
O
para Catálogo
Verificação de Disco para
d
Catálogo
Verificação de dados no
A
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
Significado
de Backup
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
Significado
do “Job”
A Cancelado pelo Usuário
B Bloqueado
C Criado, mas não está rodando
c Esperando pelo cliente
D Verificando Diferenças
Esperando pelo Número Máximo de
d
“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
Esperando pelo término de “jobs” com
p
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:

Available Has a
Available Available Graphical Has a Web Has a
for for
Package License for Mac user interface Webmin
Windows
OS X? Linux? interface? ? module?
?
Yes
AMANDA BSD Yes Yes Yes No ? (separate
download)
Areca
GPL v2.0 Yes Yes Yes Yes ? No
Backup
Attix5 Online
GPL v2.0 Yes Yes Yes Yes Yes Yes
Backup
BackupPC GPL v2.0 Yes Yes Yes Yes Yes No
Bacula GPL v2.0 Yes Yes Yes Yes Yes Yes
Yes(with Yes
cpio GNU Gnuwin32 No Yes No ? (separate
) download)
Create
GPL v3.0 Yes Partial[1] Partial[1] Yes No No
Synchronicity
Cobian
MPL Yes No No Yes No ?
Backup
DirSync Pro GPL Yes Yes Yes Yes ? No
GNU GPL
DAR Yes Yes Yes No ? ?
3
dd GNU Yes Yes Yes No No No
dump GNU No No Yes No ? ?
Yes (with
duplicity GPL Yes Yes No ? No
Cygwin)

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


GNU GPL
luckyBackup No No Yes Yes No No
3
Mondo GPL No No Yes Yes ? No
rdiff-backup GPL Yes Yes Yes Yes Yes Yes
Yes (2
(separate
rsync GPL Partial[2] Yes Yes No ?
downloads)
)
Yes(with Yes(GUI_Ta
tar GPL Gnuwin32 Yes Yes r and Tar ? ?
) GUI [1])
Zmanda
Recovery GPL Yes No Yes No ? No
Manager

2. Proprietárias:

Has a
Available for Available Available
Graphical
Package Publisher Windows? for Mac for
user
OS X? Linux?
interface?
.Mac Backup Apple Inc. No Yes No
Acronis True
Acronis Yes No Yes Yes
Image
BackupChain FastNeuron Inc. Yes No No Yes
ARCserve Backup CA, Inc. Yes Yes Yes Yes
Aggregate Backup
And Recovery IBM
System
Backup Express
Syncsort Yes Yes Yes Yes
(BEX™)
Backup4all Softland Yes No No Yes
BackupAssist Cortex IT Labs Yes No No Yes
CDP Server R1Soft Yes No Yes Yes
Code 42 Software,
Crashplan Yes Yes Yes Yes
Inc.
Austin Sarner,
Disco Jasper Hauser and No Yes No
Jason Harris
Druva
Druva InSync Yes Yes Yes Yes
Software
EMC Legato EMC Yes Yes Yes Yes
Capítulo 19 Bacula no “Windows”” - 230

NetWorker Corporation
Yes (client
Retrospect Roxio Yes Yes Yes
only)
Genie Backup
Genie-Soft Yes No Yes Yes
Manager
GRBackPro GRSoftware Yes No No Yes
Handy Backup Novosoft LLC Yes No No
HP Software &
HP Data Protector Yes No Yes Yes
Solutions
IBM Tivoli Storage
IBM Yes Yes Yes Yes
Manager
IBM Tivoli Storage
IBM Yes No Yes Yes
Manager FastBack
IBM Aggregate
Backup And IBM
Recovery System
InMage DR-Scout InMage
Image for TeraByte
Yes No Yes Yes
Windows Unlimited
Langmeier
Langmeier Backup
Software
Paramount
Macrium Reflect Yes No No
Software UK Ltd
Mozy Mozy Yes Yes No Yes
System Center
Data Protection Microsoft Yes No No
Manager
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 Microsoft Yes Yes[3] No
Backup
Windows Backup
and Restore Microsoft Yes No No
Center
Windows Live
Microsoft Yes No No
OneCare
Yosemite Server Barracuda
Yes No Yes Yes
Backup Networks

Você também pode gostar