Do que se trata o artigo:

Este artigo tem como objetivo demonstrar a importância do uso de ferramentas de backup para qualquer administrador que zele pela segurança de seus dados. Nessa primeira parte do artigo serão abordados conceitos básicos, mitos, tipos e métodos utilizados para cópia de dados. Será demonstrado como elaborar uma rotina de backup adotando várias tecnologias de armazenamento.


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

Este serviço é usado quando o administrador precisa manter uma cópia de arquivos de banco de dados, arquivos de configuração, diretórios compartilhados, diretórios de e-mails, máquinas virtuais e demais serviços utilizados pela organização. A centralização de backup com o Bacula visa facilitar a administração e identificação de falhas no processo de cópia.

Resumo DevMan:

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

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

Em Tecnologia de Informação (TI), cópia de segurança (backup) é uma cópia de dados de um dispositivo de armazenamento para outro para que possa ser restaurado em caso da perda dos dados originais, o que pode envolver apagamentos acidentais ou corrupção de dados.

Alguns meios difundidos de backup incluem CD-ROM, DVD, disco rígido, disco rígido externo (compatíveis com USB), fitas magnéticas (LTO) e também uma cópia de segurança externa (online). Esta última pressupõe o transporte dos dados por uma rede, como a Internet, para outro ambiente, geralmente para equipamentos mais sofisticados, de grande porte e alta segurança fornecidos por empresas especializadas.

Outra forma de cópia de segurança pouco difundida é feita via rede, que é o tema abordado neste artigo. Na própria rede local de computadores, o administrador ou o responsável pela cópia de segurança grava os dados, processa e distribui as partes constituintes da cópia nos computadores da rede. Isto tudo de forma segura, incluindo dados criptografados (para não haver extração ou acesso aos dados na forma original por pessoas não autorizadas) e o procedimento ser oculto.

Neste contexto, este artigo tem como objetivo demonstrar a importância do uso de ferramentas de backup para qualquer administrador que zele pela segurança de seus dados. Conheceremos alguns conceitos básicos, mitos, tipos e métodos utilizados para cópia de dados. Além disso, será demonstrado como elaborar uma rotina de backup adotando várias tecnologias de armazenamento. Começaremos por alguns conceitos básicos.

O backup 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. Neste último caso, temos a vantagem de também proteger os dados contra acidentes que possam acometer fisicamente a estrutura.

Independente de como os dados possam ser perdidos (apagamentos acidentais, corrupção dos dados, etc.), um backup eficiente consiste naquela política em que se minimizam os impactos desta perda possibilitando a restauração do arquivo ou serviço no menor tempo possível e com o mínimo de defasagem em termos de alteração das informações.

