17 dezembro 2007

Voltando a blogar e início de novo projeto

Depois de um bom tempo sem postar nada aqui graças a um período de trabalhos e provas na faculdade, entre outras coisas, estou voltando a postar no blog.

Como disse no post anterior, estou em um novo emprego e, também, um novo foco na carreira. Com o cargo de analista de sistemas meu trabalho será muito mais voltado a desenvolvimento do que a administração e suporte a sistemas. Por conta disso o foco do blog também irá mudar. Podem esperar um grande aumento na quantidade de posts a respeito de Java e de desenvolvimento em geral.

Embora esteja trabalhando na área de informática que mais goste (desenvolvimento), a tecnologia que irei utilizar aqui não me deixa nada contente. O sistema ERP aqui utiliza ainda o VisualBasic 5. Apesar disso, estou tive tempo para desenvolver um pequeno programinha em Java aqui na empresa, e pretendo começar um projeto pessoal em casa utilizando Java, aproveitando as férias da faculdade e que possivelmente será a base do meu TCC (sim, já estou pensando nisso).

O projeto que pretendo desenvolver é um sistema de backup em Java. Dois motivos principais me levaram a pensar nesse projeto:

1 - Com a experiência adquirida com o Bacula, percebi que ainda não existe uma ferramenta de backup realmente eficaz de código aberto (sim, será um projeto de código aberto ;-), levando-se em conta facilidade de instalação, facilidade de configuração e praticidade de uso, além do que existem muitos pontos que poderiam ser alterados no Bacula;

2 - O segundo motivo é que, apesar de ter um contato um pouco grande com a tecnologia Java, eu não tenho experiência com a linguagem, nem mesmo conheço a fundo tudo o que ela pode oferecer, então um projeto como esse poderia me trazer uma experiência muito boa com a linguagem.

Não sei se Java seria a melhor tecnologia para se desenvolver um sistema de backup, principalmente se levarmos em conta que pretendo desenvolver um sistema multi-plataforma (entenda-se Linux e Windows). Java, até por onde eu sei, tem muitas limitações em acesso a hardware, sendo necessário a utilização de bibliotecas que provêem acesso a API do sistema operacional, que nem sempre são fáceis de usar. Por esse e outros motivos pode ser que o desenvolvimento desse projeto seja bem complicado, ou até mesmo inviável, porém nada melhor que um bom desafio para estimular o aprendizado.

Durante o projeto entrarei em contato com muitas tecnologias e bibliotecas interessantes do mundo Java, como entrei em contato com o HSQLDB, o JCalendar, o JGoodies Forms e Looks e o JFreeReport que utilizei em pequenos projetos desenvolvidos nesses últimos meses. A medida do possível irei postar pequenos tutoriais sobre essas utilidades, e o que mais for entrando em contato.

16 outubro 2007

Um novo desafio

Após aproximadamente 6 anos e meio trabalhando em uma empresa onde comecei como auxiliar de informática e aprendi 50% do que sei relacionado a informática (e muita coisa sobre outras áreas profissionais), pedi demissão e estou indo trabalhar em outra empresa onde pretendo passar mais alguns anos.

Ao contrário do que muitos podem pensar o motivo dessa mudança é mais profissional do que financeira, já que a diferença de salário não é tão grande para justificar a saída de uma empresa para a outra. Mas profissionalmente estou tendo uma grande mudança.

Em primeiro lugar, não é fácil sair de um lugar onde se tem uma certa estabilidade (não, eu não era funcionário público), conhece bem o sistema da empresa, conhece bem a empresa, etc, e ir para um lugar totalmente novo (ou seja, sair do comodismo), principalmente quando é a primeira vez que você faz isso. Só isso já é uma grande experiência, e um dos motivos de minha mudança foi para viver essa experiência.

Um outro motivo para a mudança é a possibilidade de aprendizado. Por mais que eu ainda pudesse aprender coisas novas onde eu estava, essa possibilidade é ampliada em uma nova empresa. Tudo é novo, as pessoas são novas, as políticas da empresa são novas, a mentalidade das pessoas na empresa é nova. Enfim, com tantas novidades o natural é assimilar tudo isso e unir com os conhecimentos anteriormente adquiridos e formar novas ideias. Isso é ou não é bom?

O desafio de ir para uma empresa que esta começando suas atividades sempre me atraiu, e esse é o caso agora. É muito bom ver a empresa se erguendo (as vezes literalmente), é uma fase onde se tem muito trabalho e se pode aprender muito com a experiência.

Enfim, mudar de emprego, mudar de ambiente, pode ser muito bom, principalmente se é uma decisão que nós mesmo tomamos. Acredito também que permanência em um mesmo posto de trabalho por muito tempo (entenda-se mais de 10 ou 15 anos) pode ter consequências ruins como, por exemplo, um grande comodismo com sua situação na empresa e com a situação da própria empresa, ou seja, não procuram inovar nada achando que tudo esta bom do jeito que esta. Imagine agora uma empresa onde várias pessoas tem essa mentalidade... Acho que não preciso dizer mais nada.

Então é isso, estou partindo para uma nova empresa, um novo desafio. Esperto ser tão bem sucedido no novo trabalho quanto fui no anterior. E até a próxima.

15 outubro 2007

De volta ao Slackware

Bom, depois de passar por distribuições mais "amigáveis" como as ultima versões do KUbuntu e o Kurumin, resolvi voltar ao Slackware, desta vez a versão 12.

Sai do Slackware para buscar fascilidade de administração, mas as travas que outros gerenciadores de pacotes impõem são bem mais difíceis de acertar do que a falta de verificação de dependência do tgz.

Isso não significa que deixei de achar que o Slackware precisa de um gereciador de dependências, só acho que um bom gerenciador de dependências deveria ter flexibilidade e deixar escolher se o usuário quer realizar a operação ou não quando uma dependência não for satisfeita.

Outra coisa que acho é que a distribuição deveria escolher apenas um pacote de cada categoria, evitando de instalar vários pacotes que nunca serão utilizados pois existem outros iguais que são utilizados.

Mais um ponto que gosto de ressaltar: por que colocar vários softwares num mesmo pacote? Peguemos o pacote kdenetwork, existem vários aplicativos dentro dele, porém nem sempre utilizamos todos, mas se queremos instalar somente um dos aplicativos somos obrigados a instalar o pacote todo, ou seja, instalar vários softwares que não queremos. Deveria ser feita uma distribuição mais racional desses aplicativos, mesmo que seja para criar um pacote para cada aplicativo.


Agora deixe-me voltar a personalizar o Slackware.

12 outubro 2007

Tim Web

Bom, depois de ter dito que iria postar com mais frequência e não cumprir, estou eu depois de um bom tempo para um pequeno post.

Adquiri o Tim Web, plano de dados da Tim. Como em minha casa não chega nenhum serviço de banda larga, a não ser por rádio mas o preço é absurdamente caro, resolvi pegar o serviço da Tim, por casa do acesso discado aqui ser sofrível, tanto em velocidade quanto em dificuldade para conexão. Além do mais, é meu primeiro passo para me livrar de uma certa empresa picareta (acredito que muitos concordem comigo), o próximo passo será a telefonia fixa. Estou a poucos dias com o serviço, mas já posso dar uma pequena avaliação.

Em primeiro lugar, o próprio aparelho, fisicamente falando. Seu tamanho, praticamente o mesmo de um celular básico, bem fino, é fácil de ser transportado, cabendo até mesmo no bolso. Traz 2 cabos USB, o primeiro é mais voltado para ser usado com o notebook, sendo bem curto, cerca de uns 20 cm de comprimento. Já o segundo tem cerca de 80 cm de comprimento e uma particularidade: 2 plugs USB para serem ligados no computador. Não sei exatamente para que isso serve, mas é no mínimo curioso.

A instalação do modem é muito simples, tanto em ambiente Windows quanto Linux. No Windows, basta plugar o modem no computador e em segundos irá aparecer automaticamente o progama de instalação do modem e do discador, ao melhor estilo Next...Next...Finish. No Linux é um pouco diferente, mas não chegar a ser menos fácil, basta seguir esse pequeno tutorial que tudo irá funcionar. Acredito que funcione na maioria das distribuições, no Slackware 12 foi sem problemas, mas no Kurumin 7 reclamou da versão de uma biblioteca que não me recordo agora qual é. Só uma dica, quem usa KDE pode ser usado o Knemo para monitoramento dos dados. Acredito que a maioria das distribuições distribuam esse aplicativo.

Quanto a conexão, bom, não é exatamente a coisa mais rápida que já via, mas para quem vivia de conexão discada já é o suficiente. Explicando melhor, na minha cidade a única tecnologia para conexão é a GPRS, que chega ao máximo de 60 Kbps, se estivesse disponível o EDGE poderia chegar a 200 Kbps, mas como eu disse, pra quem esta saindo da conexão discada... Só resta esperar que a rede EDGE chegue aqui ;-) Em relação a estabilidade da conexão, sem problemas, é bem estável. Pode até cair hora ou outra, mas a conexão é feita em 3 ou 4 segundos, nada que aborreça muito.

Conclusão: é um ótimo serviço para quem ainda sofre com conexão discada, embora o preço seja meio salgado para quem só consiga conexão com GPRS. Não é, ainda, uma opção de banda larga para concorrer com os serviços tradicionais, embora 200 Kbps da conexão EDGE possa concorrer com o speedy mais básico. Eu disse "ainda" pois tem uma previsão de chegada da tecnologia 3G para celulares para meados de 2008 (isso se o leilão for realizado ainda esse ano) e o modem fornecido pela Tim parece estar preparado para 3G. Resta esperar que a politicagem não atrapalhe muito mais e que a atualização tecnológica não fique só nos grandes centros.

