Fazer backup em vários discos nem sempre é prático com o Bacula. Vejamos alguns modelos:

Clique aqui para ler tudo.

Este erro geralmente ocorre quando o Bacula não consegue acessar/gravar alguma informação nas suas tabelas do banco de dados.
Um dos motivos que ocorre este erro é a falta de espaço em disco, ocasionando um crash (corrupção) da database.
Ao tentar executar um backup ou um restore, o Bacula irá mostrar o seguinte log.:

Fatal error: sql_create.c:734 Create db File record INSERT INTO File (FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES
(1285,1303,254,4,’gE GAGRm EHA D Bp Bp A BAA BAA I BLCSMo BLBWDh BLBWDh A A E’,’0′) failed.
ERR=Table ‘./bacula/File’ is marked as crashed and should be repaired

Clique aqui para ler tudo…

Utilizando alguns fundamentos do Gerenciamento de Projetos, vamos planejar (e executar!) a instalação de um Sistema de Backups.

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:

1. Prospecção sobre a existência / elaboração de uma política de backup.

[este assunto será abordado no próximo capítulo]

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 peridiodicidade 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.

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, faça com que este levantamento não precise ser tão acurado.

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).

4. Leventamento da Quantidade de Dados a serem backupeados e Gerência de Capacidade

Dizem 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.

Uma boa alternativa (que vem se tornando popular), são soluções baseadas em disco rígido, e que podem ser modularizadas. Um exemplo está no uso de disk-arrays serial-ata hot-swap, que permitem, até, 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 difícilmente 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.

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.

6. 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’s.

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.

* ITIL – V. 2.

7. 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, 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 reste 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.

8. 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á permancer, 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.

9. 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.

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 ocupçã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.

“Baculapedia” (ou Baculpédia) é um projeto para a documentação colaborativa do Bacula, tanto em Inglês quanto em Português.
Assim, sua participação é fundamental. Participe! Clique na imagem.

Baculapedia is a documentation colaborative project for Bacula.
That way, your participation is very important. Take a look! Click on the advertise.

bsmt é o programinha que o Bacula utiliza para enviar as notificações de email para os administradores de backup. Ele já está instalado na maioria das distribuições mas, caso não esteja, você pode baixá-lo através do seguinte link:

bsmt its the little script that Bacula uses to send email for backup administrators. It is part of most Linux flavors but, if you don’t have it installed, you can download it on the following link:

[Download bsmtp]

Reportagem interessantíssima sobre o Bacula (pdf). Clique aqui.

O principal objetivo deste blog é divulgar consultoria / treinamento em software livre, especializado na ferramenta de backup Bacula. Mais informações no link “About”

The main purpose of this blog is to announce consultance / training related to open source software, in special about Bacula – backup tool. More information can be found in the “About” page.