O backup pode variar de acordo com a natureza dos arquivos, com as necessidades empresariais e com a infraestrutura disponível. Além disso, existem algumas métricas que devem ser observadas: tempo de execução das cópias (conhecido como 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. Todos esses fatores devem ser avaliados pela equipe responsável pela execução do processo de cópia.

Quanto à topologia, os backups podem ser classificados como centralizados ou descentralizados. No primeiro caso, geralmente há um servidor que comanda a realização de cópias de segurança conferindo uma maior praticidade na administração e economia pelo armazenamento dos dados em poucos dispositivos, ocorrendo aí um ganho pela escalabilidade. Geralmente é realizado pela noite para que haja mínima possibilidade de impacto aos serviços utilizados em horário administrativo. No segundo caso, cada setor fica responsável pela cópia de segurança, mantendo a mesma em sua posse (caso não aconselhável).

Tipos de Backup

A seguir serão apresentados os tipos de backup que normalmente são encontrados no dia a dia das organizações. Ao final da lista, é apresentada uma tabela com exemplo de implementação de backup full e diferencial.

· Completo (Full) – este tipo de backup faz cópia de todos os arquivos definidos na configuração da ferramenta, independente dos arquivos terem sido alterados ou não. Geralmente é realizado quando o servidor passa por backup pela primeira vez, ou no início de cada ciclo de backups (ex.: uma vez por semana). 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. Este tipo de backup se mostra extremamente caro para ser realizado diariamente, principalmente pela excessiva quantidade de espaço em disco que será utilizada levando em consideração o tamanho do diretório ou arquivo a ser armazenado;

· Diferencial – este tipo de backup faz a cópia apenas dos arquivos modificados a partir do último backup Full. Por 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, este tipo requer menos capacidade de armazenamento e resulta em backups mais rápidos. Em contrapartida, a restauração fica mais complexa, pois necessita sempre de pelo menos dois volumes de backup (um full e possivelmente o último diferencial). Observe na Tabela 1 um cronograma de backup utilizando a cópia completa e diferencial;

· Incremental – este tipo de backup faz a 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 uma vez que pode exigir vários volumes (o full e todos os demais incrementais);

· Cópia – cópia secundária ou complementar de determinado volume de backup (redundância). Muito utilizada para backup off-site. O volume copiado é mantido intacto. Pode ser feito via RAID (veja a Nota DevMan 1);

· 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” antes que a mídia pare de funcionar.

Dia

Segunda

Terça

Quarta

Quinta

Sexta

Sábado

Domingo

Tipo

Diferencial

Diferencial

Diferencial

Diferencial

Diferencial

Diferencial

FULL

Comentário

Contém os dados modificados a partir do backup full no domingo

Contém os dados modificados a partir do backup full no domingo

Contém os dados modificados a partir do backup full no domingo

Contém os dados modificados a partir do backup full no domingo

Contém os dados modificados a partir do backup full no domingo

Contém os dados modificados a partir do backup full no domingo

Backup Completo

Tabela 1. Agendamento de backup FULL e Diferencial.

Nota DevMan 1. RAID

Redundant Array of Independent Drives (Conjunto Redundante de Discos Independentes) é um meio de se criar um subsistema de armazenamento composto por vários discos individuais com a finalidade de ganhar segurança e desempenho.

Mitos sobre cópias de segurança

A partir de agora conheceremos três mitos associados à execução de backups bastante difundidos na comunidade de TI.

Mito 1 – Gerenciamento do Ciclo de Vida da Informação

Backup não pode ser confundido com o Gerenciamento do ciclo de vida da Informação (ILM – Information Lifecycle Management). Alguns desenvolvedores de ferramentas para backup têm advogado no sentido de que este seria um dos papéis deste tipo de ferramenta. Ocorre que o ILM consiste em um processo que abrange muito mais elementos, como: auditoria, indexação, criação, atualização, deleção, aspectos de armazenamento e de acesso.

Ao invés disso, na verdade o backup estaria dentro de uma subdisciplina do ILM, que seria o ILP (Information Lifecycle Protection – ou Proteção do Ciclo de vida da Informação), que também conteria uma série de outros fatores:

· Proteção proativa contra a perda de dados – que pode constituir em antivírus ou outros aspectos em nível de aplicação, por exemplo;

· Alta disponibilidade;

· Redundância de sistemas;

· E se mesmo assim houver perda na informação, a restauração dos dados previamente armazenados pelo serviço de backup seria executada.

Mito 2 – Ferramentas de backup nativas

O segundo mito nos diz que 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 essencial quando o assunto é backup: interoperabilidade. Dessa maneira, seria 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. Além disso, haveria 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 a anos no mercado se não tivessem esta qualidade. O mesmo, analogamente, vale para as soluções livres. Além disso, existem outras funcionalidades importantes que dificilmente são encontradas em ferramentas nativas, a saber:

· Possibilidade de cópias e restaurações cruzadas (ou seja, através da rede – de uma estação para outra diversa);

· Restaurações rápidas utilizando apenas as mídias necessárias para o trabalho;

· Catálogo para indexar os arquivos gravados, facilitando a busca pelos arquivos gravados;

· Manipulação de robôs-de-fitas;

· Ferramentas de recuperação de desastres (disaster recovery).

Mito 3 – Scripts substituindo ferramentas

O terceiro mito nos diz que scripts bem elaborados para backup podem suprir a necessidade de uma ferramenta específica (exemplo de shell script e rsync). A elaboração desses códigos para backup consiste em um retrabalho, visto que já existem aplicações bastante maduras desenvolvidas sob licenças livres. Além disso, o uso de scripts trata-se de uma solução única, utilizada apenas no ambiente no qual se encontra em produção. Isto dificulta bastante a possibilidade de termos suporte externo ou compartilhamento de experiências em outros cenários. A continuidade da solução também estaria prejudicada se não houvesse uma detalhada documentação interna, bem como os custos para o aprendizado seriam mais elevados do que com uma ferramenta comum.

Mídias de Backup

Há no mercado uma vasta quantidade de mídias de armazenamento que podem ser utilizadas para fins de backup. A seguir serão descritas algumas delas, tanto quanto algumas de suas especificações. É importante destacar aqui que o Bacula possui suporte a todos os tipos citados abaixo.

Fita magnética

Fitas magnéticas geralmente trazem a capacidade no seguinte formato: não-compactado/compactado (por exemplo: 20/40 Gb). Esta é uma compactação via hardware realizada pelo próprio drive, e deve ser privilegiada em relação à 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.).