16 setembro 2007

Metodologia de ensino

Depois de um bom tempo sem postar nada, estou eu aqui de volta... Nas ultimas semanas estive sem tempo e principalmente sem inspiração para postar alguma coisa aqui. Mas agora pretendo voltar a escrever mais regularmente.

Bom, pra recomeçar vou falar um pouco sobre a experiência de voltar para uma sala de aula de um curso de grande duração (faculdade) depois de 6 anos, nesse período o curso mais longo que fiz foi o de preparação para certificação Conectiva Linux, com duração de 8 meses. Estou no segundo semestre do curso de Ciência da Computação na Faculdade Comunitária do grupo Anhanguera Educacional que fica na cidade de Taubaté - SP.

Pessoalmente, acho a instituição boa, com ótimos professores (claro que sempre tem alguns não tão bom assim) e a infra-estrutura também é boa. Enfim, está no nível de qualquer outra universidade da região (exceto o ITA, mas o ITA é outra história).

A minha conclusão foi: por que diachos a metodologia de ensino não mudou desde que eu entrei pra o 1º ano do primário, ou seja, professor passa matéria, explica, passa exercícios, corrige e cobra tudo isso numa prova, muitas vezes sem consulta???? Vocês não acham que esta na hora disso mudar? Bom, eu acho que sim. E não estou falando somente da univesidade onde estudo, mas da maioria da universidades.

Pra começar, como trabalho com TI já faz mais de 6 anos (fora o tempo que "mexia" antes de trabalhar), assim como outros colegas, boa parte das coisas que estamos vendo na faculdade já são conhecidas, e outra boa parte é desinteressante, fazendo com que o interesse pelo curso vá a limites muito baixos. Tudo bem que ser dessa forma no começo é normal, pois existem alunos que nem sabem usar o computador direito, então é necessário passar a base para esses alunos. Mas o que desanima mesmo são as formas com que as aulas são dadas. O professor passar a matéria, explicar, passar exercícios, corrigir e cobrar numa prova não está de acordo com o ambiente de trabalho de qualquer empresa. E não adianta dizer que na universidade as coisas devem ser diferentes do ambiente de trabalho, afinal a faculdade é uma preparação para o mercado de trabalho.

Na minha opnião as aulas deveriam ser inspiradas no que os profissionais encontram no ambiente de trabalho, ou seja, nada de professor passando e explicando matéria e alunos só copiando e ouvindo o professor, e sim o professor dando uma introdução sobre o assunto, propondo um trabalho, e os alunos, em grupos que podem cooperar entre si, pesquisando sobre o assunto na biblioteca ou internet, dentro da sala de aula, e, claro, o professor de prontidão para tirar qualquer dúvida. Seria bem mais parecido com um ambinte de trabalho, e seriam aulas bem mais dinâmicas e bem mais aproveitadas, onde os alunos com certeza aprenderiam mais.

Esse é só um exemplo de como se poderia mudar a metodologia de ensino. Pode ser que isso não funcione na pratica, mas seria pelo menos um caminho para se começar a mudar.

Outro ponto que precisa ser melhor avaliado é o sistema de avaliação. Prova não prova nada, até mesmo por que é muito fácil de ser burlado (quem nunca colou que atire a primeira pedra:-). Seguindo a mesma linha que escrevi acima, poderiam ser dado trabalhos em grupos, com consulta mas sem ajuda do professor. Meu professor de lógica matemática se utiliza dessa metodologia, e funciona muito bem, apesar de ser apenas em dupla. Isso serve como prova, pelo menos para mim, de que esse método funciona.

Para terminar, mesmo cursando uma faculdade de tecnologia, o mais próximo que chegamos de tecnologia é o laboratório de informática, uma vez por semana na aula de programação. Eu acredito que a tecnologia deveria ser melhor utilizada em sala de aula, mesmo para cursos não ligados a tecnologia. Começando por recursos multemídia, chegando até a Web 2.0 (haha, achei que nunca iria achar um bom motivo para citar a tal da web 2.0 no blog), a tecnologia deveria ser melhor usada em todos os cantos onde se pudesse utilisa-la. Claro que isso não é fácil, mas deveriam ter incentivos das instituições para que os professores começassem a utilizar esses recursos em sala de aula, nem que seja para colocar um computador em cada mesa das salas de aula (isso teria um custo bem alto, mas também seria uma boa desculpa para subir o preço das mensalidades, interessante para as instituições).

Acredito que se cada um começar a cobrar um pouco isso dos professores e instituições poderia ser levantada a oportunidade de mudança... É ou não um assunto a ser debatido???

Só mais uma coisa, quem ainda não leu, leia este post do Nerdson, é muito interessante, principalmente os comentérios.

31 julho 2007

Desempenho do Slackware

Mais uma vez troquei a distribuição que uso. Sai da Zenwalk para o Kubuntu... Mas agora pretendo permanecer com essa distribuição, até mesmo por que a facul esta começando denovo e não terei tempo para outras trocas.

O motivo pelo qual troquei de distribuição foi relacionado com a simplicidade de se manter um sistema baseado no Debian atualizado, e a facilidade de instalar novos pacotes. Mas isso não vem ao caso agora.

O motivo deste post é que umas das primeiras coisas que notei quando inicializei o Kubuntu foi a diferença de performance em relação ao Slakware e demais distribuições baseadas nele. A diferença é gritante se comparada com o Zenwalk, ultima distribuição que utilizei antes do Kubuntu, principalmente na inicialização do sistema. Só para constar, os serviços inicializados nas duas distribuições são os mesmos.

Bom, acho que essa diferença de performance não é novidade para ninguém que conheça linux. A questão que eu queria levantar é, por que não existe uma distribuição grande baseada no Slackware????? Não é só por causa do desempenho que eu digo isso, mas Slackware é uma distribuição bastante madura, estável e simples, a única coisa que eu acho de errado no Slackware é o sistema de pacotes padrão, o tgz.

Já dei minha opinião sobre os gerenciadores de pacotes, acho que são necessárias algumas melhorias, mas isso era mais específico sobre o rpm e o deb, já o tgz precisa melhorar para ficar mais parecido com os outros dois citados, e sobretudo precisa ser adicionadas características melhoradas em relação a eles.

Mas deixando os pacotes de lado, imagine uma distribuição com as facilidades do (K)Ubuntu e o desempenho, simplicidade e flexibilidade do Slackware?? Alias, o Zenwalk chega perto, mas ainda falta o lance do gerenciamento de pacotes melhorado, o gerenciador de pacotes incorporado nele não é capaz de resolver dependências. Alguns puristas usuários do Slackware podem me xingar, mas meu sonho é ter um Slakware com essas características, mas é claro que poupando as características mais fostes do Slackware. Quem sabe um dia eu crie uma distribuição assim, quando me sobrar tempo... mas enquanto isso vou continuar com o Kubuntu, que me atente no momento.

11 julho 2007

Sobre pacotes e gerenciadores de pacotes

Estou fazendo outro teste com outra distribuição Linux, a distribuição Zenwalk. Esta distribuição é baseada no Slackware mas bem personalizada. Entre as principais personalizações, posso destacar o XFCE como gerenciador de janelas padrão, montagem automática de dispositivos USB (pelo menos no Slackwware 11 isso não existia), programa para detecção de redes wirelles, vários pacotes atualizados e muito mais. Mas a principal característica é que sua imagem "iso" tem pouco mais que 400 MB de tamanho, ou seja, um sistema completo que cabe em 1 CD, e sobra espaço. Mas meu objetivo não é falar sobre o Zenwalk, mas sim sobre sistemas de pacotes para Linux.

Instalei o Zenwalk por 2 motivos principais: é baseado no Slackware e é um sistema completo em um só CD. Mas como sempre, preciso personalizar a distribuição para que eu possa utilizar com mais comodidade, e faço isso instalando alguns pacotes e desinstalando outros. Nesse processo eu venho encontrado algumas coisas que poderiam ser melhorados no Linux em relação a instalação e desinstalação de programas.

1 - Para deixar o sistema do jeito que gosto instalei o KDE, onde os principais pacotes são: kdebase, kdeutils, kdelibs e o qt. Como ainda uso conexão discada, preciso de um discador (Zenwalk não traz nenhum), e o qual eu gosto é o KPPP. Para instalá-lo é preciso instalar o pacote kdenetwork, mas esse pacote traz vários outros programas que eu não uso. Conclusão, instalei vários programas que não preciso só por causa do KPPP. Sim, eu poderia instalar outro discador, mas gosto do KPPP ;-). Não é uma reclamação que estou fazendo aqui, mas acho que seria muito interessante se pudéssemos escolher quais programas dentro de um determinado pacote nós queremos instalar. Citei o pacote kdenetwork pois esse é um caso recente, mas existem vários outros casos onde isso ocorre.

2 - A maioria das distribuições Linux trazem aplicativos para facilitar a instalação e desinstalação de pacotes, como por exemplo o apt-get e seus derivados e similares. A principal função desses programas, como todos sabem, é buscar em repositórios os pacotes dos programas que você queira instalar, e resolver os problemas de dependências instalando os pacotes necessários quando for preciso. Isso funciona muito bem quando tudo esta dentro dos repositórios, mas quando o pacote e suas dependências não estiverem nos repositórios? A situação que imaginei é a seguinte:

Você quer instalar um software que esta empacotado e pronto para instalar, mas nem ele nem suas dependências são encontrados nos repositórios. Para instalar esse software você teria que procurar na internet as dependências dele, o que iria consumir bastante tempo. Mas o desenvolvedor saber onde encontrar essas dependências.

Com isso, imaginei que as informações de onde estão as dependências são colocadas dentro de cada pacote, e os gerenciadores de pacotes pegam essas informações e buscam esses pacotes automaticamente, seja lá onde eles estiverem, desde que se tenha uma conexão com a internet, claro. Isso eliminaria a necessidade de se manter repositórios cadastrados em nossos computadores e acrescentar mais um a cada vez que temos que instalar um pacote que não está nos repositórios cadastrados. Sei que isso não é uma idéia original, se não me engano no FreeBSD é assim, mas seria ótimo se isso fosse portado para o Linux, utilizando os formatos atuais de pacotes.

3 - Quando instalamos um pacote utilizando um gerenciador de pacotes, caso exista uma dependência não satisfeita, o gerenciador resolve essa dependência e as instala automaticamente. Mas o processo contrário não é feito, ou seja, ao desinstalar um pacote as dependências dele não são desinstaladas automaticamente, somente os pacotes que dependem dele. O ideal seria que todas as dependências do pacote que será desinstalado fossem desinstaladas também, desde que estas não sejam utilizadas por mais nenhum outro pacote, isso evitaria que ficassem pacotes que não são utilizados pelo sistema. Devo salientar que essas são conclusões a que eu cheguei, segundo o que eu pude perceber no meu uso diário, posso muito bem estar enganado, sendo assim, ignorem isso.

Mas para fazer tudo isso seria necessário criar um formato novo de pacotes, ou alterar os existentes hoje, que acredito que seja a melhor opção. Eu iria adorar desenvolver essas melhorias, mas infelizmente não tenho tempo para isso, me restando tempo somente de expor minhas idéias ;-). Mas também acredito que se fosse desenvolvido por um desenvolvedor ou grupo de desenvolvedores isolados, ou seja, que não fizessem parte do desenvolvimento de alguma distribuição, esse trabalho não seria facilmente notado, mesmo que se demonstre um excelente trabalho. Então a idéia seria também manter uma distribuição própria, poderia ser algo parecido com o Zenwalk, bem básico porém funcional.

Um dia quem sabe eu chego lá...

Técnicos????

Recentemente ocorreu um fato, no mínimo, bem curioso. Minha namorada recomendou a um amigo dela que comprasse o computador com Linux em vez de comprar com Windows Starter (nem preciso dizer aqui o motivo, certo?).

Quando conversei com ele pela primeira vez ele elogiou a interface (KDE) do Linux, e disse que estava um pouco complicado para fazer algumas coisas rotineiras, como instalar uma impressora, mas que de maneira geral estava gostando do sistema. Até ai tudo certo, pois os sistemas são realmente diferentes, e no Linux chega a ser mais complicado para iniciantes. O problema começou quando ele contratou o Speedy da Telefônica.

Em primeiro lugar, como a maioria dos produtos e serviços relacionados à informática, vem com 1 CD para a instalação em Windows, que infelizmente não procurei saber se havia algo para Linux no CD, o que, de certa forma, tira um pouco da credibilidade deste post, apesar que não havia nenhuma inscrição na capa em relação a outros sistemas operacionais. Fui na casa do amigo de minha namorada para ver se eu conseguia acertar a conexão para ele. Verifiquei que o Linux estava recebendo o endereço IP corretamente do DHCP do modem, e que o sistema conseguia "enxergar" o modem fazendo um teste simples com o ping.

Depois disso fui ler o manual do modem, que dava a instrução de acessar o modem com o navegador web, colocar a senha do administrador na página de administração do modem, e depois acessar o menu LOGIN e colocar o usuário e a senha fornecido pelo provedor de acesso. Quando acessei o menu login, simplesmente não existia campo nenhum onde digitar tal informação. Tentei então entrar em contato com o suporte do Speedy, e quando passei qual era o problema a primeira coisa que a atendente me perguntou foi: "Qual a versão do Windows que o senhor esta usando?". Respondi que não estava usando Windows e sim Linux, então ela me passou um telefone do "Suporte avançado". Pedi então que ele (o amigo de minha namorada) entrasse em contato com o tal suporte e dissesse que não estava conseguindo fazer a configuração do nome de usuário e senha no modem.

Como não tenho contato com a pessoa, perguntei para minha namorada se ela estava sabendo como foi o desenrolar da história, a principio fiquei sabendo que o "técnico" do Speedy foi na casa dele e não conseguiu resolver o problema. Mais para o final da semana passada perguntei novamente para minha namorada sobre o caso, ela então ligou para o amigo dela e ele respondeu, um tanto frustrado, que o "técnico" recomendou que ele trocasse o computador por um que tivesse o Windows instalado alegando que assim o Speedy funcionaria. E foi o que ele fez.

Mas perai, trocar de computador só por causa que a internet não estava conectando, mesmo sendo visível que o problema era a configuração do modem, e ainda mandando comprar um com Windows instalado???? Não sei se todos concordam comigo, mas para mim isso não é coisa de um técnico dizer. E isso é um problema sério.

Quando fiquei sabendo da recomendação que o "técnico" fez, além de achar um absurdo, fiquei imaginando qual é a formação e a orientação desses ditos "técnicos". Para mim, que tenho a formação de técnico em processamento de dados, o conceito de técnico é de um profissional que esta sempre se atualizando e gosta de resolver problemas, principalmente se esses problemas lhe trazem mais informações úteis, mesmo que não seja exatamente da área dele. A maioria dos técnicos de verdade que eu conheço nunca iriam sugerir um absurdo desses.

Só consigo pensar em duas possibilidades para uma atitude dessa: 1 - esses profissionais não são bem técnicos, apenas fazem cursos para saberem fazer o trabalho básico deles e o executam; 2 - as empresas (já que não são somente os técnicos da Telefônica que fazem esse tipo de recomendação sem sentido) passam ordens para que seja sempre jogado a responsabilidade para os usuários e que os problemas sejam resolvido da maneira mais fácil. Dentre essas duas possibilidades, fico com a segunda, mas a primeira também é bem provável de acontecer. E o mais importante, qualquer das duas opções sempre prejudicará uma pessoa em comum: o usuário.

Nesse caso, o problema é que o Seedy é desenvolvido para o Windows (padrão de marcado) mas pode facilmente ser configurado em outros sistemas operacionais, desde que o modem utilizado esteja corretamente configurado. Como o "técnico" somente é treinado para fazer a instalação em Windows, quando ele se depara com um sistema operacional diferente ele fica sem saber o que fazer, e acaba indo para a solução mais fácil para ele, que nesse caso específico é pedir para o usuário trocar o sistema operacional. Como nem todo mundo tem o conhecimento necessário (e nenhum usuário é obrigado a ter, mas um técnico deveria ter) para dizer onde esta exatamente o problema, ele acaba aceitando o recomendação desse "técnico".

Isso acaba criando um circulo vicioso onde as empresas empurram seus produtos voltados para os sistemas padrões, e os usuários por não saberem que o produto/serviço que ele contratou deve funcionar perfeitamente em qualquer sistema (no caso da conexão com a internet), acaba aceitando a sugestão do "técnico". Cada vez que um usuário aceita a sugestão (que as vezes soa como uma ordem) a empresa que oferece o produto/serviço tem um motivo a mais para não treinar seus funcionários em novos sistemas. E vale lembrar que a realidade hoje no Brasil é que cada vez mais usuários comuns estão comprando computadores com Linux, e empresas que prestam serviços que envolvam informática deveriam ter percebido isso e treinado seus "técnicos" nesse sistema.

O que eu quero dizer com tudo isso é que as empresas prestadoras de serviços, como a Telefônica, não estão realmente interessadas na qualidade de seus serviços e no bom atendimento aos clientes. Isso as fazem chamar de "técnicos" pessoas que não estão totalmente qualificadas para a realidade atual, e por isso acabam passando informações erradas aos usuários/clientes.

A decisão de comprar um computador com Linux não é errada, como também não é errada a decisão de comprar um computador com Windows, desde que não seja o Windows Starter, mesmo pagando bem mais por isso. O errado é admitir que as empresas continuem nos empurrando serviços e produtos que não nos dão opções de escolha, como nesse caso onde chegaram a dizer que o Speedy só funcionaria com o Windows. Precisamos ficar atentos, principalmente nós que somos da área de TI, para que esse tipo de situação não aconteça, ou pelo menos diminua.

Nota 1: É bem provável que com o Windows o Speedy conecte sem maiores problemas, pois, como disse, ele vem com um CD com o software para Windows. Acredito que esse software tenha alguma atualização do firmware do modem que é feita ao instalá-lo. Sendo assim, a melhor forma de resolver esse problema seria instalar o software em um computador com Windows instalado e o modem ligado nesse computador, após isso conectar o modem novamente no computador com Linux.

Nota 2: Não soube se o problema foi realmente resolvido só trocando o computador e sistema operacional, creio que sim.

02 julho 2007

TI x Informática

Tenho visto muitos casos onde empresas não sabem lidar com TI, geralmente empresas pequenas e médias. Quando eu digo lidar com TI, quero dizer que não sabem de tudo o que a tecnologia pode lhes oferecer para melhorar, principalmente, a eficiência e a qualidade de produtos e serviços da empresa.

