HEITOR MEDRADO DE FARIA
Orientador. Julio C Noguchi

Salvador

2010

RESUMO

A escolha de uma solução de software que atenda às necessidades empresariais no curto e médio prazo nunca foi tão difícil.

Desenvolvedores de todo mundo trazem novidades quase que diárias, e o amadurecimento do modelo colaborativo trouxe ainda mais variáveis a serem analisadas, como os benefícios da gratuidade de licença, conhecimento do código fonte, melhorias constantes e contínuas nas ferramentas, documentação aberta, maior ciclo de vida da solução, etc.

No âmbito das cópias de segurança, visamos estabelecer parâmetros objetivos de que atributos devem ser valorados na escolha da ferramenta, isso para atender as necessidades corporativas.

“O código Aberto costuma oferecer a possibilidade de avaliarmos softwares antes de decidirmos por sua aquisição. No entanto, a área dos softwares de becape é dominada por licenças proprietárias. O custo, em geral, reside na casa dos milhares de reais.” – Linux Magazine¹

De igual sorte, os “backups” são serviços críticos e, assim, não podem esperar pela compra de licenças (modelo proprietário), processo ainda mais demorado em Empresas Públicas como o SERPRO, na qual o caminho normal para a aquisição de bens é a Licitação.

Ademais, a adoção de ferramentas livres, nos últimos anos, aumentou consideravelmente, fruto de iniciativas de governos estaduais, municipais e mais notadamente no federal.

Palavras chaves: backup, Bacula, solução, cópia de segurança, armazenamento, software livre.

INTRODUÇÃO

O “backup” consiste na cópia de dados específicos (redundância), para serem restaurados no caso da perda dos originais. Ainda, segundo a Wikipedia²: “Em informática, cópia de segurança é a cópia de dados de um dispositivo de armazenamento a outro para que possam ser restaurados em caso da perda dos dados originais, o que pode envolver apagamentos acidentais ou corrupção de dados.”

A cópia pode ser realizada para o mesmo computador, para um dispositivo de armazenamento ou, ainda, para 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 (online ou cruzado). Esta, transporta os dados por uma rede como a Internet para outro ambiente, geralmente para equipamentos mais sofisticados, de grande porte e alta segurança.

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.

Por ser um tema bastante restrito e peculiar, as regras impostas pelas licenças proprietárias impedem que softwares sejam testados antes de serem adquiridos. De igual sorte, a área de “backups” foi durante muito tempo dominada por ferramentas comerciais, sendo que o custo das mesmas reside na casa dos milhares de reais Ainda, existem poucas obras em português sobre o tema: cópias-de-segurança.

No SERPRO, convivia-se com uma estrutura de backup insatisfatória – com licenças antigas do Arcserve (7.0) – já sem suporte, além de não permitir a realização de cópias na topologia centralizada. Em 2006-2007, foi iniciado um estudo para a escolha de uma ferramenta que possibilitasse a centralização de backups (que já se mostrava uma necessidade, devido aos autos custos que o modelo descentralizado impunha – ex.: um drive e conjunto de fitas para cada servidor) e que fosse preferencialmente Livre (de acordo com a política governamental e alinhamento estratégico corporativo).

O uso do modelo descentralizado trazia consigo também um alto custo com capacidades humanas. Haviam partes interessadas que precisavam estar dedicadas às seguintes atividades: troca – organização das fitas, bem como um administrador dos backups (configuração, instalação, verificação de erros, etc.). Tais atividades representavam muitas horas de trabalho.

Depois de escolhida e implementada a solução Bacula, cumulada com a mudança de topologia, o custo com mídias, licenças, drives de fitas e com capacidades humanas, foi reduzido em, no mínimo, 75% (setenta e cinco por cento).

Este trabalho objetiva demonstrar todo o processo de escolha de uma ferramenta de backup, pressupostos, requisitos, dados de aplicações específicas que precisavam ser protegidos, funcionalidades e especificações do Bacula, bem como as características e influências de uma gestão baseada nas ideologias do Software Livre.

PRESSUPOSTOS

2.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 cada organização.”⁴

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 Guise⁶.

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.

2.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 Informação), que também conteria uma série de outros fatores:

1. 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;

2. alta disponibilidade;

3. redundância de sistemas;

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

2.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…”⁷

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.

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

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

2.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 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:

1. possibilidade de backups e restores cruzados (ou seja, através da rede – de uma estação para outra diversa);

2. restores rápidos utilizando apenas as mídias necessárias para o trabalho;

3. catálogo para indexar os arquivos gravados, facilitando a buscar pelos arquivos gravados;

4. manipulação de robôs-de-fitas;

5. ferramentas de recuperação de disastres.

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

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”⁹

REQUISITOS DA FERRAMENTA DE “BACKUP”

3.1. Portabilidade:

No mesmo ritmo que surgem novas e diferentes aplicações / sistemas operacionais, crescem as especificidades e heterogeneidade das corporações. Como exemplo, a grande maioria dos datacenters atuais possuem, ao menos, duas ou três plataformas instaladas em seus servidores. Assim, a portabilidade talvez seja a principal característica a ser considerada na aquisição de uma solução de software de backup, atendendo ao princípio de que seria mais econômico administrar apenas um tipo de ferramenta, do que várias. E daí vem também a seguinte questão:

“Software proprietários normalmente são desenvolvidos visando as arquiteturas de hardware e software dominantes no mercado, e manter uma equipe de desenvolvimento e testes para arquiteturas menos utilizadas é inviável para a maioria das empresas, mesmo que na prática, garantir a portabilidade de um programa muitas vezes envolva apenas cuidados triviais.”¹⁰

No caso do software livre, a disponibilidade do código-fonte permite à comunidade verificar o funcionamento da ferramenta em diferentes sistemas operacionais, agregando valor para o programa (que ganha novos usuários) e para as plataformas (que ganham novas aplicações compatíveis).

Outra questão que de certa forma restringe a portabilidade reside na questão das licenças proprietárias. Quando adquirida, a licença de um software para Windows, como exemplo, não pode ser convertida em uma licença da mesma aplicação para Linux (por exemplo). Desta forma, migrações e estimativas de compra tornam-se muito mais complexas, muitas vezes impossibilitando o correto funcionamento de um sistema tão crítico como o de cópias de segurança.

3.2. Interoperabilidade:

“Habilidade de dois ou mais sistemas (computadores, meios de comunicação, redes, software e outros componentes de tecnologia da informação) de interagir e de intercambiar dados de acordo com um método definido, de forma a obter os resultados esperados.” (ISO)¹¹