A título de exemplo, abaixo temos alguns modelos de fita:

· Digital Data Storage (DDS) – as capacidades mais recentes são DDS-4 (20/40GB e 3.2 MB/s de gravação/leitura), DDS 72 (36/72GB, com mesma taxa de transmissão) e DDS 160 (capacidade: 80/160GB e “throughput” de 6.9MB/s);

· Digital Linear Tape (DLT) – capacidades: 40, 300 e 800 GB, com taxas de 6, 36 e 60 MB/s respectivamente;

· 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

São todas as mídias que armazenam os dados por reflexão ou marcação. Entram nessa categoria as fitas perfuradas, que usam leitura óptica como mídia de marcação e os DVDs e CDs, como mídias de reflexão.

As mídias que usam reflexão (CD-R, CD-RW e DVD-R), são classificadas em duas categorias diferentes: regraváveis e de gravação única.

As principais vantagens da mídia óptica são: durabilidade e imunidade a campos magnéticos. A desvantagem está no pouco espaço de armazenagem (os gravadores de hoje ainda não gravam mais de uma camada do DVD, o que o limita a cerca de 8.7 GB).

Convém ressaltar ainda que, atualmente, não são usadas mídias de marcação para procedimentos de backup. 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 operacional, aliado a diminuição no custo por gigabyte e aumento de confiabilidade, fizeram com que aumentasse a aplicabilidade dos HDs para o armazenamento dos backups. Atualmente, eles se mostram uma boa opção para pequenas e médias empresas, já que o investimento inicial é baixo (ao contrário dos robôs de fita).

Além disso, o uso de discos rígidos é escalável na medida em 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, em um disco rígido é possível fazer 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). Outra boa prática é alternar o schedule de maneira a utilizar os diferentes 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.

Classificação quanto ao local de armazenamento

Também podemos classificar os backups quanto ao seu local de armazenamento. Esta classificação pode ser feita da seguinte forma:

· 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 há uma existência de cofres antichamas para armazenamento das mídias;

· Backup off-site: Oposto do backup on-site, os dados ficam armazenados em localidade diferente dos dados originais. É uma das características do backup em nuvem (ler Nota DevMan 2).

Nota DevMan 2. Backup em Nuvem