Essas empresas, ou mais especificamente seus administradores, conhecem somente a Informática e não conhecem nada de Tecnologia da Informação. Por quê estou diferenciando esses termos? Bom, para mim, informática é somente um punhado de hardware e software utilizados para realizar tarefas rotineiras, são ferramentas de trabalho somente. Já a Tecnologia da Informação podemos definir como sendo a ciência de otimizar o uso de hardware e software para aumentar a eficiência e a qualidade de produtos e serviços, e não estou falando somente de produtos e serviços tecnológicos, todas as áreas (inclusive manufaturas) podem se beneficiar com TI. Essa é a minha opinião, alguém discorda??

O fato que melhor demonstra como cheguei à conclusão de que muitas empresas não sabem lidar com TI é a preocupação em investir em TI. É comum ver em pequenas e médias empresas equipamentos de informática totalmente obsoletos, tanto hardware como software. Geralmente a mentalidade dos administradores dessa empresa é de que os equipamentos devem ser usados enquanto estiverem funcionando, mesmo que seja um Pentium 100 MHz com Windows 98 instalado (sim, isso ainda existe, conheço casos atuais). Como devem imaginar, um computador nessas condições é o que chamamos de uma verdadeira "carroça", podendo ser considerado uma ferramenta de castigo para quem o utiliza. E o que leva uma uma empresa a manter computadores nessas "qualidades" em pleno funcionamento? Eu ainda não consigo entender, mas acredito que seja uma completa ignorância dos administradores nessa área, que os levam a pensar que informática é somente uma ferramenta de trabalho. Computadores antigos em empresas só geram prejuízos, e computadores no nível do acima citado não existem mais, hoje no Brasil, nem nos lares mais humildes, sendo inaceitável a permanência em empresas. Só como nota, não é recomendado utilizar os computadores por mais de 3 anos em uma empresa.

Como disse, computadores antigos só geram prejuízos. Como? Bom, em primeiro lugar, computadores antigos não têm capacidade de processamento suficiente para executar de forma cômoda os aplicativos mais atuais, sendo desaconselhado não fazê-lo. Como nem sempre esse conselho é seguido, o usuário de um computador desses é obrigado a trabalhar com aplicativos cada vez mais pesados, e as vezes não só 1, mas vários (já vi coisas bizarras nesse sentido). O computador fica facilmente sobrecarregado, levando vários minutos para executar uma tarefa simples. Enquanto o usuário fica apenas esperando essa tarefa ser executada , ele vê mais trabalho chegando para ele e recebe cobranças por seu trabalho ser demorado. Só aqui temos 2 prejuízos: lentidão na realização das tarefas e stress para o usuário, o que pode leva-lo ao afastamento temporário de suas atividades por problemas de saúde.

Outro grave problema gerado por manter computadores muito velhos em empresas é que o pessoal de suporte (isso se houver alguém dedicado a suporte na empresa) irá dedicar muito de seu tempo tentando resolver os problemas gerados por esses computadores, que tendem a apresentar mais problemas exatamente por terem muito tempo de uso. Além disso, sempre serão necessárias peças de reposição para resolver alguns problemas, que nem sempre são encontradas. Juntando tudo isso temos um alto custo em manter computadores antigos funcionando, que é muito mais alto do que a aquisição de novos equipamentos.

O problema é que não existe uma maneira fácil (se é que existe alguma maneira) de contabilizar esses gastos. Isso dificulta muito o trabalho de demonstrar que é inviável a manutenção desses equipamentos, e que comprar equipamentos novos é muito mais barato. Mas até hoje não entendi o por que é tão difícil mostrar isso a alguns administradores, mesmo quando falamos que podemos economizar dinheiro eles não dão ouvidos. Sendo assim, nesses casos temos que insistir muito até conseguir fazê-los compreender.

Como podemos ver, apenas em relação a atualização de computadores, já temos um grande problema caso os administradores não tenham noção sobre TI.

Mas será que a culpa de se ter equipamentos tão velhos numa empresa é somente dos administradores? A resposta é um sonoro NÃO. Os responsáveis pela informática na empresa têm grande parte da culpa, já que não correram atrás dos administradores em busca de investimentos. Mesmo que convencer algumas pessoas a investir seja uma tarefa árdua, temos que ser persistentes, caso contrário seremos um dos culpados pelo parque de computadores terem ficado desatualizados.

Mas isso é muito básico. Atualização de equipamentos são atitudes primarias a se tomar quando se utiliza informática para se trabalhar. Precisamos buscar sempre novas formas de utilizar os recursos de informática para melhorar o trabalho, produtos e serviços de uma maneira geral, se possível, até mesmo criando novas tecnologias. Precisamos ter a mentalidade de que tudo pode ser melhorado, e a TI possibilita isso.

Conclusões

Depois de terminar o tutorial sobre Bacula, cheguei a uma conclusão: Não da para manter tutoriais em um blog, a menos que eles sejam pequenos, rápidos e fáceis.

O primeiro problema, um tutorial sobre um assunto complexo como o do Bacula toma muito tempo. Levei horas para escrever cada post do tutorial, tempo que poderia falar de assuntos mais interessantes, mais rápidos.

Outro problema é em relação ao conteúdo do blog. Creio que muitos acharam o assunto desinteressante, e como praticamente não escrevi nada além disso, para muitos o blog deve ter ficado chato.

O terceiro problema é estético. Com posts tão grandes fica complicado achar alguma coisa entre eles. O blog fica parecendo maior do que realmente é, porém o torna difícil de ler, e para quem não esta interessado no tutorial, vai desistir logo do blog.

Conclusão: não me arrependo de ter escrito este tutorial sobre Bacula, será últil para mim mesmo quando precisar instalar outro servidor de backup, mas não repetirei isso aqui. Quando eu for escrever algum outro tutorial colocarei em algum site onde tenha uma área específica para tutoriais. Mas não sei se escreverei outro tão cedo, consome muito tempo, e tempo tem sido escasso ultimamente.

28 junho 2007

Tutorial Bacula: Iniciando o serviço e operando o sistema

Chegamos a última parte do tutorial. Aqui vou falar sobre como iniciar o serviço e operar o servidor Bacula. Não veremos tudo, mas somente o essencial para que, a partir deste ponto, quem leu o tutorial possa configurar e operar o sistema, mesmo que basicamente. Então, mãos-à-obra.

Para iniciarmos o sistema, os comando são:

# bacula-dir

# bacula-fd

# bacula-sd

que iniciam o Director Daemon, o File Daemon e o Storage Daemon respectivamente. Caso exista algum erro no arquivo de configuração, irá aparecer uma mensagem apontando qual o erro e o serviço não irá subir. Se for esse o caso, corrija os erros e execute o comando novamente. Se não exibiu mensagem de erro alguma, então o sistema deve estar no ar. Caso queira confirmar, digite o comando:

# ps aux | grep bacula

Esse comando exibirá todos os processos que estejam rodando e que contenham a sequência "bacula". Se tudo deu certo, vamos operar o sistema.

Para operar o sistema, utilizamos o console do Bacula, no caso o bconsole. Digite o comando:

# bconsole

Feito isso já estará no console do Bacula. A partir de agora, os comando com * na frente são referentes ao bconsole. A primeira ação a ser feita é nomear os volumes que serão utilizados. Para isso, digite o comando

* label

Esse comando irá pedir um nome que você queira dar ao volume. Logo depois irá pedir para que você indique em qual Pool você quer adicionar esse volume, será exibido os Pools que foram configurados no arquivo de configuração do Director. Escolhendo o Pool, ele irá gravar o nome do volume no banco de dados e, pelo menos no caso de fitas, eu não sei como o bacula trata outros dispositivos, também gravará o nome na própria fita. Você deve fazer isso com todos os volumes que irá utilizar no seu ciclo de backup. Se seguir o modelo deste tutorial, terá que nomear 1 volume para os backups incrementais e 2 volumes para os backups semanais, além de 1 volume todo mês para o backup mensal.

Se você estiver utilizando fitas para fazer backup, caso precise renomear alguma fita, o comando label não irá funcionar. Para isso terá que utilizar o utilitário btape do próprio bacula. Não vou entrar em detalhes sobre o btape, a unica dica que irei passar é que é preciso parar o serviço do bacula, em especial o bacula-sd, para poder utiliza-lo. A sintaxe é:

# btape /dev/nts0

Caso utiliza outro dispositivo que não o /dev/nts0, substitua-o pelo qual utilizar. Depois deste comando você irá entrar em um console igual ao bconsole, mas com opções diferentes.

Depois de nomear os volumes com o comando label, praticamente só será necessário trocar os dispositivos, caso sejam dispositivos removíveis, quando necesário.

Temos também o comando mount, que tem funcionalidade de montar o dispositivo. Caso você esteja usando somente fitas, simplesmente execute o comando no console e irá montar a fita que estiver dentro da unidade. Caso multiplos dispositivos de armazenamento, pode ser necesário usar a sintaxe:

* mount

25 junho 2007

Tutorial Bacula: Configurando Director Daemon

Voltei para postar mais uma parte do tutorial sobre Bacula, desta vez explicarei sobre a configuração do Director Daemon. Como já havia dito, é a configuração mais complexa do Bacula, e, como irão perceber, o arquivo de configuração é bem extenso. Eu modifique toda a disposição do arquivo de configuração em relação ao padrão, dividindo-o em seções que, na minha opinião, fica bem mais fácil de ser entendido.

Coloquei algumas observações em forma de comentário no meio das configurações. Basicamente todos os pontos importantes estão comentados. Os motivos para os pontos que não estão comentados são: a) não havia necessidade de comentar, é auto-explicativo; b) a configuração do item logo acima é igual e já esta comentado (devemos evitar redundância); c) eu realmente esqueci de comentar ;-), nesse caso me avisem para que possa corrigir.

Vamos ver as configurações:

#
# Configuracoes globais do servidor bacula
#

Director {

# Nome do Director Daemon – Servidor Bacula que estamos configurando agora
Name = sf1-dir
# Porta pela qual o servidor Bacula será acessado (normalmente pelo console)
DIRport = 9101
# Arquivo contendo as instruções SQL usadas para acessar o banco de dados
QueryFile = "/etc/bacula/query.sql"
# Diretório de trabalho do Director
WorkingDirectory = "/var/lib/bacula/working"
PidDirectory = "/var/run"
# Numero máximo de trabalhos ao mesmo tempo
Maximum Concurrent Jobs = 1
# Senha necessaria para acessar o servidor bacula pelo console
Password = "senha"
# Configuração de mensagens utilizadas pelo Director
Messages = Mensagens
}

##################################################################################
## Banco de dados a ser usado para armazenar as informações dos backups
##################################################################################
Catalog {

# Nome do catálogo
Name = MyCatalog
# Nome do banco de dados, usuário e senha para ser acessado pelo Bacula
# Por padrão a senha do banco de dados esta em branco, caso você altere a senha
# no banco de dados, deve colocar a nova senha aqui
dbname = bacula; user = bacula; password = ""
}

##################################################################################
# Seção clientes
# Configura os clientes onde estão os dados a serem armazenados em backup
##################################################################################
###################
## Servidor ServArq
###################
Client {

Name = ServArq
# Nome ou endereço IP do cliente
Address = servarq
# Porta de acesso ao cliente, configurada no arquivo de configuração do cliente
FDPort = 9102
# Catalogo a ser utilizado no banco de dados
Catalog = MyCatalog
# Senha para se acessar o cliente, configurada no arquivo de configuração do cliente
Password = "senha"
# Tempo em que o backup do cliente sera armazenado no banco de dados
# Passado esse tempo o registro desse arquivo sera excluído
# Isso não afeta o backup que esta armazenado
File Retention = 30 days
# Tempo em que os trabalhos do cliente serão armazenados no baco de dados
# Passado esse tempo o registro desse arquivo sera excluído
# Isso não afeta o backup que esta armazenado
Job Retention = 30 days
# Este comando irá apagar os registros dos arquivos e jobs,
# citados acima, automaticamente
AutoPrune = yes
}

# Este cliente é praticamente igual ao cliente acima, somente muda
# o tempo de retenção dos arquivos e dos jobs
# Fiz dessa forma pois os backups mensais devem ser guardados por
# um tempo muito maior que os backups diários e semanais
Client {

Name = ServArqMensal
Address = servarq
FDPort = 9102
Catalog = MyCatalog
Password = "senha"
# Estou deixando para 20 anos pois o backup mensal terá retenção de 20 anos
File Retention = 20 years
Job Retention = 20 years
AutoPrune = yes
}

#############################################
## ServApl – servidor de aplicações
## Basicamente é repetida a configuração do ServArq
## inclusive uma configuração distinta para o backup
## mensal
#############################################
Client {

Name = ServApl
Address = servapl
FDPort = 9102
Catalog = MyCatalog
Password = "senha"
File Retention = 30 days
Job Retention = 30 days
AutoPrune = yes
}

Client {

Name = ServAplMensal
Address = servapl
FDPort = 9102
Catalog = MyCatalog
Password = "senha"
File Retention = 20 years
Job Retention = 20 years
AutoPrune = yes
}

###############
## ServBD – servidor de banco de dados
###############
Client {

Name = ServBD
Address = servbd
FDPort = 9102
Catalog = MyCatalog
Password = "senha"
File Retention = 30 days
Job Retention = 30 days
AutoPrune = yes
}

Client {

Name = ServBDMensal
Address = servbd
FDPort = 9102
Catalog = MyCatalog
Password = "senha"
File Retention = 20 years
Job Retention = 20 years
AutoPrune = yes
}

##################################################################################
# Seção Pool
##################################################################################

Pool {

# Define o Pool para o backup semanal completo
Name = Semanal
Pool Type = Backup
# As 2 opções abaixo são utilizada para que a fita sera auto reciclada,
# ou seja, eh como se dissesse que os dados da fita podem ser apagados
# e gravados novos dados em seu lugar
Recycle = yes
AutoPrune = yes
# Define quanto tempo os dados ficarão na fita sem poderem ser apagados.
# Somente a depois desse tempo a fita sera reciclada
Volume Retention = 13 days
# Define a quantidade máxima de trabalhos que podem ser armazenados em uma fita
# sem que ela precise ser reciclada
Maximum Volume Jobs = 3
# Define o numero máximo de fitas que sera utilizada pelo Pool
Maximum Volumes = 2
}

Pool {

# Define o Pool para o backup diário incremental.
# As opções abaixo são as mesmas do Pool Semanal.
Name = Diario
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 7 days
Maximum Volume Jobs = 12
Maximum Volumes = 1
}

Pool {

# Define o Pool para o backup Mensal completo.
# As opções abaixo são as mesmas das anteriores.
# Aqui não definiremos um máximo de volumes, isso faz com que
# possa ser usado quantos volumes forem necessários.
Name = Mensal
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 20 years
Maximum Volume Jobs = 3
}

# O Pool Defaul deve ser criado pois os jobs exigem que seja
# definido o parâmetro Pool, e como não é bom utilizar um dos Pools
# acima, criamos um default. Ele nunca será usado de fato.
Pool {

Name = Default
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 365 days
}

##################################################################################
# Seção Schedule
# Agenda o nível , a data e a hora do backup para os jobs
##################################################################################
# É necessário criar um agendamento para cada cliente, pois não é
# possível fazer backup de vários clientes com o mesmo trabalho de backup
##########
# ServArq
##########
Schedule {

# Agenda o backup completo para a segunda, terceira, quarta e quinta (caso haja)
# segunda-feiras de cada mês, e também os backup diários incrementais.
# Se o mês não tiver 5 segunda-feiras, a quinta segunda-feira será ignorada.
# O backup sera sempre as 22:00 horas.
# Foram passados dois parâmetros Run pois um mesmo agendamento pode
# agendar datas e horários diferentes para o mesmo backup.

# Nome do agendamento
Name = ServArq
# Indica o nível, o dia e a hora do backup
Run = Full 2nd-5th Monday at 10:00pm
Run = Incremental tue-sun at 10:00pm

}

# Agenda o backup mensal para o servidor ServArq
Schedule {

Name = ServArqMensal
Run = Full 1st Monday at 10:00pm
}

############
# ServApl
############
# Agenda o backup completo e incremental para o servidor ServApl
# O backup sera sempre as 22:10 horas
Schedule {

Name = ServApl
Run = Full 2nd-5th Monday at 10:10pm
Run = Incremental tue-sun at 10:10pm
}

# Agenda o backup mensal para o servidor ServApl
Schedule {

Name = "ServAplMensal"
Run = Full 1st Monday at 10:10pm
}

############
# ServBD
############
# Agenda o backup completo e incremental para o servidor ServBD
# O backup sera sempre as 22:20 horas
Schedule {

Name = ServBD
Run = Full 2nd-5th Monday at 10:20pm
Run = Incremental tue-sun at 10:20pm
}

# Agenda o backup mensal para o servidor ServBD
Schedule {

Name = ServBDMensal
Run = Full 1st Monday at 10:20pm
}

##################################################################################
# Seção FileSet
# Determina quais arquivos devem ser feitos backup e quais ficarão fora dos backups
##################################################################################
FileSet {

Name = ServArq
# Define quais arquivos ou diretórios farão parte do backup
Include {
# Define algumas opções para o backup
Options {
# Opção de segurança
signature = MD5
# Compressão dos dados usando GZIP
# O número 9 indica o taxa de compressão, quanto mais alto
# mais compressão. Vai de 1 a 9
compression=GZIP9
# Exclui do backup os arquivos com extensão tmp
wildfile = "*.tmp"
# Diz que os arquivos indicados em wildfile não farão parte do backup
Exclude = yes
}
# Define quais diretórios farão parte do backup
File = /arquivos/dados
File = /etc
}
}

FileSet {

Name = "ServApl"
Include {
Options {
signature = MD5
IgnoreCase = yes
compression=GZIP9
wildfile = "*.tmp"
Exclude = yes
}
# Por ser sistema de arquivos Windows é necessário indicar a letra da unidade
# A barra (/) não esta errada, por ser em Linux é essa mesmo que temos de usar
File = "F:/Aplicacoes"
}
}

FileSet {

Name = "ServBD"
Include {
Options {
signature = MD5
IgnoreCase = yes
compression=GZIP9
}
File = "G:/BKPBancos"
}
}

##################################################################################
# Seção Storage
# Configura qual servidor esta com a unidade de fita, qual unidade de fita usar
##################################################################################
Storage {

# Nome do dispositivo a ser usado no Director
Name = AIT-1
# Endereço do servidor, pode ser o nome ou o endereço IP
Address = ServArq
# Porta pela qual o servidor de Storage será acessada
SDPort = 9103
# Senha com a qual o Director acessará o Storage Daemon
Password = "senha"
# Dispositivo configurado no Storage Daemos que iremos utilizar
Device = AIT-1
}