Também associado ao princípio da portabilidade, a interoperabilidade entre os módulos da ferramenta de backup se mostra fundamental para uma implementação racional e flexível da mesma, pois daí depende uma série de operações técnicas importantes:

1. Realização de backup multi-plataforma centralizado através de rede, diminuindo consideravelmente os custos com administração e custo com armazenamento;¹²

2. Trabalhos de restauração cruzada¹³ multi-plataforma, facilitando em muito a vida do administrador de rede que não encontra espaço, no servidor de origem dos dados, para a restauração de arquivos. De igual sorte, facilita também processos de migração;

3. Adoção de uma ferramenta de backup singular, permitindo a padronização de estratégias, procedimentos, etc., também gerando uma economicidade de recursos;

4. Racionalização dos recursos de hardware existentes, possibilitando o uso de dispositivos de armazenamento instalados em diferentes sistemas operacionais;

5. Facilidade na realização de um backup remoto (off-site), atendendo às recomendações ISO que falam do armazenamento dos dados em local diverso de onde os servidores estão instalados.

Além da compatibilidade entre os módulos do sistema de backup que são executados em diferentes sistemas operacionais, fundamental também que haja, também, uma integração com o próprio sistema hospedeiro, de maneira que seja possível a execução de scripts antes e depois dos trabalhos e, assim, possibilitando uma completa automação dos processos (ex.: ejeção de fitas após a conclusão de todos os jobs, criação do dump de um banco de dados antes da cópia dos arquivos, etc.).

Por fim, importante lembrar que: “…Para um sistema ser considerado interoperável, é muito importante que ele trabalhe com padrões abertos.”¹⁴

3.3. Suporte a backup centralizado:

Há algum tempo atrás os dados de determinado servidor geralmente caberiam em apenas uma fita e, assim, os equipamentos traziam consigo um drive de fitas de alimentação manual para a realização individual de seu backup.

“Gradativamente as companhias perceberam o custo em ter um funcionário dedicado a trocar as fitas de cada um dos servidores – ou os sistemas chegaram a um ponto no qual uma fita não era mais suficiente para a cópia dos dados…”¹⁵

As desvantagens de um backup descentralizado eram inúmeras: custo elevado para adquirir e manter um drive de armazenamento em cada servidor; necessidade de considerável intervenção humana para troca de mídias (considerada um risco maior para a ocorrência de falhas); administração mais complexa de múltiplos serviços de backup, individualmente; inexistência de relatórios, administração e configuração centralizados; dificuldade em aplicar mudanças de política (ex.: mudar backups full da sexta para o sábado); maior dificuldade na restauração dos arquivos (requer mudança manual de fita); em se tratando de software comercial requer um custo mais elevado com licenças; maior custo de operação se forem ferramentas heterogêneas.

Já na topologia de backup centralizado, vários clientes da ferramenta se reportam a apenas um “mestre” (ou servidor de cópias de segurança), implicando na transmissão de dados através da rede. Como geralmente são realizados durante a noite, os impactos de tráfego não são significativos para o usuário. De igual sorte, existem técnicas como a realização de múltiplos trabalhos de backup simultâneos de diferentes servidores que diminuem o consumo de banda em cada um deles.

As vantagens do backup centralizado são muitas:

1. a aquisição de robôs-de-fita, geralmente, passa a ser justificável (e mais econômica do que a compra de vários drives individuais) – automatizando os processos de trocas de fita no backup e restore;

2. configuração geral do sistema se torna mais fácil;

3. proteção do sistema de backup em si, resta simplificada;

4. possibilidade de relatórios consolidados, facilitando a verificação de erros ou ainda gerência de capacidade, etc.;

5. um sistema de backups centralizado justifica a alocação exclusiva de um administrador nesta função – trazendo os benefícios da especialização e uma maior proatividade na manutenção do sistema;

6. redução de custos com licenças, em se tratanto de software proprietário.

Alguns autores alegam, entretanto, que o custo inicial com hardware para o backup centralizado seriam mais elevados – o que consistiria numa desvantagem. Ocorre que, algumas ferramentas (como o Bacula), permitem que um só mestre controle uma série de dispositivos de armazenamento (ainda que em máquinas diferentes).

Dessa forma surgem soluções alternativas como, por exemplo, agrupar vários drives de fitas manuais para que trabalhem como se um robô-de-fitas fossem (para realização de backups multi-volumes).

Assim, ainda que não seja uma solução totalmente automatizada, traz consigo vários dos benefícios da centralização – e não exige a compra imediata de um robusto dispositivo de armazenamento.

3.4. Backup de Arquivos Abertos

Consiste na habilidade de copiar arquivos, mesmo que estejam em uso (ex.: uma máquina virtual em operação ou ainda um arquivo de texto que esteja sendo editado pelo usuário).

Esta funcionalidade – fundamental para que se consigam cópias de segurança válidas dos sistemas, constitui uma das ressalvas à aquisição de ferramentas proprietárias de backup. Alguns de seus desenvolvedores a comercializam como se fosse um “plus” – um acessório à solução:

“Agente OpenFile do BrightStor® ARCserve® Backup. Sabia que geralmente os backups incompletos são devidos a arquivos abertos e não à falhas do hardware ou do software? Este agente garante um backup completo de todos os arquivos, inclusive daqueles que estejam abertos ou em uso (dados básicos da empresa, dados de aplicativos, etc.), o que elimina o tempo de inatividade necessário para realizar o backup e garante a proteção completa de todos os dados e sistemas de arquivos. ” – Extraído do documento: “Personalize e Otimize seu Ambiente BrightStor® ARCserve® Backup com Opções e Agentes ”, da Computer Associates.

Obviamente, trata-se de uma espécie de “venda casada”, pois adquirir uma solução que não faça backup de arquivos abertos é ter uma proteção precária dos dados.

Vale salientar que mesmo com esta habilidade, algumas aplicações podem não ser “backupeadas” corretamente (a exemplo de bancos-de-dados). Os seus desenvolvedores devem especificar qual a maneira ideal de fazê-lo e obviamente testes de restauração são, mais do que nunca, necessários.

3.5. Agentes para aplicações específicas(?)

Os “agentes” são módulos das ferramentas de “backup” que facilitariam (e algumas vezes possibilitariam)o trabalho de “backup / restore” de determinada aplicação. Este modelo nasceu do mercado proprietário, no qual empresas (Ex.: Novell) forneciam algumas API de seus produtos de software para que outras empresas (Ex.: Computer Associates) desenvolvessem “agentes” específicos para seu produto.