Um servidor de backup em nuvem fornece ao usuário a possibilidade e flexibilidade de acessar seus dados de qualquer lugar que tenha acesso a Internet. Um exemplo desse serviço é o Dropbox, fundado em 2007 por Drew Houston e Ferdowsi Arash. O Dropbox fornece aos usuários 2 GB de espaço gratuitamente e oferece planos para quem necessita de mais armazenamento.

Projetando um sistema de backup

Utilizando alguns fundamentos da Gerência de Projetos, pode-se planejar (e executar) a instalação de um sistema de backup. Neste contexto, a 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. A seguir serão apresentados itens de suma importância para que um projeto de backup possa ser elaborado.

O que será protegido

Nessa atividade será necessário equilibrar a padronização (de agendamentos, níveis, retenções, etc.) em relação às 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. Além disso, é fundamental verificar 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.

Sistemas operacionais envolvidos

Infelizmente, nem todas as soluções de backups 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.

No caso das ferramentas proprietárias, a compra de uma licença para backup de máquina GNU/Linux, por exemplo, não serve para backup de uma estação Windows (e vice-versa). Isso faz com que seja necessário um planejamento muito mais preciso para adquirir licenças de um serviço tão dinâmico quanto cópias de segurança. 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. Além disso, é fundamental verificar se a ferramenta faz backup de arquivos abertos (nas soluções proprietárias, geralmente é cobrado um alto valor por esta funcionalidade adicional).

Gerência de Capacidade

As necessidades de backup crescem em média, segundo estudos, 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 rapidamente obsoleta. Além disso, é importante também estarmos atentos para não desperdiçarmos recursos na compra de um storage superdimensionado às necessidades reais de armazenamento.

Nesse ponto entra o Gerenciamento de Capacidade, conceito trazido pelo ITIL (ler Nota DevMan 3). O gerenciamento de capacidade trata de assegurar que a capacidade da infraestrutura de TI está adequada às demandas do negócio conforme a necessidade e o 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 (Logical Volume Manager) ou BOF (bunch of disks) suficientemente segura.

Nota DevMan 3. ITIL

ITIL (Information Technology Infrastructure Library) foi criada em 1989 pelo CCTA, hoje incorporado pelo Office of Government Commerce, um órgão independente do governo britânico. Constitui-se de uma descrição coerente e integrada de práticas de gerenciamento de serviços de TI. Estas práticas ajudam a implantar e manter um gerenciamento de serviços de TI focando em pessoas, processos, tecnologia e parceiros que são usados na entrega de serviços que atendam às necessidades dos clientes. A versão atual, a ITIL V3, foi lançada em junho de 2007. Junto com o lançamento da ITIL V3, também foi lançado um novo esquema de qualificação profissional.

Se o administrador optar por drives de fita singulares (ou seja – sem alimentação automática), tenha certeza que seu backup dificilmente irá requerer multivolume (mais de uma fita para o backup full). Caso contrário, será trabalhosa a atividade de troca das fitas.

No caso de robôs de fita, a grande preocupação reside no throughput de seus drives, na medida em 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. Além disso, 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 é um fator importante. Neste caso, uma alternativa seria a instalação de uma placa de rede adicional.

Realocação de equipamentos

Algumas vezes, encontramos tesouros perdidos no parque computacional 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 HDs. Vale salientar que, no caso de mídias antigas, é importante verificar o MTBF (ou validade) das mesmas. Também tenha certeza do conteúdo das mesmas antes de reciclá-las.

Escolha do software

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 GNU/Linux costumam prover uma farta e estável compatibilidade com sistemas de fita, disco rígido, aliada à flexibilidade do shell script, configurando-se como ótima escolha para hospedar um servidor de backups.

É necessário um 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 será inviável.

Não se pode esquecer também que notificações por e-mail facilitarão, e muito, a vida do administrador e operadores de backups. Além disso, a opção por uma ferramenta proprietária pode ocasionar um aprisionamento tecnológico, não podendo mudar de solução posteriormente sem ter de renovar as licenças para poder restaurar o legado.