##################################################################################
# Seção Job
# Configura os trabalhos de backup
##################################################################################
# Para que se possa fazer um backup completo na segunda-feira e incremental
# nos demais dias da semana, é necessário que os dois tipos de backup sejam
# controlados por este mesmo job. É necessário que o Client e o FileSet também
# sejam os mesmo nos dois tipos de backup. Analisando a configuração veremos isso.
# Uma observação que deve ser feita é que, mesmo quando estiver agendado para
# executar o backup incremental, o Bacula poderá executar o backup Full. Dois motivos
# para que isso aconteça é: 1 – Nunca ter sido feito um backup full desses arquivos antes;
# 2 – ter sido feito alguma mudança no FileSet.
############
# ServArq
############
# Define o trabalho para o backup semanal e diário do ServArq
Job {

# Nome do trabalho
Name = ServArq
# Tipo do trabalho, pode ser Backup ou Restore
Type = Backup
# Cliente que foi configurado acima
Client = ServArq
# File set do servidor ServArq configurado acima
FileSet = ServArq
# O storage configurado acima
Storage = AIT-1
# O agendamento para o backup do ServArq configurado acima
Schedule = ServArq
# O Pool configurado, mas que será indicado aqui apenas por que o Bacula
# exige esse parâmetro, não será utilizado
Pool = Default
# Os dois parâmetros abaixo serão os utilizados para indicar o Pool.
# Um indica o Pool o Pool para o backup Full e o outro para o Incremental.
# O Bacula que indica qual Pool será utilizado, conforme agendamento.
Full Backup Pool = Semanal
Incremental Backup Pool = Diario
# Configuração de mensagem utilizada por este Job
Messages = Mensagens
# Script que será executado antes da execução do backup. No caso, esse script
# montará o dispositivo (caso não esteja montado) antes de ser feito o backup.
# Mostrarei esse script no final dessa parte do artigo.
RunBeforeJob = "/usr/sbin/monta_tape.sh"
# Define a prioridade do Job, quanto menor o valor, a prioridade é maior
# O padrão é 10. É uma opção importante pois, caso os backups atrasem, a execução
# será pela prioridade e não mais pelo horário.
Priority = 10
}

# Define o trabalho para o backup mensal do servidor ServArq
Job {

Name = ServArqMensal
Type = Backup
Client = ServArqMensal
FileSet = ServArq
Storage = AIT-1
# Neste caso informamos somente um Pool, pois o backup mensal
# será sempre completo
Pool = Mensal
Schedule = ServArqMensal
Messages = Mensagens
RunBeforeJob = "/usr/sbin/monta_tape.sh"
Priority = 10
}

# Define o trabalho de Restore o backup semanal do servidor ServArq
# O Job Restore é importante para restaurarmos um backup
# As opções são as mesmas dos Jobs de backup
Job {

Name = RestoreServArqSemanal
Type = Restore
Client = ServArq
FileSet = ServArq
Storage = AIT-1
Messages = Mensagens
Pool = Semanal
Where = /tmp/bacula-restores
}

Job {

Name = RestoreServArqDiario
Type = Restore
Client = ServArq
FileSet = ServArq
Storage = AIT-1
Messages = Mensagens
Pool = Diario
Where = /tmp/bacula-restores
}

Job {

Name = RestoreServArqMensal
Type = Restore
Client = ServArqMensal
FileSet = ServArq
Storage = AIT-1
Messages = Mensagens
Pool = Mensal
Where = /tmp/bacula-restores
}

###############
# ServApl
###############
Job {

# Define o trabalho para o backup semanal do servidor ServApl
Name = ServApl
Type = Backup
Client = ServApl
FileSet = ServApl
Storage = AIT-1
Schedule = ServApl
Pool = Default
Full Backup Pool = Semanal
Incremental Backup Pool = Diario
Messages = Mensagens
RunBeforeJob = "/usr/sbin/monta_tape.sh"
Priority = 11
}

Job {

Name = ServAplMensal
Type = Backup
Level = Full
Client = ServAplMensal
FileSet = ServAplMensal
Storage = AIT-1
Pool = Mensal
Schedule = ServAplMensal
Messages = Mensagens
RunBeforeJob = "/usr/sbin/monta_tape.sh"
Priority = 11
}

Job {

Name = RestoreServAplSemanal-sapp
Type = Restore
Client = ServApl
FileSet = ServApl
Storage = AIT-1
Messages = Mensagens
Pool = Semanal
Where = /tmp/bacula-restores
}

Job {

Name = RestoreServAplDiario
Type = Restore
Client = ServApl
FileSet = ServApl
Storage = AIT-1
Messages = Mensagens
Pool = Diario
Where = /tmp/bacula-restores
}

Job {

Name = RestoreServAplMensal
Type = Restore
Client = ServApl
FileSet = ServApl
Storage = AIT-1
Messages = Mensagens
Pool = Mensal
Where = /tmp/bacula-restores
}

###############
# ServBD
###############
Job {

# Define o trabalho para o backup semanal
Name = ServBD"
Type = Backup
Client = ServBD
FileSet = ServBD
Storage = AIT-1
Schedule = ServBD
Pool = Default
Full Backup Pool = Semanal
Incremental Backup Pool = Diario
Messages = Mensagens
RunBeforeJob = "/usr/sbin/monta_tape.sh"
Priority = 12
}

Job {

Name = ServBDMensal
Type = Backup
Level = Full
Client = ServBDMensal
FileSet = ServBDMensal
Storage = AIT-1
Pool = Mensal
Schedule = ServBDMensal
Messages = Mensagens
RunBeforeJob = "/usr/sbin/monta_tape.sh"
Priority = 12
}

Job {

Name = RestoreServBDSemanal
Type = Restore
Client = ServBD
FileSet = ServBD
Storage = AIT-1
Messages = Mensagens
Pool = Semanal
Where = /tmp/bacula-restores
}

Job {

Name = RestoreServBDDiario
Type = Restore
Client = ServBD
FileSet = ServBD
Storage = AIT-1
Messages = Mensagens
Pool = Diario
Where = /tmp/bacula-restores
}

Job {

Name = RestoreServBDMensal
Type = Restore
Client = ServBD
FileSet = ServBD
Storage = AIT-1
Messages = Mensagens
Pool = Mensal
Where = /tmp/bacula-restores
}

##################################################################################
# Seção Mensagens
##################################################################################

Messages {

Name = Mensagens
# Envia todas as mensagens geradas pelo Bacula para o arquivo
# /var/log/messages
syslog = all, !skipped, !saved
}

Esse é o script que será executado antes do primeiro Job do dia para montar a fita no Bacula:
Depois de criado o script, é só dar as permissões adequadas e estará pronto.

Eu sei que esteticamente essa listagem do arquivo de configuração não ficou nada boa, mas espero que todos tenham conseguido entende-lo. Não é mesmo complexo? Mas o grande problema é que, talvez, para deixar as configurações mais simples tenha uma grande perda na flexibilidade do sistema. O ideal seria um sistema menos complexo de se configurar e com toda flexibilidade que o Bacula tem. Acho que vou fazer disso o meu projeto de TCC da faculdade ;-).

Um ponto que gostaria de comentar é sobre redundância, que falei no começo do post, que nesse arquivo de configuração é abundante (pelo menos a meu ver). Uma mesmas configuração pode ser encontrada em vários pontos diferentes da configuração. Acredito que isso seja uma coisa que gera dificuldade para a maioria das pessoas entenderem como o Bacula funciona.

Como de praxe, peço para que comentem principalmente se o artigo precisar de alguma melhoria para que fique mais fácil de entende-lo.

A próxima parte, a última (felizmente, não aguento mais escrever sobre Bacula :-\ ), trará a explicação de como operar o sistema. Será um manual básico sobre as principais funções necessárias para operação do sistema, sem se aprofundar muito. Pretendo faze-lo até a próxima semana.

19 junho 2007

Tutorial Bacula: Configurando Storage Daemon, File Daemon e Console

Depois de algum tempo enrolado com provas da faculdade, estou eu aqui para mais uma parte do tutorial sobre Bacula. Aqui vamos ver como configurar os serviços Storage Daemon, File Daemon e Console. O Director Daemon será configurado a parte por possuir uma grande complexibilidade e, por isso, ser um assunto muito extenso.

Arquivo /etc/bacula/bacula-sd.conf (Storage Daemon)

Vamos começar pelo Storage Daemon. Segue abaixo o arquivo de configuração /etc/bacula/bacula-sd.conf:

# Configuração para o Servidor de Armazenamento.
# Esse é o servidor no qual está instalada fisicamente a mídia de armazenamento

#
# Aqui são definidas as configurações do próprio servidor de armazenamento
#
Storage {
# Nome do Storage Daemon, esse é o nome utilizado pelo bacula,
# não necessariamente precisa ser o hostname
Name = sf1-sd
# Porta utilizada pelo Director Daemon para acessar o Sotorage Daemon
SDPort = 9103 Daemon
# Diretório de trabalho (temporário) do Storage Daemon
WorkingDirectory = "/var/lib/bacula/working"
# Diretório onde é armazenado informação sobre o processo rodando
Pid Directory = "/var/run"
# Númro de trabalhos rodando ao mesmo tempo
# Se você irá fazer mais de 1 backup ao mesmo tempo, indique o número aqui
# No meu caso será somente 1 trabalho mesmo
Maximum Concurrent Jobs = 1
}

#
# Aqui é listado a configuração para conexão com o Director Daemon
#
Director {
# Nome do Director Daemon (cadastrado no /etc/bacula/bacula-dir.conf)
Name = sf1-dir
# Senha que o Director irá usar para acessar o Storage
Password = "senha"
}