Obviamente se mostra uma prática deturpadora do mercado – e até uma espécie de venda casada, na medida que restringe absurdamente as opções de implementação do “backup”. De igual sorte, o mínimo que determinada aplicação de respeito deve fornecer como funcionalidade, é uma maneira de extrair seus dados de maneira integra.

O modelo de “agentes” também dificulta a adoção de uma ferramenta de backup única, na medida que cada ferramenta possui agentes para diferentes aplicações – tornando inviável qualquer espécie de padronização.

Muito mais útil do que os agentes, seria a já mencionada possibilidade de executar scripts ou binários, antes ou depois dos “jobs” de backup, tanto no cliente quanto no servidor responsável pelas cópias de segurança, independente de plataforma. Com esta possibilidade, é possível colocar bancos-de-dados em modo de backup (ex.: funcionalidade do Postgresql), fazer dump de bancos (ex.: MySQL), ou ainda chamar rotinas nativas da aplicação, como submeter um backup através RMAN (no exemplo, ferramenta do banco Oracle).

3.6. Automação

A execução automatizada de tarefas como ejeção de fitas no caso de drives de midia manuais, bem como a manipulação automatizada de robôs-de-fitas, agendamento de trabalhos, são qualidades essenciais de uma ferramenta de backup, como já introduzido no item sobre o “backup centralizado”. Entretanto, existem questões ainda mais profundas.

A reciclagem de volumes (contagem do tempo de retenção e sua expiração), apesar de constituir uma funcionalidade básica de qualquer ferramenta, precisa ser automático. De igual sorte, o envio de “logs” com o status dos trabalhos de backup precisa existir, para diminuir custos com a administração deste serviço, bem como mensagens de alerta quando alguma intervenção manual seja necessária – para diminuir o tempo em que o sistema reste paralisado.

Mais uma vez, a integração com o sistema operacional, para a execução de scripts, se mostra fundamental, para tratar algum dos quesitos já citados ou outras necessidades eventuais de automação.

3.7. Compatibilidade com o padrão “GFS”

O GFS consiste na estratégia de rotação de volumes mais popular entre os administradores de rede no mundo. Prova disto reside no fato de que a maioria das ferramentas possibilita sua implantação, e muitas delas já trazem padrões inspirados na mesma.

3.8. Banco de dados Independente

Um banco-de-dados para a gravação de informações sobre os dados armazenados consiste quase que numa “exigência” para uma ferramenta de backup corporativa. Entretanto, algumas delas trazem formatos proprietários fechados, específicos para aquele software, o que traz um sério risco consigo.

Se este banco-de-dados for corrompido – e as rotinas nativas para restauração não conseguirem repará-lo (existem inúmeros casos concretos), é bem provável que não seja possível restaurar os dados que foram gravados previamente com a ferramenta, isto porque os índices de localização dos arquivos (catálogo) foram perdidos.

Portanto, a possibilidade pelo uso de uma das soluções de banco-de-dados mais comuns do mercado, principalmente das alternativas livres, confere uma segurança e praticidade extremamente maiores para o sistema.

3.9. Auto-restauração do Sistema de Backup

Se todo o servidor de backups for apagado, imprescindível que existam rotinas para restaurá-lo a partir dos seus volumes gravados. Preferencialmente, que estes possam ser extraídos a partir de ferramentas abertas como o “dd”¹⁶ do Linux.

3.10. Outras Características Básicas

Obviamente, características básicas como possibilidade em executar os tipos essenciais de backup (full, diferencial e incremental) não pode deixar de ser um requisito para uma ferramenta de backup. Ademais, temos a integridade dos dados armazenados e a preservação de meta-informações dos arquivos (permissões, proprietário do arquivo, etc.), quando da restauração.

O BACULA

4.1. A Maturidade e Popularidade da Ferramenta

Apesar de ser mais novo que a maioria dos demais projetos de backup sob licença livre (registrado em 2002-04-07), o Bacula superou todos os similares em quantidade de usuários, downloads e popularidade. Ocupa a posição 292 no ranking dos projetos de software hospedados no maior hospedeiro do gênero (o Sourceforge), com 1,156,044 (hum milhão, cento e cinquenta e seis mil, e quarenta e quatro) downloads, atualmente¹⁷. Por conta disso, foi escolhido como paradigma para estudo dos pressupostos e requisitos estabelecidos na escolha de uma ferramenta de backup.

“O software é um dos bens que se enquadra na definição de bem intangível. A escassez do software, depois que o bem se tornou rentável, foi provocada de maneira artificial pelos modelos de licença, fato que ocasionou níveis de restrição de acesso aos códigos. Ao recuperarmos a natureza do bem, pela aplicação de licenças livres, o software retoma seu pleno potencial na economia dos bens intangíveis.”¹⁸

Constituindo um bem intangível, o software possui valor não apenas pela utilidade das funcionalidades que possui e que proporciona mais, também, pela quantidade de usuários que possui.

Quanto mais usuários determinada ferramenta possui, menor é o custo com treinamentos, com contratação de mão-de-obra especializada, bem como compatibilidade entre sistemas nele baseados.

O “Bacula” trata-se da ferramenta mais utilizada dentre as livres, e provavelmente a mais utilizada em todo mundo (apesar de não haverem estatísticas).

“De acordo com estatísticas do Sourceforce, o software de backup livre Bacula foi baixado mais de um milhão de vezes. A crescente popularidade deste software está atribuída em parte ao crescimento contínuo de sua comunidade. Existem também novos produtos como um dispositivo de boot via USB para recuperação de desastres. Bacula é um pacote sólido de softwares para backup, agora na versão 5.0.0, que traz todo o necessário para salvar, restaurar e verificar as informações através de uma rede de diversos computadores, inclusive trazendo a opção de armazenar dados de maneira criptografada.”¹⁹

Existem empresas e profissionais dedicadas ao treinamento e suporte da mesma – como a Bacula Systems²⁰ (fundada pelos principais desenvolvedores do Bacula), e a nível nacional a Bacula Backup Brasil (www.bacula.com.br) – que é também a base da comunidade brasileira de usuários da ferramenta.

4.2. Funcionalidades Atuais