Hardwares de armazenamento e servidor de backup

Este ponto é um dos últimos passos em um planejamento de backup. É interessante observar que para realizar esta atividade, a maioria das informações que subsidiarão esta escolha já foram identificadas. O administrador deverá ter em mente que a solução adquirida deverá permanecer por, no mínimo, 5 ou 7 anos (quando então já estará obsoleta, com dificuldade para 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 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.

Preservação do legado de backup

A maneira mais usual para 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 em uma 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.

Políticas e boas praticas de backup

A existência de uma política de backup em uma organização é essencial e está dentro do considerado como melhores práticas. Ela 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 e a estratégia. Entretanto, o documento deve ser genérico o suficiente para permitir liberdade de escolha das ferramentas utilizadas, bem como as soluções de hardware utilizadas. Pode-se especificar que o backup será feito, preferencialmente, em mídia magnética e de maneira automatizada, mas nunca especificar fabricantes, modelos, referências. 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.

A seguir são apresentadas algumas boas práticas para políticas de backup:

· Ter estratégia condizente com a natureza dos dados armazenados;

· Efetuar testes de restore com periodicidade;

· Efetuar 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;

· Efetuar planejamento e simulações de disaster recovery;

· Exigir 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.

Sistema centralizado de backup

Nessa seção são apresentadas características de um sistema de backup de forma centralizada. Com esse procedimento há uma economia de fitas na medida em que é minimizada a quantidade de espaço subutilizado. Seguem alguns pontos que caracterizam sua valorização:

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

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

Ocasionalmente, um volume pode ser removido do esquema para estabelecer um marco, ou para fins de disaster recovery. Os administradores de rede consideram o GFS como o método mais simples e efetivo de rotação de fitas.

Há ainda de se considerar os benefícios dessa técnica. Um exemplo seria a proteção de seus arquivos com um número mínimo de fitas. Normalmente apenas uma ou duas são necessárias para o restore de um servidor, reciclando algumas fitas e arquivando outras. Pode-se ainda reduzir o desgaste das fitas ou outros dispositivos ligados ao storage. Tem-se ainda como benefício a facilidade na localização de arquivos armazenados devido à sistematização dos backups.

A estratégia de rotação GFS é baseada em uma 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 a ser realizado durante a semana (por exemplo, na sexta-feira à noite), 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.

Na terminologia GFS, o backup diário é o filho e o semanal, o pai. O último backup full de cada mês será considerado o backup mensal 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 na organização.

Um ponto importante que precisa ser ressaltado é a reciclagem das fitas. Por padrão, o backup reutiliza as fitas diárias semanalmente (ou seja, uma mesma fita sempre vai fazer o backup nomeado de segunda-feira). Um exemplo das fitas semanais é que elas deverão ser reutilizadas, tomando como base a fita de sexta-feira, na segunda sexta-feira do mês. Seguindo o exemplo, haverá uma 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 multivolumes, ou se o tempo de retenção (reciclagem) for menor que o padrão.

Sabendo que backups diferenciais diários ocupam um menor volume, ao invés do uso de quatro fitas necessárias no padrão GFS comum (gerando assim a necessidade de troca das mídias diariamente), pode ser implementada outra proposta:

· Semana 1: (fita A) para todos os backups diferenciais diários é utilizada uma mesma fita, com retenção de uma semana;

· Semana 2: (fita B) uma segunda fita é inserida, e será utilizada durante toda esta segunda semana, a não ser para realização do backup full semanal. Atenção, esse será feito em uma fita específica;

· Semana3: (fita A) agora se recicla a fita A, que receberá os backups diários da semana em questão;

· Semana 4: (fita B) e dá-se sequência no ciclo de backup.

A grande vantagem deste esquema é que o risco de danos à fita é diminuído, pois menos trocas de fitas são necessárias. Entretanto, as fitas são gravadas e regravadas em um ritmo mais acelerado.

Conhecendo o Bacula

A partir de agora passaremos a analisar o Bacula, que é um conjunto de ferramentas que permitem administrar as rotinas de backup, restauração e verificação dos dados de computadores em uma rede de sistemas variados. Em resumo, o Bacula é um programa de backup em rede. Ele é formado pelos seguintes componentes (módulos), que podem trabalhar de maneira independente em máquinas variadas, inclusive com sistemas operacionais diferentes:

· Director Daemon: 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;

· Console Manager: programa que auxilia 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 três versões do Console Manager:

o Texto puro (TTy);

o Interface gráfica (GUI) usando bibliotecas do “Gnome”;

o Bibliotecas “wxWidgets” (tanto em formato “Unix” quanto em “Windows”).

· File Daemon: é o software (serviço ou programa cliente) 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. Também é responsável por administrar a gravação dos arquivos de restauração comandados pelo Director Daemon. Existem versões do File Daemon para diferentes sistemas operacionais: GNU/Linux, *BSD, Unix, Windows Macintosh;

· Storage Daemon: serviço que consiste em administrar a gravação e restauração dos dados e atributos dos backups fisicamente em mídias apropriadas. Estes podem ser volumes de dados gravados diretamente no disco rígido ou em alguma mídia removível;

· Catalog: é 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.

Na Figura 1 pode-se ter uma ideia geral de como é o funcionamento dos módulos no Bacula. Conforme podemos observar, o Director é o coração do Bacula. Ele recebe os comandos do administrador via Console (modo texto, GUI, web) e se comunica com os clientes (file daemons). Esses clientes entram em contato com a Storage Daemon, que posteriormente fará as gravações dos arquivos no disco (Physical Media), e ela, em seguida, troca informações com o Director, como autorizações, índices e atributos que ficam gravados no Catalog SQL.

Figura 1. Módulos do Bacula.

Para esclarecer ainda mais o entendimento dos módulos no Bacula, a Figura 2 apresenta de forma sucinta como ocorre a interação desses agentes no Bacula. Conforme podemos observar, o administrador (admin workstation), através de uma console de comandos ou wxWidgets Console (interface gráfica), faz consultas, envia comandos para o Servidor Bacula (Director), este escutando na porta 9101. A aplicação roda em segundo plano autenticando as conexões e controlando as operações de backup. O administrador (admin workstation) ao mesmo tempo faz um monitoramento do cliente Bacula (File Daemon) na porta 9102, e da storage que armazena todos os dados pela porta 9103. O Director se comunica com os clientes ordenando as rotinas de backup para a storage, que por sua vez grava na mídia de armazenamento. Durante todo esse processo o Director está em contato com o servidor de banco de dados, aqui o MySQL na porta 3306, para armazenar e consultar os Índices.

Figura 2. Interação dos módulos no Bacula.

Características do Bacula

Agora que já sabemos como funciona o Bacula e seus agentes, seguem abaixo algumas de suas principais características:

· 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 suporte pela comunidade (mailing lists, forums, IRC channel);

· Grande documentação disponível na Internet;

· Portabilidade (compatibilidade entre os módulos para diferentes sistemas);

· Várias opções para a customização de backups;

· 100% compatível com o esquema GFS;

· Ferramenta de “backup” multi-banco de dados;

· Possui baixos requisitos de hardware.

Além dessas características, o Bacula possui uma funcionalidade que permite a execução de scripts (ou executáveis) antes ou depois do início de trabalhos (backup/restore), tanto no cliente quanto no servidor. Tais operações podem ser efetuadas via linha de comando (modo texto) ou GUI (interface gráfica).

Um destaque especial pode ser dado também para as ferramentas de administração via web. O webacula e o bacula-web são ferramentas de visibilidade gerencial, sendo que a primeira ainda possibilita operações de backup e restore.

O Bacula tem suporte para a maioria dos dispositivos de storage do mercado (inclusive mídias ópticas). Um ponto fundamental é o envio de mensagens de log. Esta é uma funcionalidade importante tanto para os trabalhos de backup/restore quanto para fornecer instruções para operadores de diferentes perfis.

Pelo fato de ser livre, o Bacula permite o desenvolvimento de uma série de addons potencializando os recursos da ferramenta (veja a Nota DevMan 4). Inclusive, já existe plugin para o Nagios, ferramenta de monitoração.

O Bacula pode ainda substituir as ferramentas proprietárias mais comuns no mercado de TI (como exemplo, o ArcServe da Computer Associates e o TCM, da IBM).

Por fim, uma grande vantagem do Bacula consiste no fato de que, por possuir variante da licença GPL, ele é distribuído gratuitamente pela Internet. Além da economia 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.

Nota do DevMan 4. Addons

Conjunto de plugins que agregam funcionalidades a uma determinada aplicação.

Outras ferramentas de backup

Para finalizar, apresentaremos nesta seção algumas opções de ferramentas disponíveis para trabalharmos com backup:

· Amanda: Ferramenta livre, acrônimo para Advanced Maryland Automatic Network Disk Archiver, trata-se de um sistema que permite a configuração de um servidor mestre para realização de backups de múltiplos clientes numa rede com a possibilidade de armazenamento em fita, disco ou dispositivo. Ela usa o dump nativo do UNIX ou a ferramenta GNUtar e pode realizar backups de uma grande quantidade de máquinas rodando diferentes sistemas UNIX, com possibilidade de uso do Samba ou Cygwin para o backup de sistemas Microsoft Windows. Esta foi por muito tempo a mais popular ferramenta livre para realização e gerenciamento de backup;

· Arcserve: Ferramenta proprietária, muito interessante uma vez que suporta diversos sistemas operacionais, assim como o Bacula. Entretanto, a licença para um sistema só serve para aquele em específico, causando um aprisionamento tecnológico. O 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 possuir um custo elevado, é dividido por módulos e por funcionalidades, ou seja, cada vez que houver necessidade de um novo recurso, será necessário adquirir um novo módulo. No final do projeto, seu custo se torna demasiadamente alto;

· TSM: ferramenta proprietária, trata-se de uma ferramenta com bastantes recursos e, em certo ponto, é similar ao Bacula. A maior desvantagem fica na falta de documentação aberta, resultando em maior necessidade de treinamento e dificuldade na solução de problemas/bugs. De forma semelhante à ferramenta anterior, possui todas as demais desvantagens em se adotar uma ferramenta proprietária. O TSM costuma ser fornecido gratuitamente para quem adquire um storage da IBM, o que consiste em uma venda casada. No momento que o usuário começa a utilizar o TSM, cria um legado de backups difícil de ser migrado posteriormente. 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, gerando um aprisionamento tecnológico.

Conclusão

Toda organização que se preze deverá ter um bom capítulo sobre backup na sua Política de Segurança da Informação. Conforme mencionado, há vários aspectos a serem avaliados quando um serviço de cópias de segurança é implementado. Nessa primeira parte do artigo sobre o Bacula apresentamos uma introdução sobre a importância do uso de cópias de segurança assim como suas formas.

Além disso, conhecemos o Bacula e seus principais componentes. Vimos que com ele ganhamos em flexibilidade de personalização de políticas e hardware, e obtemos uma redução de custos com licenças de uso.

Na próxima edição será apresentada de forma prática a instalação, configuração e uso do Bacula em um sistema operacional baseado em kernel Linux.

Links

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

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

Software Livre
http://softwarelivre.org/bacula

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

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

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

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

Amanda
http://www.amanda.org/

TSM
http://www-01.ibm.com/software/tivoli/products/storage-mgr/

ARCServe
http://www.arcserve.com/us/support/ca-arcserve-backup.aspx

Referências

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