#
# Define as configurações da unidade de fita
#
Device {
# Nome do dispositivo
Name = AIT-1
# Tipo do dispositivo, pode ser File (arquivos, partições), Tape (fitas), Fifo (sistemas de acesso sequencial) ou DVD
Device Type = Tape
# Nome do dispositivo pelo qual o linux irá acessar a unidade de fita
Archive Device = /dev/nst0
# Diz se a fita ira receber um nome pelo Bacula
LabelMedia = yes;
# As opções abaixo não tive tempo de procurar saber para que servem,
# mas ficando no padrão já funcionan
Random Access = Yes;
AutomaticMount = yes;
RemovableMedia = no;
AlwaysOpen = no;
}

#
# Essa opção envia as possíveis mensagens geraradas para o Director
#
Messages {
# Nome da configuração de mensagens
Name = Standard
# Nome do Director Daemon
# all significa que todas mensagens serão enviadas
director = sf1-dir = all
}
Obs.: Os comentários originais do arquivo de configuração foram tirados para uma melhor visualização, e nem todas as opções possíveis para configuração do Storage Daemon são tratadas aqui, somente as necessárias para o correto funcionamento do sistema estão tratadas aqui. Isso também vale para todos os outros arquivos de configuração.

As configurações acima servem para disponibilizar um dispositivo de backup (que no meu caso é uma unidade AIT-1 Turbo, mas pode ser qualquer outra unidade de fita, além de gravadores de DVDs e CDs, partições de HDs, etc) para o Director, que irá acessa-lo no momento do backup ou da recuperação dos dados. Os nomes dados é você quem escolhe, não é necessário ser o nome correto do dispositivo

Acredito que com os comentários nas configurações já seja possível entender a configuração do Storage Daemon. Qualquer duvida ou opinião será bem-vinda para melhoria do artigo.

Arquivo /etc/bacula/bacula-fd.conf (File Daemon)
#
# Esse é o arquivo responsável pelas configurações do cliente,
# ou seja, o local onde estão os dados a serem incluidos no backup
#

#
# Aqui é listado a configuração para conexão com o servidor principal do bacula
#
Director {
# Nome do Director Daemon que irá acessar este File Daemon
Name = sf1-dir
# Senha que o Director usará para acessar este cliente
Password = "senha"
}

#
# Especificação das configurações globais do cliente
#
FileDaemon {
# Nome deste cliente, pode ser qualquer nome que o identifique melhor
Name = sf1-fd
# Porta pela qual o servidor bacula ira acessar o cliente
FDport = 9102
# As opções abaixo são indenticas as do Storage Daemon
WorkingDirectory = /var/lib/bacula/working
Pid Directory = /var/run
Maximum Concurrent Jobs = 1
}

#
# Essa opção envia as possíveis mensagens geradas para o Director
#
Messages {
# Nome da configuração de mensagens
Name = Standard
# Nome do Director Daemon
# all significa que todas mensagens serão enviadas
# O ! significa exceto
director = sf1-dir = all, !skipped, !restored
}
Arquivo /etc/bacula/bconsole.conf (File Daemon)
#
# Bacula User Agent (or Console) Configuration File
#

Director {
# Nome do Director Daemon que o console irá acessar
Name = sf1-dir
# Porta pela qual o console irá acessar o Director
DIRport = 9101
# Endereço do Director, pode ser o hostname ou endereço IP
address = sf1
# Senha com a qual o console irá acessar o Director
Password = "senha"
}

Pronto, com essas configurações já estamos 30% do servidor pronto, resta agora configurar o Director Daemon, que corresponde por 50%, e aprender a operar o Bacula pelo console. Teremos mais 2 posts para terminar o artigo e estarmos aptos a colocar o sistema para rodar. Espero terminar esse artigo nas próximas 2 semanas, e, como sempre, espero a contribuição de vocês para melhorar o artigo.

Obs.: As porcentagens foram calculadas por mim, sem nenhuma pretenção de estarem certas, mas quem sabe eu tenha acertado mesmo ;-)

15 junho 2007

Mudança de layout

Mudei o layout do blog esperando assim melhorar sua visualização. Caso alguém tenha algum problema com a visualização do blog, por favor me avise para poder resolver o ploblema.

12 junho 2007

Dispositivo para teste em portas USB

Em uma lista de discução que participo foi enviada uma mensagem bastante interessante. É a notícia de um artigo sobre como fazer um dispositivo para teste de portas USBs. Para quem tem pendrive esse dispositivo é muito util, pois evita de queima-lo em portas USB ligadas de maneira errada. Segue o link para o artigo

http://www.ribafs.net/joomla/index.php?option=com_content&task=view&id=60&Itemid=85


Obs.: A terceira parte do tutorial sobre Bacula vai demorar um pouco pra sair. To em semana de prova na faculdade, então provavelmente só sairá na semana que vem.

28 maio 2007

Tutorial Bacula: Infra-estrutura e Instalação

Volto aqui com a segunda parte do tutorial sobre o Bacula. Vou abordar nessa parte a explicação de como é a infra-estrutura na qual eu baseei o tutorial e a instalação do Bacula.

Infra-estrutura.

O tutorial é baseado na experiência que tive ao instalar o Bacula na empresa onde trabalho, por isso irei utilizar uma estrutura parecida para esse tutorial.

Para este tutorial teremos 1 servidor de arquivos com Linux instalado (acredito que a distribuição não seja importante) que o chamaremos d ServArq. Nesse servidor esta instalado uma unidade de fita para backup, com a qual, obviamente, iremos realizar os backups. Os arquivos a serem feito backup estão em somente 1 diretório, o diretório /arquivos. Será nesse servidor que iremos instalar o banco de dados e o Bacula, logo, teremos todos os módulos do Bacula concentrados em somente 1 servidor: o Bacula Director Daemon, o Bacula Storage Daemon, o Bacula File Daemon, o Database Server e o Console de Comandos. Apesar de estar instalando tudo em somente um servidor, eu poderia instalar cada módulo em um servidor diferente. Não estou utilizando vários servidores pois o volume de dados não é tão grande para justificar isso, porém é altamente recomendado uma configuração com vários servidores para quem tem muitos dados que precisam serem feito backup.

Além desse servidor de arquivo, teremos mais 2 servidores com dados que farão parte do backup. É um servidor de aplicações, que iremos chamar de ServApl, e um servidor de banco de dados, que chamaremos de ServBD, os 2 rodando Windows (acredito que a versão não seja importante, pois o Bacula roda em todas as versões). Nesses 2 servidores será instalado apenas o Bacula File Daemon, pois somente serão usados para buscar os dados que estão neles.

Acredito que com isso já se possa ter uma idéia melhor de como é a estrutura que será usada no backup. Saber como é a estrutura usada, na minha opinião, é fundamental para o entendimento da configuração do Bacula. Só mais um detalhe, todos os 3 estão na mesma rede física e lógica.

Como será realizado o backup

  • A partir da estrutura acima descrita, o backup será realizado da seguinte forma:

  • - Os dados de todos os 3 servidores estarão no backup;

  • - O servidor ServArq é o responsável pelo backup dos 3 servidores;

  • - Os backups serão realizados sempre durante a noite, iniciarão as 22 horas;

  • - Toda primeira segunda-feira de cada mês será realizado um backup completo, que será armazenado e não deverá ser apagado. Esse será nosso backup mensal;

  • - Será feito um backup completo toda segunda-feira (backup semanal, exceto na primeira segunda de cada mês), e backups incrementais de terça-feira à domingo (backup diário);

  • - O backup semanal será armazenado por 2 semanas, utilizando 2 fitas, alternando o uso (uma fita em uma semana, outra fita na semana seguinte), assim garantimos que sempre haverá um backup completo disponível;

  • - O backup diário utilizará apena 1 fita, que será utilizada todos os dias. Cada backup diário realizado será adicionado à fita sem sobrescrever o anterior, mantendo assim 6 backups incrementais na mesma fita;
Esse é o esquema de backup ideal, pelo menos para meu caso. Com esse esquema temos economia (pois usaremos somente 3 fitas durante o mês, sem contar com a fita mensal), praticidade (já que iremos trocar de fita apenas 2 vezes por semana) e segurança, já que teremos sempre um backup completo guardado e backups todos os dias.

Obs.: Para quem não sabe como funciona exatamente o backup incremental, vou colocar uma explicação rápida, mas aconselho que leia os links deste post, que contêm explicações mais detalhadas. Vamos à uma explicação rápida sobre os tipos de backup:

  • - Backup Completo ou Full – como o próprio nome diz, backup completo com todos arquivos existentes;

  • - Backup Diferencial – backup com as alterações realizadas desde o ultimo backup completo;

  • - Backup Incremental – backup com as alterações realizadas desde o ultimo backup, não importando que esse ultimo backup foi completo, diferencial ou incremental.
A instalação

Conforme as informações abordadas na parte de infra-estrutura, toda a instalação feita aqui será no mesmo servidor, no caso o ServArq. Então vamos começar.

Para a instalação, inicialmente você precisa ter instalado o MySQL ou algum outro servidor de banco de dados. Os bancos suportados na versão 2.0.3 são: MySQL, PostgreSQL, SQLite3, SQLite. No meu caso utilizei o MySQL. Como a maioria das distribuições atualmente já trazem o MySQL como padrão em sua coleção de pacotes, não irei abordar a instalação do mesmo, e vou considerar que todos saibam instalá-lo ou já o tenham instalado.

Para a instalação do Bacula, primeiro precisamos baixar a versão mais recente (recomendo isso pois aqui utilizo a versão mais recente, e mesmo que sua distribuição já traga o Bacula em sua coleção de pacotes, pode ser que a versão que a distribuição traga seja mais antiga) do site oficial (www.bacula.org). Depois de baixado e descompactado os fontes, vamos compilá-lo:

# ./configure --with-mysql

# make

# make install