“O Bacula tem estado em desenvolvimento contínuo por mais de 7 anos, provendo uma completa e fácil instalação para diversos sistemas operacionais. Inclui bom suporte a dispositivos removíveis como DVDs e USB, código de indexação de discos para rápida restauração de dados e boa documentação. Aqui temos uma completa lista das funcionalidades do Bacula.

O sistema está disponível para acesso através de console texto ou ainda interfaces gráficas.”²¹

Dentre outras funcionalidades mais recentes do Bacula (versão 5.0), destacamos:

a) O controle de arquivos duplicados – economizando espaço no armazenamento – funcionalidade esta que também vem sendo divulgada como atrativo das últimas versões de ferramentas proprietárias (Ex.: Arcserver 12.5²²);

b) versão de sua interface gráfica nativa – BAT (Bacula Administration Tool) também para Windows;

c) tradução para diversos idiomas – inclusive Português do Brasil.

4.3. O que é o Bacula?

O Bacula é um conjunto de programas que permite, ao administrador de sistemas, administrar backup, restauração e verificação dos dados de computadores em uma rede de sistemas heterogêneos (ou seja – com diferentes sistemas operacionais).

Em outros termos, o Bacula é um Programa de Backup em rede, conforme demonstrado no diagrama a seguir:

Figura 1.: Diagrama de Módulos do Bacula.

.

Principais características da ferramenta:

a) Estrutura cliente/servidor;

b) estrutura modular independente (director, client, storage, database, administration console);

c) licença GPL – economia de custos com licenças, conhecimento do código, possibilidade de customização da ferramenta, além de todas as vantagens retromencionadas;

d) inúmeros canais de suportes pela comunidade (mailing lists, forums, IRC channel, etc.);

e) farta documentação disponível na Internet;

f) portabilidade (módulos para diferentes sistemas operacionais – Windows, Linux, MAC, etc. – são compatíveis;

g) infinidade de recursos para a customização de backups;

h) 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;

i) operação via linha de comando ou GUI (inclusive, com diferentes interfaces web desenvolvidas pela comunidade. Destques para o webacula e o bacula-web – ferramentas de visibilidade gerencial, com gráficos, etc., sendo que a primeira ainda possibilita operações de backup, restore…);

j) suporte à maioria dos dispositivos de storage do mercado (inclusive mídias ópticas);

l) funcionalidade para o envio de mensagens de log dos trabalhos de backup/restore ou ainda instruções para o operador de backup (diferentes perfis);

m) compatível com a estratégia de retenção de fitas GFS;

n) única ferramenta de backup multi-banco-de-dados (atualmente suporta três: SQLite, MySQL e PostgreSQL) para que funcionem como seu “catálogo”;

o) pelo fato de ser livre, permite o desenvolvimento de uma série de “addons”, por terceiros inclusive, potencializando os recursos da ferramenta (ex.: plugin para o Nagios – ferramenta de monitoração também GPL).

Como funcionam os módulos do Bacula:

a) Director Daemon: serviço responsável pela administração de todos os processos de backup, restore, verificação e arquivamento. Trata-se do servidor de backup, propriamente dito. O Administrador de Sistema usa o Director Daemon para efetuar agendamentos de backup, para recuperar arquivos, bem como realizar grande parte das configurações;

b) 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);

c) 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);

d) Storage Daemon: consiste no software que administra a gravação e restauração dos dados e atributos dos backups fisicamente, isso em mídias apropriadas. Estas podem ser volumes de dados gravados diretamente em discos rígidos ou dispositivos removíveis (ex.: Fita DAT, DVD, CD, etc…);

e) Catalog: o serviço de catálogo é 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.

4.4. Casos de Sucesso

Dentre empresas públicas e privadas, são inúmeros os casos de sucesso na implementação do Bacula. Em nível nacional temos o SERPRO – Serviço Federal de Processamento de Dados, que utiliza o Bacula há aproximadamente 4 anos – isso em substituição ao Arcserve.

Dentro das companhias estaduais de TI, temos o exemplo da ATI (Piauí), e no Setor Paraestatal a FIERN/SESI/SENAI/IEL – Federação das Indústrias do Estado do RN²³.

No setor privado sabe-se da utilização da: Neocode Software e a Pontis Corporation²⁴ (Canadá), LIDP Consulting, Inc. e Worcester Polytechnic Institute (EUA), Capodarco S.C.S.I (Itália), Banco da Áustria²⁵, etc.

4.5. Requisitos Mínimos de Hardware

Os daemons (ou serviços) do Bacula, em si, quando sem uso consumem recursos insignificantes dos equipamentos nos quais se encontram instalados (na verdade, o próprio banco-de-dados utilizado como catálogo consome mais recursos).

Dessa maneira, existem relatos de operação do Director do Bacula em equipamentos com processador Pentium 233 MHz e 128 MB RAM (sendo que a base do catálogo se encontrava em outro equipamento).

Já um servidor completo do Bacula (Director com banco, storage e File Daemon instalados), já esteve em produção num computador com processador AMD Athlon 500 Mhz e 512 MB RAM.

Foi testado, durante a pesquisa, o funcionamento do Bacula em máquinas virtuais com menos de 512 MB RAM.

Entretanto, vale ressaltar, que a performance do backup está diretamente ligada à capacidade de transferência de dados entre os dispositivos de rede, discos, armazenamento, etc.

4.6. Dispositivos de Armazenamento Compatíveis

O Bacula suporta o uso de praticamente qualquer dispositivo de armazenamento (fitas magnéticas, robôs-de-fitas, gravadores de DVD, etc.), desde que reconhecidos pelo sistema operacional.

A comunidade mantém listas²⁶ de dispositivos que já foram testados por usuários – entretanto, existem muitos outros modelos que são utilizados, mas que não estão consolidados nestas listas.

Outro aspecto importante consiste na customização da ferramenta – que permite a mudança de parâmetros como o tempo entre comandos enviados a determinado robô-de-fitas, corrigindo possíveis erros decorrentes da sobreposição de instruções – que variam de acordo com cada modelo.

4.7. Recuperação de Desastres

O Bacula, para Linux, possui uma solução nativa para a restauração de servidores após uma perda completa de informações no disco (exemplo: troca de HD). Consiste na gravação de um CD inicializável, que permite: o particionamento do disco-rígido da maneira como era antes do desastre; a configuração da interface de rede; a configuração do “cliente” Bacula (File Daemon) e, ainda, a restauração dos backups mais recentes para a restauração dos respectivos serviços.²⁷

Para os sistemas operacionais Windows, o Bacula dispõe de um plugin que permite a interação com o software BartPE, ferramenta esta que cria, de igual sorte, um disco inicializável e permite a restauração do sistema.²⁸

LABORATÓRIO DE BACKUP DE APLICAÇÕES EM PRODUÇÃO NO SERPRO

5.1. Backup de Máquinas Virtuais

Em relação às máquinas virtuais “XEN”, uma das estratégias adotadas consistiu na instalação de um cliente do “Bacula” em cada uma das máquinas virtuais – ou seja: tratá-las como se fossem máquinas dedicadas (físicas), que consiste em um dos procedimentos indicados pelos desenvolvedores de ferramentas de virtualização.

A dificuldade residiu 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, no caso do XEN²⁹.

Assim, foi pesquisada e implementada a seguinte metodologia:

1. 1. 1. Pausa da Máquina Virtual Xen para a cópia dos arquivos.

Entretanto, a desvantagem desse processo é óbvia: a indisponibilidade temporária da máquina virtual. Então, surge outra alternativa:

1. 1. 2. Pausa do “domU³⁰” utilizando o comando “xm pause” (script RunBeforeJob do “Bacula”). Precedido dos seguintes procedimentos:

1. 1. a) Sincronização do “domU” utilizando o comando “xm sysrq” (num segundo script “RunBeforeJob”).

1. 1. b) Realização de “backup” das configurações do Xen e do arquivo correspondentes à máquina virtual.

1. 1. 1. c) Continuidade do “domU” através do comando “xm unpause”

Segundo o desenvolvedor, este “backup completo” da máquina virtual poderia ser executado numa periodicidade menor (Ex.: semanalmente ou mensalmente).

Em relação às máquinas virtuais do “VMWare”, surgem duas opções:

1. 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:

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

2. Métodos Tradicionais

O método tradicional de “backup” (indicado pela documentação do desenvolvedor) 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).

5.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 seja, o banco não pára), muito útil para grandes bases.

Consiste na ativação da funcionalidade WAL (write ahead log) do Postgresq, permitindo que o banco seja colocado em “modo backup”, através de scripts executados antes e depois dos jobs de backup – garantindo uma cópia integra dos dados.

Já para o MySQL,entretanto, as pesquisas apontaram, como única possibilidade, a utilização da funcionalidade de dump – que realiza um espelhamento fiel das informações do banco, mas que deixa suas transações pendentes durante sua criação.

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 funcionalidade³² 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.

5.3. Servidores Web

Um cliente Windows do Bacula será capaz de copiar o conteúdo dos arquivos do IIS (Internet Information Services) sem nenhuma dificuldade³⁴ – 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.

5.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³⁵.

Para a aplicação Zimbra, os próprios desenvolvedores divulgam scripts, na sua página “wiki”³⁶, para backup através do Bacula.

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.

Com a possibilidade da execução de pré-scripts, informados inclusive pela documentação oficial da ferramenta disponibilizada no site da comunidade³⁷, mostrou-se plenamente viável o uso do Bacula.

5.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³⁸.

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³⁹.

OUTRAS FERRAMENTAS DE BACKUP ANALISADAS

6.1 Ferramentas Open-source

Uma das mais antigas ferramentas livres para backup, sendo a terceira mais popular do Sourceforge atualmente, é o Amanda.

“O Amanda, acrônimo para Advanced Maryland Automatic Network Disk Archiver, é um sistema de backup 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 ótico (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 backup de sistemas Microsoft Windows. Esta foi por muito tempo a mais popular ferramenta livre para realizacção e gerencimento de backups, e ainda hoje é 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 já citada seleção natural que rege a popularidade dos softwares livres de espécies semelhantes. As principais desvantagens relatadas dizem respeito à dificuldade de operação e de implementação de um esquema customizado de rotação de fitas (ex.: esquema GFS) – mas que vem sendo melhorado, principalmente impulsionado pela versão comercial de suporte, denominada Zmanda. Desde 2006, a comunidade do “Bacula” já possuía mais que o dobro de downloads que o Amanda.

Nas pesquisas realizadas, ainda, não foram encontradas interfaces gráficas estáveis para uso do Amanda – o que constitui motivo de resistência para usuários. A documentação, de igual sorte, não se mostrou tão completa quanto à do Bacula.

Já o BackupPC, outra popular alternativa livre, teve seu desenvolvimento em “perl” direcionado para que pequenas e médias empresas realizem backup de seus desktops, servidores e laptops. A ferramenta possui uma interface de configuração baseada em CGI/Web.

Não pode ser considerada solução completa de backup ­ por necessitar de algumas ferramentas de terceiros (smb, rsync, ssh e tar). Entretanto é bastante robusto, trazendo uma filosofia diferenciada para garantir uma cópia rápida e eficaz dos dados da rede: o hardlink.

De acordo com [PRESTON, 2007],o hardlink consiste numa combinação de métodos utilizados pelo BackupPC para reduzir o espaço total usado pelos arquivos copiados. Após o primeiro backup full, todos os arquivos são transferidos em segundo plano na base do BackupPC, comprimidos e comparados. Arquivos idênticos são linkados para utilizarem somente uma entrada adicional nos diretórios. Ou seja, podem efetuar-se cópias de 10 servidores Windows 2003 Server, com 20GB de informações cada, e com 10GB de dados repetidos em cada um deles (arquivos binários do sistema operacional, atualizações, etc). Sendo assim, seriam necessários 200GB de espaço para armazenamento. Porém, somente 110GB seriam utilizados (10x 10 GB + 10GB).

Este é um processo extremamente útil para a economia de espaço em discos. Porém, o BackupPC pode perder-se nos hardlinks quando se tem um volume muito grande de informações – pecando no requisito “escalabilidade”.

Vale salientar, que o “Bacula” também trouxe, na versão 5.0 ou superior, o controle de arquivos duplicados para a economia de dados.

Ainda, foram descartadas as ferramentas livres afbackup, Mondo, UBT, por não não atenderem a diversos dos pressupostos e requisitos retromencionados (exemplo: suporte à maioria dos dispositivos de armazenamento), ou por não estarem suficientemente maduras para o uso corporativo.

6.2 Ferramentas Proprietárias

a) 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 aprisionamento tecnológico e limitando as ações do administrador de rede.

A console do administração do “Arcserve”, apesar de bastante funcional, requer uma máquina possante, bem como uma boa largura de banda entre ela e o servidor para que o desempenho operacional seja satisfatório.