Obs.: Existe um programa chamado checkinstall que server para criar o pacote rpm, deb ou tgz para a instalação com o gerenciador de pacotes. Para utilizá-lo, basta, depois do comando make, utilizar o comando:

# checkinstall make install

Esse comando irá pedir algumas informações sobre o programa e após isso irá gerar o pacote. Depois é só instalá-lo como o gerenciador de pacotes de sua distribuição. Isso garante uma remoção mais fácil do pacote, caso seja necessário. Eu tenho o pacote rpm gerado para o openSuse 10.2, se encontrar algum lugar para disponibilizar o pacote eu coloco o link no blog.

Após a instalação do Bacula, temos que criar o banco de dados no MySQL, criar as tabelas no banco de dados e preencher as tabelas com os dados iniciais necessários para o correto funcionamento do Bacula. Mas calma, não precisamos fazer isso manualmente, o Bacula traz scripts para automatizar essa tarefa. Entre no diretório /etc/bacula, que é o diretório padrão onde ficam os arquivos de configuração do Bacula. Nesse diretório estão os scripts que irão preparar o banco de dados. Digite os seguintes comandos:

# ./create_mysql_database

# ./grant_mysql_privileges

# ./make_mysql_tables

# ./update_mysql_tables

Ates de executar essas scripts, porém, é necessário saber a senha do adminitrador do MySQL (que normanlmente é o usuário root). Por padrão, ao instalar o MySQL, a senha é em branco. Se a senha do MySQL da sua instalação for em branco, é só executar os scripts e tudo funciona. Caso a senha seja outra, e você saiba a senha, entre em casa um dos scripts e altere a linha

if $bindir/mysql $* -f < $* -f

para

if $bindir/mysql -p= $* -f < $* -f

Agora, caso a senha não esteja em branco e você não saiba a senha, então temos um problema. Será necessário forçar a troca de senha. Eu sei que isso é possível fazer, mas não tenho os comandos necessários para fazer, logo, recomendo uma busca no google, caso esse seja o seu problema.

Para quem executou todos os passos até aqui sem nenhum problema, temos agora o ambiente pronto para começar a configirar o Bacula, mas isso irei abordar na próxima parte do artigo. Paro os que não obtiveram sucesso em alguma parte, estejam livre para postar as dúvidas nos comentários. Também estejam livres a apontar os problemas e fazer críticas ao tutrial.

Até a próxima.

22 maio 2007

Tutorial Bacula: Introdução ao Bacula

Bacula é um servidor para gerenciar, realizar e recuperar backup. É um sistema bem completo e flexível, o que também o torna bastante complexo, principalmente para configurá-lo. É baseado em plataforma cliente-servidor, o que quer dizer que um mesmo servidor pode fazer backup de vários clientes diferentes. O bacula também aceita vários tipos de dispositivos de armazenamentos, que vai desde arquivos em disco até modernas unidades de fitas (o que não é surpresa, já que qualquer tipo de dispositivo no Linux é tratado como arquivo:-).

Um ponto interessante no Bacula é que podemos usar vários servidores para o sistema de backup, isso por que o Bacula é dividido em vários “módulos” ou “servidores” (não sei qual a melhor terminologia para usar nesse caso). Segue abaixo uma esquematização do Bacula, que tirei do site oficial:

E aqui temos algo mais simples:

Conceitos do Bacula

Vou explicar o esquema acima, começando pela descrição de cada parte:

- Bacula Server (ou Bacula Director Daemon): é a parte principal do Bacula. Ele é o responsável por toda a administração dos backups e também pela recuperação dos dados em backup. É o “núcleo” do sistema todo. É ele que controla os demais servidores, sendo assim, tudo depende da configuração do Director. A configuração do Director é justamente a parte mais complexa do Bacula, porém as demais partes são extremamente simples.

- Storage Server (ou Bacula Storage Daemon): é servidor onde os dados serão armazenados. Não necessariamente necessita haver uma unidade de backup como uma unidade de fita ou gravador de DVD, pode ser somente um servidor com espaço em disco o suficiente para armazenar os arquivos de backup. Isso por ser uma característica do bacula realizar o backup em qualquer tipo de dispositivo como, por exemplo, Unidades de Fita, gravador de CD ou DVD, arquivos em HDs, penrives, disquetes (desde que o backup seja menor que a capacidade, claro), etc.

- File Server (ou Bacula File Daemon): é o cliente do bacula, ou seja, responsável por disponibilizar os arquivos que serão feito backup pelo servidor Bacula. Explicando melhor, no computador onde estão os dados que necessitam serem feito backup ficará instalado o programa cliente do Bacula, que permitirá ao servidor Bacula acessá-lo e copiar os dados para o backup.

- Database Server: esse na verdade é o banco de dados onde ficam armazenadas todas as informações gerenciadas pelo Bacula. É no banco de dados que ficam armazenados as informações sobre os dispositivos de armazenamentos, informações sobre os trabalhos de backup utilizados, a lista dos arquivos dos quais foram feitos backup em cada trabalho, etc. Os bancos de dados mais comuns de se utilizar é o mySQL e o PostgreeSQL. Nesse tutorial iremos utilizar o mySQL.

- Admin Workstation (Command Console): é a interface, ou console, pela qual se administrará o bacula. Existe a versão em linha de comando e também uma versão em modo gráfico (que na verdade é praticamente a mesma coisa, muda apenas algumas opções). Existe versões do console para Linux, BSD, Unix (e outros sistemas possix) e também para Windows.

Essa foi uma pequena descrição sobre cada parte do Bacula. Cada uma dessas partes pode estar em computadores diferentes, bem como todas em um mesmo computador. Aqui estão todas em um mesmo computador inclusive o File Daemon, e existem outros File Daemon na rede (em computadores diferentes).

Agora tentarei explicar de um modo simples como o Bacula funciona como um todo, bem como será a seqüência de configuração do sistema. A configuração de cada parte, apesar de ser comentada aqui, será detalhada em um post futuro (não sei se será no 2º ou 3º post sobre o assunto).

Para começar temos que ter instalado o banco de dados, no nosso caso o mySQL. Para configurar o mySQL, o Bacula traz alguns scripts para faze-lo, mas isso iremos ver no próximo post. Após isso configuraremos o Bacula Storage Daemon, com o arquivo /etc/bacula/bacula-sd.conf. Nele configuraremos o próprio Storage Daemon (claro), o Director que pode acessá-lo, o dispositivo que será utilizado e as mensagens do sistema.

Após isso iremos configurar o Bacula File Daemon, com o arquivo /etc/bacula/bacula-sd.conf. As configurações são: a configuração do File Daemon; o Director que pode acessa-lo; as mensagens do sistema.

Após, configuraremos o console, com o arquivo /etc/bacula/bacula-sd.conf. Para o console iremos apenas configurar qual o Director que será acessado pelo console. E só isso.

Agora a parte mais complexa, o Bacula Director Daemon, onde detalharei um pouco mais (apesar de não entrar na parte de configuração ainda). O arquivo de configuração é o /etc/bacula/bacula-dir.conf , onde iremos configurar as seguintes “seções”: (nota: o termo “seção” esta sendo utilizado por mim para tentar simplificar a explicação. Dentro de cada seção podemos dividir as informações em “itens”. Originalmente os arquivos de configuração do Bacula não esta dividido claramente em seções)

- Director: são as configurações globais do Bacula, one são definidos o nome do servidor, porta de acesso, etc.

- Messages: é o responsável de tratar as mensagens do sistema Bacula.

- Catalog: define qual é o nome do banco de dados, usuário e senha para acessar o banco de dados. Está ligado ao banco de dados propriamente dito.

- Client: configura os clientes de onde os arquivos serão feito backup. Cada computador onde esteja instalado o File Daemon deverá ser configurado aqui e no File Daemon deve ser configurado esse Director para poder ser acessado por ele, ou seja, essa configuração depende da configuração que esta no arquivo bacula-fd.conf, que é o arquivo de configuração do File Deamon.

- FileSet: aqui é configurado quais arquivos e diretórios serão e quais não serão feito backup. Caso seja informado uma pasta, todos os arquivos e subdiretórios desta pasta estará incluído no backup. Esta diretamente ligado ao Client.

- Pool: Pool pode ser entendido como um agrupamento de dispositivos de backup, que no bacula é chamado de Volume. Um agrupamento de volumes é utilizado para definir propriedades iguais, dentro do Babula, para vários dispositivos. Por exemplo, dispositivos que serão usados em backups mensais são agrupados em um pool diferente de dispositivos que são usados em backups diários, pois eles devem ser mantidos por tempos bem diferentes.

- Schedule: É utilizado para agendar backup, definindo qual o tipo de backup e quando deve ser executado (sim, o Bacula tem uma agenda de backup própria).

- Storage: define o Storage Daemon e o dispositivo que será usado. Pode haver mais de um Storage e também mais de um dispositivo de cada storage. Esta ligado com as configurações do Storage Daemon no arquivo bacula-sd.conf.

- Job: define os “trabalhos” de backup. O Job é o que realmente realiza o backup, utilizando outras configurações do arquivo bacula-dir.conf. Dentro de um Job é utilizado “itens” da seção Client, Pool, Schedule, FileSet e Storage, ou seja, usa praticamente todas as seções.

Abaixo segue a esquematização dos arquivos de configuração do Bacula:

Acredito que com essas explicações já se possa ter uma visão básica sobre o Bacula. Continuarei com esse tutorial nos próximos post, até lá gostaria que fosse comentado sobre como melhorar esse tutorial, com dicas, críticas, correções, etc. Espero que este tutorial possa ser bastante útil.