O licenciamento do “Arcserve”, além de parecer demasiadamente “caro” (entre U$ 400 e milhares de dólares), é historicamente dividido por funcionalidades – ou seja: cada vez que um novo recurso lançado pelo fabricante (Computer Associates), só pode ser utilizado pela aquisição de licença específica.

O catálogo (banco de dados) do ArcServer possui um formato proprietário e não SQL – o que caracteriza um real problema se o banco corromper e a rotina de reparação automatizada do sistema não funcionar.

Num comparativo de funcionalidades da versão 12.5 do Arcserve, observa-se que não houve muita inovação no âmbito de suas funcionalidades, em relação às versões anteriores.

O carro chefe deste exemplar (mais atual), é a funcionalidade que evita o backup de arquivos duplicados, embarcada na versão mais simples do software. Entretanto como já citado, algumas ferramentas livres já possuem este recurso.

O formato de gravação é proprietário e fechado – ou seja: os dados gravados só podem ser restaurados com a ferramenta, dificultando inclusive a preservação de legados e trabalhos de migração.

Não foram encontrados dados sobre teste de stress devido à quantidade de objetos armazenados.

b) TSM (IBM Tivoli)

Trata-se de uma ferramenta com bastantes recursos e, em certo ponto, similar ao “Bacula”. Ainda, se mostra mais completo no suporte ao backup da solução Active Directory, da Microsoft. Assim como o Bacula e o Amanda, suporta mais de 1.000.000.000,00 (hum bilhão) de objetos armazenados e utiliza banco de dados SQL.

Como pontos negativos pesquisamos dificuldades na solução de problemas / “bugs” (existem casos reais dentro da empresa de ocorrências sem solução) e suporte a diferentes dispositivos de armazenamento não tão abrangente (não suporta gravação em mídias ópticas, como exemplo). A principal desvantagem, que eliminou a possibilidade de uso, residiu na ausência de uma versão para Debian – importante sistema operacional Linux utilizado em servidores.

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 – 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 tecnológico).

Também utiliza um formato proprietário de armazenamento.

c) Arkeia Network Backup

O Arkeia, das ferramentas proprietárias, se mostra a única a suportar mais de 100 distribuições Linux. Possui recursos para o backup de aplicações bem específicas como o eDirectory da Novell e o Vmware.

Esta solução se mostra, entretanto, deficiente em alguns quesitos básicos como a realização de backups no disco local do servidor⁴⁰.

Consiste em outra solução que depende de si para a restauração dos dados gravados – ao contrário do Bacula e Amanda (livres), por exemplo.

Não foram encontrados dados sobre testes de escalabilidade – o que pode ser temerário para aplicação em data-centers, por exemplo.

A licença para o Servidor pode ser adquirida a partir de 950 euros, mais 60 por cliente⁴¹.

d) Veritas Netbackup

Possui compatibilidade limitada em relação a Sistemas Operacionais (ex.: falta de suporte para o BSD e MAC OS). Além disso, não oferece o atrativo das outras soluções que consiste nos agentes específicos para aplicações importantes como bancos PostgreSQL, Vmware, etc.

O custo elevado com licenciamento, entretanto, consiste num fator negativo. Um pacote com 5 clientes (mais servidor e módulo de armazenamento), está orçado em 6.500 euros.

Armazena dados em formato proprietário e não foram encontrados testes de escalabilidade.

DA GESTÃO DO SOFTWARE LIVRE

Além de estar alinhado ao planejamento estratégico governamental, a adoção do software livre consiste em uma tendência universal no mundo de TI.

Segundo a “Gartner Group” – empresa de consultoria especializada em TI, a “tecnologia open source será indispensável no futuro”. Segundo pesquisa: “até 2011 pelo menos 80 % de softwares comerciais terão quantidades significativas de código-fonte aberto”.

“A pesquisa mostrou porque daqui a poucos anos, 80% dos softwares comerciais contarão com quantidades significativas de código fonte aberto. O estudo revelou que as ferramentas free estão alterando a indústria de softwares licenciados e comenta que alguns fornecedores já adotaram o sistemas sem licenciamento para obtenção de vantagem competitiva.”⁴²

Ainda, a companhia sugere os fatores que devem ser levados em conta na escolha da solução, quanto ao licenciamento:

“1. Se software atende a sua finalidade;

2. Se o produto de ferramenta free fornece uma relação aceitável de risco/recompensa;

3. Conferir o perfil de tecnologia que a sua empresa adota atualmente;

4. Certificar se o software cumpre suas exigências;”⁴³

Do modelo proposto, depreendeu-se que o Bacula atenderia a todos estes requisitos. As análises de funcionalidades, testes preliminares, definitivos e produção, demonstraram que a ferramenta possui plena viabilidade e que, em alguns quesitos (performance, funcionalidades, flexibilidade, etc.), supera o software proprietário análogo.

a) Durabilidade das Soluções Livres:

Existem outros aspectos que encorajam a escolha do software livre. Uma delas, reside no fato de que as “bolhas” de desenvolvimento dessas ferramentas tendem a ser muito longas – ou seja: há uma melhoria constante e uma continuidade no trabalho de desenvolvimento (busca-se que as diferentes versões sejam compatíveis). No caso do software proprietário, existe o interesse em sempre serem lançadas novas versões para a aquisição do cliente e, algumas vezes, não há a mencionada preocupação com a interoperabilidade.

A principal característica do Estado é a sua longa duração. Portanto, os sistemas computacionais que o atendem também devem ser planejados em longo prazo.

Diante disto, percebe-se que o modelo de desenvolvimento proprietário comercial – desenvolvido por empresas privadas, não está alinhado à durabilidade do estado, na medida que exige um dinamismo nas aquisições para que se perpetue, além de fatores mercados que podem extinguir o negócio – deixando o Estado desamparado em relação ao suporte e continuidade da tecnologia.

b) Caráter Social do Software Livre:

O software livre possui um forte caráter social, segundo o qual não seria “ético aprisionar conhecimento científico, que deve estar sempre disponível, para assim permitir a evolução da humanidade.” e, desta forma, as Empresas públicas teriam um papel fundamental como representantes do governo, em difundir e fomentar este tipo de tecnologia.

Segundo Richard Stallman, fundador do movimento software livre, do projeto GNU, da Free Software Foundation (FSF) e autor da General Public License (GPL) – a licença livre mais usada no mundo, que consolidou o conceito de copyleft:

“O software livre garante as liberdades de conhecer, criar, compartilhar e distribuir sem limites”, afirmou Stallman. “Portanto, as tecnologias proprietárias são uma transgressão aos direitos constitucionais”, completou. “A meta do movimento é eliminar barreiras e destruir injustiças. A imposição tecnológica está a um passo da imposição ideológica”, definiu.

c) O Software como Bem Intangível:

Destaca-se também, que o simples uso do software faz com que ele adquira valor, na medida que mais pessoas passam a adquirir conhecimento sobre ele, trocar informações inteiramente compatíveis e fornecer feedback para os desenvolvedores (relatos de bugs, sugetões, etc.). Desta maneira, além de fornecer valor imediato ao programa, é formado um círculo incentiva a perpetuação e a melhoria contínua daquela.

“O usuário, que representa a demanda, poderá contratar serviços para melhorar o software. E quando o software é utilizado por uma base maior de usuários significa que posso aumentar a quantidade de serviços prestados pela área de TI, o que seria assim um impacto externo. Um software da área de saúde chegando mais rápido a centenas de prefeituras pode gerar uma qualidade extrínseca ao bem, decorrente da melhoria do serviço de saúde prestado para o cidadão. Entendemos, neste caso, o serviço de saúde como o ambiente lateral, aquele que gera um impacto extrínseco.” – Corinto Meffe, em sua coluna na Computerworld⁴⁴.

d) O Conhecimento do Código Fonte:

A possibilidade de customização da ferramenta oriunda do conhecimento do código, bem como documentação livre, permitem que qualquer pessoa se especialize em determinado software livre e preste suporte (consultoria, treinamento, etc.). Ou seja: os empregados gerados para o desenvolvimento de softwares proprietários, tradicionalmente localizados, em sua maioria, nos países desenvolvidos, passam a ser gerados em todo o mundo. Dessa maneira, a Empresa que utilize ferramentas livres terá maior facilidade em conseguir suporte, ainda que empresas prestadoras venham a requerer falência ou por algum motivo não possam fazê-lo. No modelo proprietário geralmente há um monopólio ou um mercado restrito de profissionais capacitados nos respectivos sistemas.

e) Benefícios Motivacionais:

Apesar de qualquer mudança de software geralmente resultar em uma resistência do usuário, o uso de ferramentas livres pode trazer uma série de benefícios motivacionais – e resultar em inovações para a empresa.

Segundo os pesquisadores Lakhani e Wolf⁴⁵, a maioria dos colaboradores de projetos com código aberto no SourceForge.net, relatam que o desenvolvimento colaborativo seria uma das experiências criativas mais importantes de suas vidas. Outra parcela considerável, afirma ainda que contribui para comunidades por diversão, estímulo intelectual, melhoria nas habilidades de programação e a crença na ideologia dos projetos livres / abertos. Seriam quatro os tipos básicos de colaboradores das comunidades:

“1. Aqueles que expressaram diversão e aprendizado como motivadores primários;

2. Aqueles que simplesmente precisam do código para satisfazer necessidades não ligadas a trabalho;

3. Aqueles que tem necessidades ligadas ao trabalho e preocupam-se com a carreira;

4. Aqueles que tem gratidão com a comunidade e acreditam que o software deve ser livre ou aberto.” – de acordo com os resultados da mesma pesquisa.

O grande mérito das comunidades de software livre reside no fato de que pessoas com diferentes motivações podem coexistir e colaborar – gerando benefícios para todos. Portanto – o uso de FOSS (sigla bastante utilizada para designar software livre/aberto – Free/Open Source software Development) pode trazer motivação e estimular a inventividade das partes interessadas dentro das corporações.

f) Qualidade das Soluções Livres

Autores como Neumann defendem que o software livre não é necessariamente melhor que o análogo proprietário – mas possuem potencial para ser. Outros como Anderson, abordam as questões de segurança oriundas do conhecimento do código. Se por um lado esta publicidade poderia fazer com que um agente mal intencionado tenha conhecimento de determinada falha, por outro permitiria que qualquer pessoa da comunidade a corrigisse de maneira muito mais rápida. Desta forma, as vulnerabilidades de segurança seriam mais rapidamente sanadas. Prova disto, é que a base de dados do Clamav (solução livre), possui as mais rápidas atualizações contra vírus recém-descobertos.

O mais popular navegador de Internet livre, o Firefox, possui uma série de prêmios como melhor ferramenta do gênero⁴⁶ – principalmente no crítico quesito da segurança. O serviço web Apache – que também depende do quesito segurança, está presente em diversas grandes empresas pelo mundo, fornecendo acesso a seus sites (inclusive o Google).

Diversas pesquisas, de igual sorte, apontam que o sistema operacional de código aberto mais utilizado – o Linux, seria mais seguro que o seu principal concorrente – o Windows. Um estudo feito pelo site The Register⁴⁷ comparou as 40 últimas vulnerabilidades e patches de correção tanto de um servidor Windows como em um Red Hat Enterprise Linux.

“Avaliando as características de cada brecha, os autores levaram em conta os seguintes fatores: o nível de importância de cada falha, com seu risco em potencial, ou seja, a capacidade de danos que cada um pode causar; a facilidade com que o cracker consegue executar o exploit; o grau de exposição do código malicioso, verificando qual nível de acesso o criminoso precisa para rodar o script e, para completar, foi verificado o número de vulnerabilidades críticas que apareceu em cada sistema operacional.”

Resultado: quase 40% das vulnerabilidades analisadas no Windows pertenciam ao nível crítico, enquanto no Linux, apenas 10% das brechas estavam nesta esta categoria. De acordo com os autores da pesquisa:

“…tais resultados são até generosos com a Microsoft e, especialmente duros com a Red Hat, já que eles se baseiam nas qualificações da companhia de Bill Gates, e não na aplicação estrita de métricas próprias.”

O fato é que – mesmo nos dias atuais, o uso do Linux dispensa a instalação de qualquer anti-vírus – e os índices de contaminação são praticamente inexistentes, ainda mais com a quantidade de máquinas da plataforma Microsoft “zumbis” que estão conectadas à Internet. São computadores infectados utilizados principalmente para ataques⁴⁸ de força bruta contra outros sistemas computacionais.

g) Modelos Econômicos e de Negócio Baseados no Software Livre

Os autores Tapscott e Williams⁴⁹ do famoso livro Wikinomics, realizaram um extenso estudo de como empresas modernas se utilizaram da colaboração em massa (um dos pilares do software livre) para obterem sucesso. Segundo eles, seria uma extensão do negócio – espécie de terceirização, mas neste caso com funções abertas para que agentes individuais participem de maneira colaborativa para melhoria ou solução de um problema.⁵⁰

As grandes e tradicionais empresas da área e informática não estão indiferentes ao software livre, como a IBM, por exemplo, que liberou código de soluções, provê suporte dos seus equipamentos para ambientes livre e divulga documentações relativas ao Linux (ex.: Tutoriais para a Certificação LPI⁵¹).

Segundo o autor César Taurion: “O software livre já não é mais apenas um brinquedo nas mãos de hackers, mas já faz parte da agenda política e estratégica de empresas privadas e públicas. É um negócio sério e profissional.”

“As discussões dos méritos e desafios dos softwares livres versus softwares proprietários têm sido uma constante. O tema também está entrando na agenda política dos governantes dos diversos países e blocos econômicos.” – reafirma o autor.

Software livre é um modelo de negócios no qual ocorreu uma mudança de paradigma. Não é mais a licença do software que é cobrada. Esta sim – nociva, pois evita o conhecimento do código para que qualquer pessoa o aperfeiçoe.

“A liberdade que o software livre dá às organizações resulta em agilidade nos seus negócios. Não podemos abrir mão de conhecer o insumo básico, que é o conhecimento em tecnologia da informação, o que só é possível no mundo do software livre e aberto.” entrevista do Sr. Marcos Mazoni, presidente do SERPRO.

Atenta para as potencialidades do trabalho colaborativo, a Apple – quando do lançamento do Iphone, liberou algumas “API” (ou Interface de Programação de Aplicativos) para que qualquer pessoa pudesse desenvolver códigos para seu aparelho. Além disso, criou um “website” no qual os softwares desenvolvidos por terceiros pudessem ser disponibilizados (gratuita ou onerosamente). O simples fato de disponibilizar este espaço, rende à empresa milhões de acesso diários, uma maior versatilidade para seu produto (novas aplicações = valor agregado), interação com os usuários e marketing – ou seja: grande retorno a partir do trabalho de uma comunidade.

Outra iniciativa popular recente de grande repercussão (não ligada a software) foi a comunidade criada pela empresa de veículos automotores “FIAT”. Trata-se de uma rede social como o objetivo de projetizar um veículo de maneira colaborativa. Assim, os usuários ganham destaque de acordo com as ideias enviadas e como elas são recebidas pelo grupo. Vale salientar que todo o projeto, bem como as contribuições, estão licenciadas como “Creative Commons” – o que garante a liberdade de uso por qualquer pessoa. Pode-se perceber que a filosofia livre está irradiando efeitos até para áreas até então totalmente proprietárias. E se fosse por esse caminho, não poderíamos deixar de falar da Wikipédia (considerada a enciclopédia mais precisa do mundo) e que também é desenvolvida colaborativamente…

CONCLUSÃO

Do exposto, depreende-se que o modelo tecnológico do backup centralizado, aliado com a adoção de uma ferramenta livre madura como o “Bacula”, representa uma das maneiras mais econômicas em realizar cópias de segurança, tanto nos aspectos patrimoniais quanto nos processuais / gerenciais.

A centralização permitiu uma visibilidade gerencial unificada – muito mais confiável e ágil. Em apenas uma página do navegador de web seria possível quais trabalhos de backup não foram executados com êxito nos servidores. Facilitou, ainda, que a empresa se adequasse às normas ISO, pois os servidores de cópias atuais (modelo centralizado) não dispunham de cofres anti-chamas para o armazenamento de mídias, equipamentos que possuem um custo elevado. O modelo centralizado permitiu o armazenamento das cópias de segurança em local diverso dos dados originais – protegendo contra incidentes físicos de grandes proporções.

Permitiu a criação de um “backup em nuvem”, aderente à nova grande tendência de TI. “Cloud computing” (computação em núvem) – que é a expressão do momento. “Nomes de peso como Amazon, AT&T, Dell. HP, IBM, Intel, Microsoft e Yahoo já anunciaram planos e investimentos na área e o Gartner acaba de liberar um relatório que aponta o cloud computing como uma das três mais importantes tendências emergentes nos próximo três a cinco anos.”1 – segundo reportagem do site IDG Now [*]. Neste aspecto, o serviço de “backup” remoto se mostrou plenamente viável, inclusive com possibilidades de tráfego via Internet – desde que os dados sejam protegidos por VPN.

Os custos com controle e aquisição das licenças – até então proprietárias, foram eliminados. Estas e todas as outras já citadas vantagens técnicas e de gestão, em sua maioria, advém da adoção de uma solução livre – verdadeiro aliado na resolução dos problemas operacionais – principalmente no que toca a integração com outras ferramentas.

Os governos, historicamente, sempre foram os maiores consumidores de software proprietário enquanto setor da sociedade, e o SERPRO – Serviço Federal de Processamento de Dados, enquanto empresa pública, vem agindo como usuário, desenvolvedor e fomentador de tecnologias livres – que em sua essência seriam patrimônios universais.

A escolha do Bacula, se mostra mais acertada e ainda com maior importância se analisarmos o aspecto legalista constitucional dos gastos públicos. Estes, devem ser feitos dentro do princípio da “eficiência” – ou seja: fazer mais com menos. Se uma solução proprietária fosse adquirida, no momento em que existe uma similar livre que realiza as mesmas funções, com performance igual ou superior, então, ocorreria uma lesão ao patrimônio público.

“Eu já disse isso publicamente em muitos lugares fora do Brasil: eu acho que o Brasil é uma estrela brilhante no software livre. A comunidade, a indústria e o governo trabalham junto com alguma freqüência para resolver problemas. A comunidade, os empresários e o governo trabalham junto para patrocinar conferências de software livre, o que considero muito importante. Eu acredito que o governo está encorajando empresas a pensar diferentes formas de vender software, vender serviços. Desta forma, os empresários podem fazer a transição de um modelo de software proprietário, de código fechado, para um software livre, de código aberto. E eu reforço essa questão do software livre, porque na verdade conheço muitas empresas que fizeram mais dinheiro com software livre do que faziam com software proprietário “de caixinha”⁵². – Jon Maddog Hall, um dos pioneiros do software livre.

REFERÊNCIAS:

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.

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.

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.

COMUNIDADE EXPRESSO. Rotina de Backup. Disponível em: http://www.expressolivre.org/html/expressolivre/downloads/documents/rotinadebackup.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.html 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.

Disponível em: Português