Baixe o app para aproveitar ainda mais
Prévia do material em texto
Linux Solutions “Bacula” - Ferramenta Livre de “backup” por Heitor Medrado de Faria www.bacula.com.br 2 Sumário Capítulo 1 Conceitos Básicos de “backup”......................................................................................6 1.1. Mitos do "backup".........................................................................................................7 1.2. Conceitos.....................................................................................................................12 1.3. Tipos de “backup”.......................................................................................................14 1.4. Mídias de “Backup”.....................................................................................................16 Capítulo 2 Desenhando um Sistema de “backup”.........................................................................18 Capítulo 3 Políticas e Melhores Práticas ......................................................................................24 3.1. Políticas de "backup":.................................................................................................24 3.2. Melhores Práticas de "backup":.................................................................................25 Capítulo 4 Estratégias de "backup" e o Esquema GFS ................................................................26 4.1. Vantagens de um sistema de "backup" Centralizado (viabilizado pelo “Bacula”):......26 Capítulo 5 Questões sobre “backups” em Concursos....................................................................31 Capítulo 6 O que é o “Bacula”? ....................................................................................................37 6.1. Como ele funciona?.....................................................................................................37 6.2. Principais Características do “Bacula”:......................................................................40 6.3. O que há de novo na versão 5.0?................................................................................42 Capítulo 7 O “Bacula” e as Ferramentas Similares ......................................................................45 7.1. Amanda (livre):............................................................................................................46 7.2. “Arcserve” (proprietária).............................................................................................47 7.3. TSM (proprietária)......................................................................................................47 Capítulo 8 Instalando o “Bacula”..................................................................................................49 8.1. Instalando o Banco de Dados:.....................................................................................49 3 8.2. Instalando o “Bacula” (Linux):....................................................................................51 Capítulo 9 Configurando o “Bacula”.............................................................................................59 9.1. Passo-a-passo: Configurando o “Bacula” pela Primeira Vez.......................................59 9.2. bacula-dir.conf.............................................................................................................62 9.3. bacula-sd.conf.............................................................................................................87 9.4. bacula-fd.conf..............................................................................................................92 9.5. bconsole.conf..............................................................................................................93 9.6. Utilizando “Include” para organizar os arquivos de Configuração do “Bacula”.........94 9.7. Configurando: Ciclo de Vida dos Volumes..................................................................95 9.8. Configurando: Exemplo de “GFS” no “Bacula”...........................................................97 9.9. Configurando: Retenções do Bacula...........................................................................99 9.10. Configurando: Novos Clientes Bacula.....................................................................101 9.11. Configurando: Compressão dos "backups".............................................................102 9.12. Configurando: Migração e Cópia de Volumes.........................................................102 9.13. Configurando: Label Automático de Volumes no Bacula........................................107 9.14. Configurando: Desduplicação de Arquivos............................................................109 9.15. Configurando: Criptografia das Comunicações do Bacula (TLS)...........................111 9.16. Configurando: Criptografia dos dados Gravados no Storage................................118 9.17. A função da “pool scratch”......................................................................................121 Capítulo 10 Primeiros Passos com Fitas Magnéticas....................................................................122 10.1. Os dispositivos de Fita-Magnética..........................................................................123 10.2. Operações com Fitas...............................................................................................124 10.3. Manipulando Robôs-de-fitas:...................................................................................124 10.4. Usando robôs com múltiplos drives gravando simultaneamente:...........................131 10.5. “Spooling” de Dados...............................................................................................131 Capítulo 11 Comandos do “Bacula”...............................................................................................134 11.1. Lista Alfabética dos Comandos do “bconsole”:.......................................................134 11.1. Comandos especiais com Arroba (@) .....................................................................156 11.2. Executando o bconsole por Shell Script................................................................157 Capítulo 12 Restaurando Arquivos................................................................................................158 4 Capítulo 13 Restaurando Informações do Catálogo .....................................................................165 13.1. Restaurando catálogo MySQL a partir do arquivo .sql ("backup").........................165 13.2. bscan.......................................................................................................................166 Capítulo 14 Upgrade de Versões do Bacula..................................................................................168 Capítulo 15 Acessórios para o “Bacula”........................................................................................172 15.1 Interfaces Gráficas...................................................................................................172 15.2. Monitoração............................................................................................................175 Capítulo 16 16.1. Instalação do Webacula (GUI) – Versão: 3.*......................................................176 16.1. Instalação e Configuração:......................................................................................177 Capítulo 17 “Backup” de Aplicações Específicas com o “Bacula”.................................................183 17.1. "backup" de Máquinas Virtuais...............................................................................183 17.2. "backup" de Bancos de dados.................................................................................18617.3. Servidores Web.......................................................................................................193 17.4.Serviços de Email.....................................................................................................193 17.5. Serviços de Diretório..............................................................................................198 Capítulo 18 “Bacula Disaster Recovery” no Linux........................................................................199 18.1. “Bare Metal Recovery” usando um Disco de Emergência do “Bacula” .................199 Capítulo 19 Bacula no “Windows”” ..............................................................................................208 19.1. Instalando um Servidor Bacula no “Windows”.......................................................209 19.2. Botando para Funcionar.........................................................................................211 19.3. Configurando o “Bacula”.........................................................................................211 19.4. Operando o “Bacula”...............................................................................................213 19.5. Clientes “Windows”.................................................................................................214 19.6. Modificações no Servidor Específicas para os Clientes Windows..........................214 19.7. VSS Shadow............................................................................................................218 19.8. Disaster Recovery no Windows...............................................................................218 5 Anexo I Códigos de “status” do “Bacula” ...............................................................................225 Anexo II Comparativo Entre as Ferramentas de “Backup”......................................................228 6 Capítulo 1 Conceitos Básicos de “backup” O “backup” (ou cópia de segurança) consiste na cópia de dados específicos (redundância), para serem restaurados no caso da perda dos originais. A cópia pode ser realizada para o mesmo computador, para um dispositivo de armazenamento ou, ainda, em outro prédio ou localidade. Desta forma, protegendo os dados também contra acidentes que possam acometer fisicamente a estrutura. Independente de como os dados forem perdidos (apagamentos acidentais, corrupção dos dados, etc.), um “backup” eficiente consiste naquele que minimiza os impactos desta perda, possibilitando a restauração do arquivo ou serviço no menor tempo possível e com o minimo de defasagem em termos de alteração das informações. Os dispositivos de armazenamento mais comuns são o “DVD, disco rígido, disco rígido externo, fitas magnéticas e a cópia de segurança externa. Esta última, transporta os dados por uma rede como a Internet para outro ambiente, geralmente para equipamentos mais sofisticados, de grande porte e segurança. 7 As cópias de segurança podem variar de acordo com a natureza dos arquivos, com as necessidades empresariais e com a infra-estrutura disponível. Ainda, algumas métricas devem ser observadas: tempo de execução (janela de “backup”), a periodicidade, a quantidade de exemplares das cópias armazenadas, o tempo que as cópias devem ser mantidas, a capacidade de armazenamento, o método de rotatividade entre os dispositivos, a compressão e encriptação dos dados. Quanto a topologia, os “backups” podem ser classificados entre “centralizados” ou “descentralizados”. Na modalidade “centralizada”, geralmente há um servidor que comanda a realização de cópias de segurança, conferindo uma maior praticidade na administração e economicidade pelo armazenamento dos dados em poucos dispositivos, ocorrendo aí um ganho pela escalabilidade. Geralmente o “backup” é realizado pela noite, para que haja mínima possibilidade de impacto aos serviços utilizados em horário administrativo. 1.1. Mitos do "backup" 1.1.1. O “ROI” do Serviço de "backup" Em se tratando de um serviço relativo à área da “Segurança” em Tecnologia da Informação, o serviço de "backup" não poderia faltar à regra: trata-se de um aspecto cujo retorno de investimento se mostra praticamente impossível de ser quantificado. “Os benefícios são muito teóricos e incertos para que as empresas possam levá-los a sério como justificativa de investimento por si só. Para a maioria dos projetos em segurança da informação, é simplesmente impossível quantificar antecipadamente um ROI financeiro. Portanto, as organizações devem reagir com ceticismo a cálculos ou modelos de ROI divulgados por vendedores de soluções em segurança que não sejam substanciados por uma rigorosa pesquisa anterior, personalizada de acordo com o contexto de 8 cada organização.”1 Ao longo do tempo, algumas companhias que experimentam um número limitado de falhas tendem a reduzir a atenção e o orçamento para "backup", considerando eles, de certa forma, menos necessários. Ou ainda, simplesmente deixam de fazer as devidas expansões indicadas pela Gerência de Capacidade, fazendo com que o sistema não atenda adequadamente à demanda. Necessário ter em mente que "backups” e contratos de seguro não possuem muita diferença: “Similar às apólices de seguro são um investimento nos quais é preferível deixar de precisar do que usá-los” - conforme as palavras do autor Preston de Guise2. Portanto, a não-ocorrência de demandas para a restauração de arquivos não pode, de forma alguma, constituir uma justificativa para que o serviço de cópias de segurança seja realizado de maneira precária – ou pior: que se deixe de fazê-lo. Uma vantagem das soluções em software livre consiste no fato de poderem ser testadas e, dessa forma, obter uma flutuação menor na estimativa do ROI. 1.1.2. "Backup" não se confunde com o Gerenciamento do ciclo-de-vida da Informação ("ILM – Information Lifecycle Management") Muito tem se falado sobre o ILM atualmente – inclusive, alguns desenvolvedores de ferramentas para "backup" tem advogado no sentido de que seria um dos papéis das mesmas. Ocorre que o Gerenciamento do Ciclo-de-vida da Informação consiste em um processo que abrange muito mais elementos, como: a auditoria, indexação, criação, atualização, deleção, aspectos de armazenamento e de acesso. Portanto, o "backup" estaria dentro, ainda, de uma subdisciplina do ILM, que seria o ILP (“Information Lifecycle Protection” – ou Proteção do Ciclo-de-vida da 1 Rodrigo Faustini: http://www.faustiniconsulting.com/artigo10.htm 2 Tradução do mesmo livro: "backup" & Recovery: A Corporate Insurance Policy, p. 7, Preston de Guise. 9 Informação), que também conteria uma série de outros fatores: a) proteção proativa contra a perda de dados – que pode constituir em anti- vírus ou outros aspectos em nível de aplicação, por exemplo; b) alta disponibilidade; c) redundância de sistemas; d) e se mesmo assim houver perda na informação, a restauração dos dados, previamente armazenados pelo serviço de "backup", seria executada. 1.1.3. O serviço de "backup" versus sistemas de tolerância a falhas “Tolerância a falhas é a propriedade que permite que sistemas (em geral, computacionais) continuem a operar adequadamente mesmo após falhas em alguns de seus componentes. Se sua qualidade de operação diminui, a queda é proporcional à severidade da falha. A tolerância a falhas é propriedade inerente em sistemas de alta disponibilidade…”3 Desta forma, o “backup” não vem, de forma alguma, constituir um elemento de tolerância a falhas. Entretanto, trata-se de um importante elementoda recuperação de falhas (inclusive o tempo necessário para a restauração de arquivos – e consequentemente de serviços, deve ser considerada uma métrica importante para a escolha do hardware e software utilizado pela cópia de segurança). Algumas empresas tendem a imaginar que sistemas tolerantes a falhas diminuem a necessidade por "backups". Entretanto os sistemas de tolerância a falha são caros (nem sempre podendo ser implementados em todos os pontos críticos do parque computacional) e, em nenhuma hipótese, podem ser considerados 100% eficazes. 3 Conceito da Wikipédia: http://pt.wikipedia.org/wiki/Tolerância_a_falhas_(hardware) 10 “nada corrompe mais rápido do que um espelho” – máxima que traduz o fato de que discos redundantes, por exemplo, não estão imunes à corrupção de dados – muito menos à deleção acidental de arquivos. Portanto, os “backups” permanecem como uma necessidade imperativa para a grande maioria dos sistemas. 1.1.4. Relação Riscos X Custos dos "backups” Os riscos da atividade de TI geralmente podem ser divididos em duas grandes áreas: os riscos operacionais e os comerciais. Em contrapartida, sabemos que nem todos as chances de perdas de dados podem ser evitadas – por mais caros que sejam os sistemas de proteção (ex.: um maremoto de proporções globais, uma guerra nuclear mundial, etc.). Deixando de lado as hipóteses catastróficas (nas quais provavelmente a restauração dos dados não será mais importante), deve ser feito um gerenciamento de capacidade constante no sentido de verificar a relação risco versus custo dos sistemas de "backup", principalmente quando as opções são plurais. Exemplo: a armazenagem das cópias de segurança em edificação diversa de onde foram gerados – protegendo assim as mídias de um possível incêndio, seria preferível em relação à compra de um cofre anti-chamas? Ou ainda: seria interessante fazer um "backup" redundante (ou seja, duas cópias de segurança), de determinados dados? Isto posto, necessário levar em consideração uma série de fatores, como a criticidade e natureza das informações, o grau de maturidade dos usuários, a periodicidade da atualização dos dados, etc. 1.1.5. As ferramentas de "backup" nativas dos Sistemas Operacionais seriam suficientes e/ou mais confiáveis que as ferramentas específicas para este serviço? Os softwares nativos dos sistemas operacionais carecem de uma qualidade 11 essencial no âmbito dos "backups” – interoperabilidade. Dessa maneira, impossível (ou excessivamente difícil) realizar cópias de segurança de vários servidores em apenas um “storage” – o que representa uma enorme economia com recursos de armazenamento. Ainda, teríamos um maior custo pela manutenção e administração descentralizada de aplicações heterogêneas de "backup". Mesmo as ferramentas proprietárias de cópias de segurança são consideradas mais eficientes quando comparadas com as nativas – e em relação à confiabilidade, não estariam há anos no mercado se não tivessem esta qualidade. O mesmo, analogamente, vale para as soluções livres. Existem outras funcionalidades importantes que dificilmente são encontradas em ferramentas nativas, a saber: a) possibilidade de “backups” e “restores” cruzados (ou seja, através da rede – de uma estação para outra diversa); b) “restores” rápidos utilizando apenas as mídias necessárias para o trabalho; c) catálogo para indexar os arquivos gravados, facilitando a buscar pelos arquivos gravados; d) manipulação de robôs-de-fitas; e) ferramentas de recuperação de desastres. 1.1.6. “Scripts” bem elaborados para “backup” podem suprir a necessidade de uma ferramenta específica? A elaboração de “scripts” para “backup” consiste em um “retrabalho”, na medida que já existem aplicações bastante maduras desenvolvidas sob licenças “livres”. Ademais, tratar-se-ia de uma solução única, apenas utilizada no ambiente no qual se encontra em produção e, desta forma, impossível qualquer forma considerável de suporte externo ou compartilhamento de experiências em outros cenários. 12 A continuidade da solução também estaria prejudicada se não houvesse uma detalhada documentação interna sobre os “scripts”, bem como os custos para o aprendizado seriam mais elevados do que com uma ferramenta de “backup” comum. De igual sorte, as aplicações proprietárias de “backup” eventualmente realizam testes de performance que dificilmente seriam superados por um “script”. Segue o exemplo: “Em 2004, um vendedor de "backup" comercial publicou seu recorde de velocidade, realizando o "backup" de 10 TB das informações de um cliente real, com uma taxa de transferência ao nível de arquivo de 2.6 Gb/s. É razoavelmente seguro dizer que poucos, para não dizer nenhum, administrador de sistemas desenvolveria um script que atinja uma performance de "backup" nessa escala”4 1.2. Conceitos 1.1.1. Retenção: período pelo qual determinada informação não pode ser apagada do banco de dados ou da mídia de "backup" – a não ser por especial intervenção humana. 1.1.2. Expiração: término do prazo de retenção. 1.1.3. “Job”: trabalho de “backup” ou de “restore”. No caso do “Bacula” ainda há os “jobs” de verificação. 1.1.4. “Purge”: ato de eliminar os dados do catálogo a respeito de determinado volume (“files, jobs”, etc.). Entretanto, permanecem o “label” no catálogo e os dados na fita. 1.1.5. “Prune”: ato de eliminar entradas provavelmente já não necessárias 4 Extraído do livro: "Backup" & Recovery: A Corporate Insurance Police, p. 15, Preston de Guise. 13 no banco de dados (exemplo: arquivos e jobs expirados dos volumes. 1.1.6. SAN (“Storage Area Network”): Rede seccionada com o objetivo de isolar o tráfego destinado a “backup”, tanto por segurança quanto por performance. Utiliza protocolo SCSI. 1.1.7. Volume: divisão (espécie de caixa) reservada para o armazenamento dos dados de “backup”. Compartimento lógico no qual os “backups” serão armazenados. Pode ser criado em fitas, HD, etc., sendo que cada fita somente poderá conter 01 (um) volume lógico. 1.1.8. “Pool” (grupo): conjunto de volumes com características semelhantes (ex.: tempo de retenção). De igual sorte, trata-se de um dispositivo de segurança (se o “backup” utilizando determinada pool é agendado não poderão ser utilizados volumes de outra). O volume herda as características da pool. 1.1.9. “FileSet”: lista de diretórios (ou arquivos) que serão "backupeados". Pode ser utilizado para um ou vários servidores. Geralmente deve excluir diretórios desnecessários (/proc, /tmp). No Bacula, são suportadas expressões regulares para excluir ou incluir arquivos com nomes e/ou terminações específicas. 1.1.10. Catálogo: é o responsável por armazenar um índice de todos os arquivos armazenados pela ferramenta de "backup". Fica armazenada em um banco de dados. A vantagem do Bacula, é que ele suporta 3 bancos diferentes (e livres) para armazenamento do catálogo. 1.1.11. Janela de “backup” (“backup window”): consiste no tempo máximo de duração na qual pode ser executado um "job" de "backup" ou restore, de maneira a não gerar impactos para os usuários do respectivo servidor. Por isso, na maioria das vezes, os "backups" são agendados logo após o expediente administrativo, momento em que os dados já não devem sofrer tantas alterações e, assim, aumentando a fidelidade da cópia de segurança. Lógico que, determinadas aplicações, possuem uma grande atividade ininterrupta (24x7) - nestas, nas quais não há janela de "backup", o horário de realização do "backup" torna-se menos importante. 1.1.12.Política de “backup”: trata-se em um documento corporativo onde 14 devem estar delineadas de maneira genérica (sem explicitar produtos específicos), como devem ser feitos os “backups” dentro da corporação. Deve seguir as normas ISO referentes ao tema, tentando ao máximo seguir as orientações de armazenamento e descarte de mídias, além de outras melhoras práticas descritas. Deve especificar as retenções para cada aplicação e, de igual sorte, o nível do “backup” (o quê deve ser armazenado). 1.1.13. MTBF (“Mean Time Between Failure”): conceito muito importante, que diz respeito ao tempo médio que determinado hardware (ou suprimento) deve ser utilizado com segurança, com a mínima probabilidade de erros. Exemplo: o MTBF de fitas magnéticas é, em geral, 5 anos - ou seja, depois deste período indica-se que sejam trocadas. 1.1.14. GFS (“grandfather, father, son”): estratégia de rotação de fitas mais utilizados pelos administradores. É viabilizado através da utilização de uma hierarquia de "pools" com tempos diferentes de retenção, gerando uma grande economia com mídias. Será explicado em outros capítulos. 1.1.15. “Tape virtualization”: a diminuição no custo dos HD (por Gb), aliado a um ganho de confiabilidade, fez com que atualmente seja muito utilizado para “backups”, em substituição à fita magnética. “Tape virtualization” nada mais é do que a criação de múltiplos volumes de “backup” nestes HD, simulando um robô-de-fitas. Assim, é possível implementar estratégias de retenção como o GFS. 1.1.16. "backup" Cruzado: “backup” realizado remotamente, de uma máquina para outra (ou para um “storage” independente, através da rede. 1.3. Tipos de “backup” 1.2.1. “Full” – faz cópia de todos os arquivos definidos na configuração da ferramenta, independente que os arquivos da lista ("file set") terem sido alterados ou não. Geralmente é realizado quando o servidor é “backupeado” pela primeira vez, ou no início de cada ciclo de "backups" (ex.: Ciclo Semanal GFS). Como é um "backup" mais longo, geralmente é iniciado na sexta-feira ou sábado, para que tenha a janela do final de semana para ser realizado. 15 Se for o "backup" mais atual, apenas uma mídia será realizada para restore (considerando um "backup" monovolume). Entretanto, se mostra um tipo de "backup" extremamente caro para ser realizado diariamente, principalmente pela excessiva quantidade de suprimentos (armazenamento) gastos. 1.2.2. Diferencial – faz o “backup” apenas dos arquivos modificados a partir do último “backup full”. Exemplo: um "backup" Full ocorreu no sábado; um "backup" diferencial realizado na segunda só conterá os dados alterados ou criados na segunda; se na terça-feira for gravado outro "backup" diferencial, ele novamente vai gravar os arquivos alterados ou criados, desde que se gravou o "backup" Full, isto é, os arquivos de segunda e terça. Assim, requer menor capacidade de armazenamento e resulta em "backups" mais rápidos. Em contrapartida, a restauração fica mais complexa, pois necessita sempre de até dois volumes (um “full” e possivelmente o último diferencial). 1.2.3. Incremental – faz cópia apenas dos arquivos modificados a partir do último “backup” diferencial. Ao contrário do diferencial, se for feito um "backup" Incremental após outro Incremental, o segundo "backup" não irá conter os dados do primeiro. Apesar de ser o tipo mais rápido de “backup”, tende a deixar a restauração demasiadamente complexa, na medida que pode exigir vários volumes (o full e todos os demais incrementais mais recentes). 1.2.4. Cópia – cópia secundária ou complementar de determinado volume de “backup” (redundante). Muito utilizada para “backup off-site”. O volume copiado é mantido intacto. 1.2.5. Migração – os dados de determinado volume são migrados para outro, sendo que o primeiro deixa de existir. Pode ser útil quando há suspeitas de erros de leitura e/ou gravação em determinada mídia de armazenamento (ex.: fita, HD, etc.) e, dessa forma, os dados precisam ser movidos para um meio saudável. Você consegue identificar os principais elementos e tipos de “backup” da empresa onde trabalha? 16 1.4. Mídias de “Backup” 1.4.1. Tipos: Fita magnética: As fitas magnéticas geralmente trazem a capacidade no seguinte formato: não-compactado / compactado. Ex.: 20 / 40 Gb. Esta é uma compactação via “hardware” realizada pelo próprio “drive”, e deve ser privilegiada em relação a compressão via “software”. A quantidade de dados compactados gravados varia de acordo com a natureza original das informações (ex.: arquivos já compactados como .mp3, .jpg, .zip, etc.). Quanto mais compactados os dados, menos poderão estar contidos numa mesma fita. Alguns modelos de fita5: a) Digital Data Storage (DDS) - as capacidades mais recentes são DDS-4 (20/40GB e 3.2 MB/s de gravação / leitura) e DDS 72 (36/72GB, com mesma taxa de transmissão). DDS 160 (capacidade: 80/160Gb e “throughput” de 6.9MB/s) b) Digital Linear Tape (DLT) – capacidades: 40, 300 e 800 Gb, com taxas de 6, 36 e 60 Mb/s respectivamente. c) Linear Tape-open (LTO) – capacidades recentes: 200/400Gb (LTO-2), 400/800GB (LTO-3) e 800/1.6Tb (LTO-4), com taxas de transmissão de 40, 80 e 120 Mb/s. Mídia óptica: A falta de uma capacidade, durabilidade e confiabilidade ampliadas, fizeram com que esse tipo de mídia não fosse tão utilizada para fins de “backup”. Disco rígido: O fato dos discos rígidos estarem sempre acessíveis para o sistema 5 Barros, E. Entendendo os Conceitos de Backup, Restore e Recuperação de Desastres. Editora Ciência Moderna, Rio de Janeiro, 2007. 17 operacional, aliada a diminuição no custo por “gigabyte” e aumento de confiabilidade, fizeram com que aumentasse a aplicabilidade dos HD para o armazenamento dos “backups”. Atualmente, se mostra uma boa opção para pequenas e médias empresas, já que o investimento inicial é baixo (ao contrário dos robôs de fita). É escalável, na medida que basta a aquisição de mais discos para que seja ampliada a capacidade de armazenamento. A facilidade de operação também é um dos pontos fortes. Enquanto com robôs-de-fita só é possível ler ou escrever em uma fita, por “drive”, de cada vez, num disco rígido é possível a leitura e gravação simultânea de todos os seus volumes (ex.: “backup” e “restore” simultâneo). No caso dos discos, é recomendável a criação de vários volumes dentro de um mesmo disco (no mínimo 04), para otimizar seu uso (evitar a perda de espaço ocioso). De igual sorte, alternar o “schedule” de maneira a utilizar os vários discos (no mínimo 02), de maneira alternada, para que a perda de um dos discos não represente a perda de todas as informações de “backup” já gravadas O “Bacula” suporta todos os tipos citados de mídias. 1.4.2. Quanto ao local de armazenamento: “Backup” on-site: Neste caso, os dados ficam armazenados no mesmo prédio de origem (servidor). Assim, a ocorrência de catástrofes físicas (ex.: incêndio) poderia afetar não apenas o dado original, mas também a cópia de segurança. O “backup” on-site é aceitável quando existe a existência de cofres anti- chamas para armazenamento das mídias. 18 “Backup” off-site: Oposto do “backup on-site”, os dados ficam armazenados em localidade diversa dos dados originais. É uma das características do “backup em nuvem”. Capítulo 2 Desenhando um Sistema de “backup” Utilizando alguns fundamentos do Gerenciamento de Projetos, vamos planejar (e executar!) a instalação de um sistema de “backups”. 19 Termo de Início do Projeto: Implementar Sistema de “backup” (preferencialmente automatizado), que salvaguardeinformações essenciais - ou seja - que minimizem o impacto da perda de dados e/ou parada dos serviços de TI. O que deve ser levantado no planejamento: 2.1. Prospecção sobre a existência / elaboração de uma política de “backup”. Trata-se de um documento normativo que trará as diretrizes para os sistemas de “backup” da empresa, devendo ser constituído antes mesmo da EAP (este assunto será abordado no próximo capítulo). 2.2. Levantamento da natureza dos serviços e dados que serão protegidos. Aqui, necessário equilibrar padronização (de agendamentos, níveis, retenções, etc.) em relação com as diferentes necessidades da organização. Um ambiente muito complexo pode trazer dificuldades na administração dos “backups”. Importante também, verificar seu SLA (“service level agreements” / acordo de níveis de serviço), para saber a periodicidade adequada dos “backups”, além do prazo pactuado para restauração de arquivos. De igual sorte, para cada aplicação, estudar se existem rotinas especiais que precisam ser seguidas para a realização de um "backup" confiável (Exemplo: "dump" de um banco de dados que não suporta "backup on-line"). A maioria das aplicações, traz em sua documentação quais arquivos ou como deve se proceder para efetuar cópias de segurança. 2.3. Levantamento dos Sistemas Operacionais envolvidos. Infelizmente, nem todas as soluções de "backup" são como o Bacula - cuja gratuidade de licença e compatibilidade entre módulos para diferentes sistemas operacionais, dispensa uma maior precisão nesta etapa da migração. 20 No caso das ferramentas proprietárias, a compra de uma licença para "backup" de máquina Linux, por exemplo, não serve para "backup" de uma estação “Windows” (e vice versa). Torna-se necessário um planejamento muito mais preciso e penoso - um verdadeiro exercício de imaginação (ou até clarividência), para adquirir licenças de um serviço tão dinâmico quanto cópias de segurança. De igual sorte, os módulos podem não ser compatíveis entre si, impossibilitando "backup" cruzado, ou modelo centralizado. O cerne da questão, aqui, consiste em saber se a solução de software a ser adquirida suporta todos os sistemas operacionais de sua empresa (ou ao menos a maioria) - de preferência com módulos compatíveis. Ainda, fundamental verificar se a ferramenta faz “backup” de arquivos abertos (nas soluções proprietárias, geralmente é cobrado um alto valor por esta funcionalidade adicional). 2.4. Levantamento da Quantidade de Dados a serem armazenados e Gerência de Capacidade. Estudos informam que as necessidades de "backup" crescem, em média, entre 20 e 25% ao ano. Entretanto, um bom planejamento se mostra importante para que não seja adquirida uma solução de software que fique obsoleta rapidamente. em contrapartida, seria desperdiçar recursos a compra de um storage superdimensionado às necessidades reais de armazenamento. Aqui, entra o Gerenciamento de Capacidade, conceito trazido pelo ITIL. Trata- se de assegurar que a capacidade da infra-estrutura de TI está adequada às demandas do negócio conforme a necessidade e no tempo. Boas alternativas são soluções baseadas em disco rígido, e que podem ser modularizadas. Um exemplo está no uso de “disk-arrays serial-ata” e “hot-swap”, que permitem inclusive configuração de RAID - caso não considere o uso de LVM ou BOF (“bunch of disks”) suficientemente segura. Se optar por “drives” de fita singulares (ou seja - sem alimentação automática: robô), tenha certeza que seu "backup" dificilmente irá requerer multi-volume (mais de uma fita para o "backup" full). Caso contrário, será penosa a atividade de troca de fitas do operados. 21 No caso de robôs de fita, a grande preocupação reside no "throughput" de seu(s) “drive”(s), na medida que a quantidade de fitas por "backup" não é tão importante, pois não requer intervenção manual. A quantidade de fitas de seu esquema pode aumentar muito, caso necessário - mas sua janela de "backup" não. Alguns robôs, suportam a instalação posterior de "drives" adicionais. Ainda, para “backups” centralizados ou cruzados (ou seja, que importem em tráfego de rede), verificar a capacidade de transferência de dados, bem como estações críticas, nas quais o "download" dos dados possa causar impacto ao usuário. Neste caso, uma alternativa seria a instalação de uma placa de rede adicional. 2.5. Prospectar o CMDB* (Banco de Dados de Configuração) na procura por equipamentos que possam ser alocados para o sistema de “backups”. Algumas vezes, encontramos tesouros perdidos em nosso parque de TI. Um “drive DDS”, com sorte um DLT. Somados, ou seja, como se fossem um conjunto de “storage”, podem fornecer uma boa capacidade de armazenamento e gravação para seus “backups”. O mesmo ocorre com os HD. Vale salientar que, no caso de mídias antigas, verificar o MTBF (ou validade) das mesmas. Também, tenha certeza do conteúdo das mesmas antes de reciclá-las. 2.6. Escolha e aquisição de software para a realização dos “backups”. Além dos aspectos já mencionados, o suporte ao "hardware" de armazenamento é fundamental - não só pela ferramenta a ser adquirida mas, também, pelo sistema operacional hospedeiro. As distribuições Linux costumam prover uma farta e estável compatibilidade com sistemas de fita / disco rígido, etc., aliadada à flexibilidade do “shell script”, configurando-se como ótima escolha para hospedar um servidor de “backups”. Necessário cuidado com a operação de "autochangers" (robôs de fitas) no que se refere aos tempos entre os comandos de operações (carga, descarga de fitas). Se este tempo (utilizado pela solução de "backup") for menor do que o necessário, 22 podem ocorrer desagradáveis travamentos. E se a ferramenta não permitir a modificação destes parâmetros, tudo indica que a integração entre as soluções será inviável. Não podemos esquecer que notificações por email facilitarão, e muito, a vida do administrador e operadores de “backups”. Ainda, a opção por uma ferramenta proprietária pode ocasionar um "aprisionamento tecnológico", na verdade que você não poderá mudar de solução, posteriormente, sem ter de renovar as licenças para poder restaurar o legado. 2.7. Eventual escolha e aquisição dos hardwares de armazenamento e servidor de "backup". Este é um dos últimos passos no planejamento de "backup", na medida que a maioria das informações que subsidiarão esta escolha, já foram levantadas. Tenha em mente que a solução adquirida deverá permanecer, no mínimo, por 5 ou 7 anos (quando então já estará obsoleta, com dificuldade em adquirir suprimentos ou peças de reposição). Soluções definitivas nunca serão uma opção. As opções mais usuais são o “drive” de fita manual (para soluções de até 1.2 “terabytes” - LTO4), o robô de fitas (mais caros e, portanto, para capacidades superiores) e sistemas baseados em discos rígidos (que, no caso, atendem a todas as necessidades de armazenamento, independente do tamanho). Os dispositivos ópticos, apesar de muito promissores, ainda se mostram muito limitados em termos de capacidade, podendo ser utilizados, apenas, para pequenos projetos. 2.8. Levantamento e preservação do legado de “backup” de antiga ferramenta (em caso de migração). A maneira mais usual de se preservar determinado legado de “backup” (ou seja, “backup” realizado por solução que não está mais em produção na empresa), consiste em manter um conjunto alternativo (software e hardware) para restauração de arquivos antigos. 23 Entretanto, podem ser utilizados outros métodos: coexistência de soluções numa mesma estação (compartilhando o hardware de '"backup"”, de maneira sempre alternada),ou ainda, a transferência de dados da solução antiga para a atual, através de "restores" e novos "backups". Esta última, apesar de econômica em termos de ocupação de "hardware", pode gerar um grande trabalho manual e comprometer a integridade dos dados. Por ser tão problemática, a migração de sistemas de "backup" deve sempre ser planejada com cautela, inclusive evitando as diversas limitações impostas pelas licenças de "software" proprietário. 24 Capítulo 3 Políticas e Melhores Práticas 3.1. Políticas de "backup": A existência de uma política de "backup" em sua empresa, por si, está dentro do considerado como “melhores práticas”. Consiste em um documento que deverá conter os princípios de como ocorrerão os “backups” (e “restores”), bem como o papel das partes interessadas, o tempo máximo para a resolução das ocorrências, a estratégia de "backup", etc. Entretanto, deve ser genérico o suficiente para permitir liberdade razoável de escolha das ferramentas de "backup", bem como as soluções de “hardware”. Ex.: pode especificar que o “backup” será feito (preferencialmente) em mídia magnética e de maneira automatizada (robôs de fita), mas nunca especificar fabricantes, modelos, referências, etc.). Vale salientar que é importante estar de acordo com os SLA* ou OLA* existentes, para não gerar divergência entre a política e os contratos. 25 3.2. Melhores Práticas de "backup": Exemplos: − Estratégia de "backup" condizente com a natureza dos dados armazenados. − Testes de “restore” periódicos. − Auditorias periódicas, inclusive com gerência de capacidade do sistema. − Operador de fitas, administrador de “backup” e administrador de “restore” devem ser sempre pessoas diferentes. − Constante documentação (inclusive banco de soluções). − Alta disponibilidade. − Planejamento e simulações de "disaster recovery". − Exigência de "ticket" para “restore” − "Desejável" ticket para cada dia de realização dos “backups”, para que seja informado se foram concluídos corretamente. − Deve haver um procedimento formal de descarte das mídias não mais necessárias (ex.: trituração, incineração, etc;) − Adequação à norma ISO 27002 26 Capítulo 4 Estratégias de "backup" e o Esquema GFS 4.1. Vantagens de um sistema de "backup" Centralizado (viabilizado pelo “Bacula”): - Economia de fitas na medida que é minimizada a quantidade de espaço subutilizado. - Facilidade na administração, correção de erros, troca e controle de fitas. - Economia de “hardware” (“storages”). - Maior agilidade (“time sharing”). −Facilidade no “restore” (catálogo único) 27 4.1.1. Esquema GFS (“Grandfather-father-son "backup"”): “Grandfather-Father-Son” "backup" se refere ao mais comum esquema de rotação de mídias para "backup". Originalmente concebido para o "backup" em fitas, funciona bem para qualquer estrutura de "backup" hierárquico. O método básico consiste em criar 3 conjuntos de "backup", sendo um diário, um semanal e outro mensal. Os "backup" diários ou “filhos”, são rotacionados a cada dia com um semanal (ou pai) a cada semana. O "backup" semanal é rotacionado, em bases semanais, com um mensal (“ou avô”). Ocasionalmente, um volume pode ser removido do esquema para estabelecer um marco (“milestone”), ou para fins de “Disaster Recovery”). Os administradores de rede consideram o GFS como método mais simples e efetivo de rotação de fitas. Benefícios:. - Proteção de seus arquivos com um mínimo número de fitas (normalmente apenas uma ou duas são necessárias para o "restore" de um servidor), reciclando (sobrescrevendo) algumas fitas e arquivando outras. - Reduz o desgaste das fitas e/ou outros dispositivos ligados ao "storage". - Facilidade na localização de arquivos armazenados, devido à sistematização dos "backups". Ainda não entendi. O que é GFS? A estratégia de rotação GFS é baseada numa agenda de 7 dias (Domingo - Sábado), na qual é feito ao menos um "backup" “full” a cada semana. Nos demais dias, são feitos "backups" diferenciais (diários). O “"backup" full” realizado durante a semana (geralmente na sexta-feira a noite, ou sábado), será sempre considerado como ""backup" semanal". Então, as fitas diárias podem ser recicladas depois de 7 dias e as semanais após um mês - mas esse 28 assunto será abordado em maior profundidades. Alguns exemplos de agendamento semanal: SUN MON TUES WED THUR FRI SAT None Diff* Diff Diff Diff FULL None *WEEKLY* Exemplo 2: SUN MON TUES WED THUR FRI SAT Diff Diff* Diff Diff Diff Diff FULL "backup" *WEEKLY* *Diff = "backup" diferencial. Na terminologia GFS, o “backup” diário é o filho e o semanal, o pai. O último “"backup" full” de cada mês (o primeiro ou ainda outro), será considerado o "backup" mensal (“monthly”) - ao invés de semanal. Este é o avô. Os "backups" mensais, devem ser armazenados por um período maior (meses, ou até anos), de acordo com a política de “backup” existente. Exemplo Mensal: SUN MON TUES WED THUR FRI SAT 1 2 3 4 5 6 7 None Diff* Diff Diff Diff F-WKLY** None Tape 1 Tape 2 Tape 3 Tape 4 Tape 5 8 9 10 11 12 13 14 None Diff* Diff Diff Diff F-WKLY** None Tape 1 Tape 2 Tape 3 Tape 4 Tape 6 15 16 17 18 19 20 21 None Diff* Diff Diff Diff F-WKLY** None Tape 1 Tape 2 Tape 3 Tape 4 Tape 7 22 23 24 25 26 27 28 None Diff* Diff Diff Diff F-WKLY** None 29 Tape 1 Tape 2 Tape 3 Tape 4 Tape 8 * Diff "backup" diferencial. **F-WKLY=Full Semanal (WEEKLY). Reciclagem de Fitas: Por padrão, o "backup" reutiliza as fitas diárias semanalmente (ou seja, uma mesma fita sempre vai fazer o "backup" da segunda-feira, etc). As semanais, devem ser reutilizadas para cada sexta-feira (por exemplo) do mês, ou seja: uma fita será sempre utilizada na segunda sexta do mês, etc. Seguindo o exemplo, você teria a proteção de 1 ano de "backups", utilizando 4 fitas diárias, 4 semanais, e 12 mensais. Obviamente, este número pode aumentar em caso de "backups" multi-volumes, ou se o tempo de retenção (reciclagem) for menor que o padrão. Dica - GFS diário avançado: Sabendo que os "backup" diferenciais diários ocupam menos de 10% do volume, ao invés das 4 fitas necessárias no padrão GFS comum (que gera uma necessidade diária pela troca das mídias), pode ser implementado o seguinte esquema. Semana 1: (fita a) para todos os "backups" diferenciais diários é utilizado uma mesma fita, com retenção de uma semana. Semana 2: (fita b) uma segunda fita é colocada, e será utilizada durante toda esta segunda semana, a não ser para realização do "backup" full semanal, que será feito em uma fita específica. Semana3: (fita a) agora reciclamos a "fita a", que receberá os "backups" diários desta semana. Semana 4: (fita b) ... 30 A grande vantagem deste esquema, é que o risco de danos à fita provavelmente de ejetamento (ou montagem) no drive é diminuído, pois menos trocas de fitas são necessárias. Entretanto, as fitas são gravadas e regravadas em um ritmo mais acelerado. 31 Capítulo 5 Questões sobre “backups” em Concursos 5.1 Concurso SERPRO 2008 - Cargo I*: *Autoria da CESPE (Gabarito ao final). 5.1.1. Considerando a figura seguinte, que apresenta um diagrama esquemático de funcionamento de um ambiente corporativo, na qual se destaca um sistema de virtualização de fita, julgue os itens de 89 a 97, a respeito de armazenamento de dados: 32 89 O eventual uso de cachês junto ao elemento F teria como um de seus principais objetivos reduzir a latência no acesso aos dados. 90 Os elementos F, G e H possuem a mesma finalidade básica de suportar a realização de "backup" e restore, sendo que G e H variam quanto ao tamanho da janela de operaçãoque deve ser aberta por seus clientes, a qual é maior em G que em H. 91 O padrão de fita LTO, empregado em muitos sistemas de "backup" em fita, possui elevada capacidade de armazenamento de dados, sendo que uma única fita é 33 capaz de armazenar entre 4 a 8 “terabytes” de dados, inclusive com o uso de compressão e criptografia. 92 A velocidade de transmissão de dados entre os elementos A e D é usualmente superior à velocidade alcançada na transmissão de dados entre C1 e G. 93 Quanto à diversidade e necessidade de sistemas e algoritmos de escalonamento de recursos, é correto afirmar que ela é crescente na sequencia dos dispositivos: G, H e F. 94 O uso de espelhamento remoto de dados apresenta maior correlação entre os dispositivos H e F, que entre os dispositivos H e G. 95 Considere diversas estratégias para transferência de dados entre os vários dispositivos apresentados. A que permite o uso de G ou H como elemento intermediário na transferência de dados entre C1 e C2 é denominada “server-to- server”; que permite o uso de H como elemento intermediário na transferência de dados entre G e F é denominada “storage-to-storage”. 96 Com relação a diferenças nas abordagens de conectividade empregadas nos elementos ligados a E, é correto afirmar que o uso de interfaces de canal de fibra (“fibre channel”) apresenta maiores vantagens sobre o uso de interfaces SCSI, mesmo a primeira sendo de natureza paralela, enquanto que interfaces SCSI são seriais; e o protocolo de transporte FCP (“fibre channel protocol”) não pode ser empregado sobre interfaces físicas do tipo SCSI. 97 Considerando as similaridades nos protocolos de comunicação empregados nos elementos B e E, é correto afirmar que ambos podem usar o protocolo TCP/IP, especialmente se E permite, em pelo menos uma de suas portas, o uso do protocolo FCIP (“fibre channel over IP”). Gabarito: 34 5.2 Prova do CGU aplicada pela banca ESAF para o cargo de Analista de Finanças e Controle – Área – Tecnologia da Informação / 2004: 5.2.1. Com o objetivo de restaurar informações deve-se fazer cópia de segurança ("backup") que, no sistema operacional “Windows”, pode ser do tipo: a) Diferencial, no qual são copiados somente, entre os arquivos selecionados, os arquivos modificados no dia corrente. O atributo arquivo é desmarcado. b) Diferencial, no qual todos os arquivos selecionados devem ser copiados, independentemente de estarem ou não com seu "backup" atualizado. Este tipo de "backup" não atualiza o atributo arquivo. c) Cópia, no qual somente serão copiados, entre os arquivos selecionados, aqueles que estiverem desatualizados (com seu atributo arquivo marcado). Este tipo de "backup" não afeta o atributo arquivo. d) Incremental, no qual todos os arquivos selecionados devem ser copiados, independentes de estarem ou não com seu "backup" atualizado. Todos os arquivos copiados terão seu atributo arquivo desmarcado. e) Incremental, no qual somente serão copiados, entre os arquivos selecionados, aqueles que estiverem desatualizados (com seu atributo arquivo marcado). Todos os arquivos copiados terão seu atributo arquivo desmarcado. 5.2.2. A respeito dos sistemas de "backup" das organizações é incorreto afirmar que: a) a política de "backup" compreende os procedimentos e a infra-estrutura necessários à proteção de informações com o objetivo de possibilitar a continuidade de suas atividades. b) é recomendável que cada sistema crítico para uma organização tenha pelo 35 menos duas cópias: uma em local próximo, para recuperação imediata e outra em local distante, para permitir a recuperação em caso de desastres com maiores dimensões. c) a estratégia de "backup" precisa estar focada em objetivos distintos e que não abrangem os requisitos de negócio e ambiente operacional da empresa. d) uma arquitetura de "backup" e recuperação deve incluir um plano de prevenção de desastres, procedimentos e ferramentas que ajudem na recuperação de um desastre ou falha de energia, além de procedimentos e padrões para realizar a recuperação. e) a recuperação dos dados define os procedimentos necessários ao retorno da operação normal dos sistemas. Se esta recuperação não funcionar, o "backup" não terá utilidade. 5.3. Prova da Receita Federal aplicada pela banca ESAF para o cargo de Auditor Fiscal da Receita Federal – Área Tecnologia da Informação / 2005. 5.3.1. Um planejamento detalhado é o ponto de partida para a eficácia de um plano de "backup" e recuperação. Na implementação de uma solução eficaz de "backup" e recuperação, incluindo planos de prevenção de desastres e planos de recuperação de desastres, o "backup" incremental é aquele que: a) captura os dados que foram alterados desde o último "backup" total. Necessita-se de uma fita de "backup" total e da fita incremental mais recente para executar uma restauração completa do sistema. Ele não marca os arquivos como tendo sido submetidos a "backup", ou seja, o atributo de arquivamento não é desmarcado. 36 b) captura todos os dados, incluindo arquivos de todas as unidades de disco rígido. Cada arquivo é marcado como tendo sido submetido a "backup", ou seja, o atributo de arquivamento é desmarcado ou redefinido. Uma fita atualizada de "backup" incremental pode ser usada para restaurar completamente um servidor em um determinado momento. c) mantém dados redundantes, pois os dados alterados e não alterados são copiados para fi tas sempre que um "backup" incremental é executado. d) captura todos os dados que foram alterados desde o "backup" total ou incremental mais recente. Deve-se usar uma fi ta de "backup" total (não importa há quanto tempo ela tenha sido criada) e todos os conjuntos de "backups" incrementais subsequentes para restaurar um servidor. Um "backup" incremental marca todos os arquivos como tendo sido submetidos a "backup", ou seja, o atributo de arquivamento é desmarcado ou redefinido. e) pode ser utilizado em conjunto com o "backup" diferencial. Uma restauração completa exige no máximo dois conjuntos de fitas-a fita do último "backup" diferencial e a do último "backup" incremental. Gabarito: 5.2.1. - E 5.2.2. - C 3.3.1. - D 37 Capítulo 6 O que é o “Bacula”? “Bacula” é um conjunto de programas que permite administrar "backup", restauração e verificação dos dados de computadores em uma rede de sistemas variados. Resumindo: o “Bacula” é um Programa de "backup" em rede. 6.1. Como ele funciona? O “Bacula” é formado pelos seguintes componentes (módulos), que podem trabalhar de maneira independente em máquinas variadas, inclusive com sistemas operacionais diferentes: 6.1.1. “Director Daemon”: Este serviço é responsável pela administração de todos os processos de “backup”, “restore”, verificação e arquivamento. O Administrador de Sistema usa o “Director Daemon” para efetuar agendamentos de “backup” e recuperar arquivos. 38 6.1.2. “Console Manager”: Este programa ajuda o administrador ou o usuário a se comunicar com o “Director Daemon”, pode ser executado em qualquer computador da rede e em sistemas operacionais diferentes, atualmente existem 3 versões do Console Manager: em texto puro (TTy), em interface gráfica usando bibliotecas do “Gnome” e uma usando bibliotecas “wxWidgets” (tanto em formato “Unix” quanto em “Windows”). 6.1.3. “File Daemon”: Este serviço (ou programa cliente) é o software que é instalado na máquina que vai ser protegida pelo “backup”, ou seja, ele vai ser responsável por enviar os arquivos solicitados pelo “DirectorDaemon” pela rede. Ele também é responsável em administrar a gravação dos arquivos de restauração comandados pelo “Director Daemon”. Existem versões do “File Daemon” para diferentes sistemas operacionais: Linux, *BSD, Unix, Windows (9x,NT,2000,XP,2003)e “Macintosh” (OSX). 6.1.4. “Storage Daemon”: Este serviço consiste em administrar a gravação e restauração dos dados e atributos dos "backups" fisicamente em mídias apropriadas, essas podem ser volume de dados gravados diretamente no disco rígido ou alguma mídia removível (Fita DAT, DVD, CD, etc…) 6.1.5. “Catalog”: O serviço de catalogo é o programa responsável por manter uma indexação de todos os arquivos que são armazenados no "backup" e gerar uma base de dados dos volumes gerenciados pelo “Director Daemon”. O “Catalog” agiliza a busca de um arquivo no "backup" na hora que o administrador de sistema necessita efetuar uma restauração, como ele mantém uma base de indexação dos arquivos gravados, a busca por um arquivo no meio dos volumes é mais rápida. 39 Figura 1. Módulos do “Bacula”. 40 Figura 2. Como Interagem os módulos do “Bacula”. 6.2. Principais Características do “Bacula”: − Estrutura cliente/servidor − Estrutura modular independente ("director, client, database", console de administração). − GPL - economia de custos com licenças, conhecimento e possibilidade de customização da ferramenta. − Inúmeros canais de suportes pela comunidade (“mailing lists, forums, IRC channel”, etc.) − Farta documentação disponível na Internet. − Portabilidade (módulos para diferentes sistemas operacionais – Windows, Linux, MAC, etc. - são compatíveis. − Infinidade de recursos para a customização de “backups”. 41 − Funcionalidade que permite a execução de “scripts” (ou executáveis) antes/depois do início de “jobs” ("backup"/restore), tanto no cliente quanto servidor “Bacula”. − Operação via linha de comando ou GUI (inclusive, com diferentes interfaces web desenvolvidas pela comunidades. Destaques: webacula e o bacula-web – ferramentas de visibilidade gerencial, com gráficos, etc., sendo que a primeira ainda possibilita operações de "backup", restore...). − Suporte a maioria dos dispositivos de storage do mercado (inclusive mídias ópticas). − Funcionalidade para o envio de mensagens de "log" dos trabalhos de "backup"/restore ou ainda instruções para o operador de "backup" (diferentes perfis). − 100% compatível com o esquema GFS. − Única ferramenta de "backup" multi-banco-de-dados. − Possui baixos requisitos de “hardware”. − Pelo fato de ser livre, permite o desenvolvimento de uma série de "addons", por terceiros inclusive, potencializando os recursos da ferramenta. Inclusive, já existe “plugin” para o “Nagios” (monitoração). O “Bacula” pode, perfeitamente, substituir as ferramentas proprietárias mais comuns (como, por exemplo, o “ArcServe” da “Computer Associates” e o “TCM”, da IBM). 42 6.3. O que há de novo na versão 5.0? Recentemente foi lançada a versão 5.0 do “Bacula”, que acrescentará novas funcionalidades de estabilidade aprimorada. Muitos projetos foram completados e mais de 21 pessoas contribuíram com “patches”, além de muitas outras com o relato de “bugs”. Obrigado a todos. “657 arquivos foram modificados, 104036 inserções(+), 78504 deleções(-)” As novas funcionalidades mais importantes são: * Projeto 5: Opção de truncar o volume após o “purge” (para diminuir o uso de disco de volumes em HD). * Projeto 6: Controle de arquivos duplicados – economizando espaço no armazenamento (File Deduplication using Base Jobs). * Projeto 10: Restaurar de Múltiplos dispositivos de Storage (Restore from Multiple Storage Daemons). * Projeto 11: Permitir definção de compressão por dispositivo (AllowCompression per Device). * Projeto 23: Adicionar a opção “Maximum Concurent Jobs” para dispositivos, permitindo balanceamento de carga entre dispositivos (Add Maximum Concurent Jobs for Devices to balance load between drives). * Nova opção “accurate” no “FileSet”, que pode ser utilizada para verificação de “checksum”, como exemplo (Add Accurate Fileset Options to configure accurate detection. Can use checksum verification for example.). * Permite que o FD tenha permissão de leitura dos arquivos mas abandone a permissão de gravação (CAP). * Adicionar “Tab-completion” para o “Baconsole”. * Manipulação segura de senhas para o banco-de-dados. 43 * Adicionou a API Bvfs, para fazer consultas ao catálogo sem precisar construir uma árvore na memória (memory tree). * Adicionado teste de velocidade ao programa “btape” * Adicionadas novas telas para o “Bat” (Autochanger content, Job view, Media view, …) * Versão Windows do “Bat” * Tradução Espanhola e Ucraniana do “Bacula” * Permite que os “backups” Migrate, Copy, e Virtual Full leiam e escrevam na mesma pool. * Novo comando: show disabled — mostra arquivos desabilitados. * Melhorias na ACL * Adicionado nível no status do FD * Permite habilitar/desabilitar checagem de blocos de checksum por dispositivo. Mais detalhes: http://www.bacula.org/5.0.x- manuals/en/main/main/New_Features_in_5_0_0.html Por que mudar diretamente da versão 3.0 para a 5.0? (Cadê a 4.0?) “Você deve estar imaginando porque essa versão pula da 3.0.X para a 5.00, omitindo a versão 4.0.0. Nós fizemos isso por várias razões: primeiro, nós queríamos uma maneira de distinguir o sistema de numeração da versão Bacula System Enterprise da 44 versão do projeto Bacula. Para isso, decidimos que o primeiro número da versão do projeto Bacula será sempre ímpar, e o da versão Enterprise será sempre par. Consequentemente, o projeto Bacula está indo da versão 3.0.X diretamente para a versão 5.0.X. Além disso, nós queremos manter a numeração da versão do projeto Bacula superior a versão da Enterprise para indicar que o projeto Bacula é mais avançado ou tem mais features que o Enterprise. Só para lembrar, a versão Enterprise corrente é a 2.6.1 e a próxima versão (a ser lançado em alguns meses, antes de junho de 2010) será a versão 4.0.0.” - Kern Sibad, um dos fundadores do projeto “Bacula” Atualizando para a versão 5.0 1. O “Director” e “Storage” devem ser atualizados ao mesmo tempo (os clientes podem ser atualizados mais tarde – mas não se deve demorar muito para evitar problemas). 2. O banco-de-dados deve ser atualizado através de um script que acompanha a versão 5 (não esqueça de fazer um “dump” do seu catálogo velho antes de rodar o “script”) 3. Não é possível migrar das versões 2.x diretamente para a 5. necessário atualizar o catálogo primeiro para a versão 3. 45 Capítulo 7 O “Bacula” e as Ferramentas Similares Uma grande vantagem do “Bacula” consiste no fato de que, por possuir variante da licença GPL, é distribuído gratuitamente pela Internet. Além da economicidade gerada, a distribuição gratuita não impede que o administrador implemente o “backup” em um servidor, simplesmente porque ainda não tem comprada a licença do “software”. Para uma área tão crítica e dinâmica como é a das cópias de segurança, esta é uma característica chave. Isto posto, vamos fazer um rápido comparativo com as ferramentas concorrentes mais comuns. Para um comparativo mas amplo e detalhado veja o anexo II desta obra. 46 7.1. Amanda (livre): “O Amanda, acrônimo para Advanced Maryland Automatic Network Disk Archiver, é um sistema de "backup" que permite a configuracao de um servidor mestre para realizacao de "backups" de múltiplos clientes numarede, com a possibilidade de armazenamento em fita, disco ou dispositivo otico (CD ou DVD) [Amanda 2006]. Ele usa o dump nativo do UNIX e/ou a ferramenta GNU tar e pode realizar "backups" de uma grande quantidade de máquinas rodando diferentes sistemas UNIX. Ele também usa Samba ou Cygwin para o "backups" de sistemas Microsoft Windows. Esta foi por muito tempo a mais popular ferramenta livre para realizacao e gerencimento de "backups", e ainda hoje e bastante usada. Numa busca por ferramentas de "backup" no SourceForge [SourceForge 2006], o Amanda aparece em segundo lugar, com cerca de 180.000 downloads.” (Tássia Camões - ANALISE COMPARATIVA ENTRE O BRF E MÉTODOS TRADICIONAIS PARA O GERENCIAMENTO DE BACKUPS). O Amanda foi superado pela seleção natural que rege a popularidade dos “software” livres de espécies semelhantes. As principais desvantagens relatadas dizem respeito à falta de um cliente nativo para Windows, operação não muito intuitiva e dificuldade para a implementação de um esquema customizado de rotação de fitas (ex.: GFS) . Desde 2006, a comunidade do “Bacula” já possuía mais que o dobro de downloads que o Amanda. 47 7.2. “Arcserve” (proprietária) O “Arcserve” é uma ferramenta muito interessante de “backup”, na medida que suporta diversos sistemas operacionais (como o Bacula). Entretanto, a licença para um sistema só serve para aquele em específico, causando um incômodo aprisionamento tecnológico. De igual sorte, a console de administração do “Arcserve” requer uma máquina possante e uma boa largura de banda na rede, para que o desempenho operacional seja satisfatório. O licenciamento do “Arcserve”, além de demasiadamente “caro”, é dividido por funcionalidades – ou seja: cada vez que você necessitar de um novo recurso (exemplo: "backup" de arquivos abertos), será necessário adquirir novo módulo. No final das contas, o TCO se torna demasiadamente alto. 7.3. TSM (proprietária) As características técnicas do TSM podem ser encontradas no próprio site do fabricante (abaixo - [1]). Trata-se de uma ferramenta com bastante recursos e, em certo ponto, similar ao “Bacula”. A maior desvantagem fica, aqui, na falta de documentação aberta e, resultando em maior necessidade de treinamento e dificuldade em solução de problemas / “bugs”. De igual sorte, possui todas as demais desvantagens em se adotar uma ferramenta proprietária... Costuma ser “fornecido gratuitamente” para quem adquire um “storage” da IBM – o que consiste em uma venda casada (armadilha). No momento que o usuário começa a utilizar o TSM, cria um legado de “backups” difícil de ser migrado posteriormente – ou seja – a renovação da licença e do suporte, após o primeiro ano e para todos os demais, passa a ser praticamente obrigatória (aprisionamento 48 tecnológico). 49 Capítulo 8 Instalando o “Bacula” Existem várias maneiras de instalar o “Bacula” e, portanto, não há “receita” pronta. Entretanto, podemos estabelecer alguns procedimentos que irão facilitar as escolhas do administrador. 8.1. Instalando o Banco de Dados: Antes de tudo, é necessário escolher (e instalar) um dos bancos de dados suportados pelo “Bacula”.Na versão 5.xx, estas são as opções: MySQL PostgreSQL SqLite Cada um destes, possui características e limitações distintas, que muito provavelmente não serão perceptíveis ao usuário do “Bacula”, na medida que o seu banco é relativamente pequeno (se configurado adequadamente), mesmo que se 50 tenha uma grande quantidade de clientes instalados. Os procedimentos de instalação também variam de acordo com a escolha, sendo que o PostgreSQL requer um passo adicional de configuração que será explicado. Existem diversos manuais na Internet, inclusive em Português, com todos procedimentos detalhados. De qualquer sorte, o caminho mais rápido para instalar o banco de dados, consiste na utilização de um gerenciador de pacotes (apt, yum, yast, etc.). No exemplo, vamos verificar uma instalação através do “apt-get”: MySql: # apt-get install mysql-server Ele irá te perguntar o nome e a senha do usuário administrador do banco. Para fins de aprendizado (iniciantes), vamos manter o usuário “root” (default), e a senha em branco. * Caso estabeleça uma senha, é necessário passá-la como parâmetro mais a frente, nos “scripts” que criam o banco, tabela e o usuário “Bacula” (ficam dentro de /etc/bacula). A sintaxe é: [“script” nome_de_usuário senha] 51 Postgresql: # apt-get install postgresql Depois de instalado, provavelmente seu serviço de banco de dados já estará rodando. Sqlite: # apt-get install sqlite 8.2. Instalando o “Bacula” (Linux): Por pacotes: No meu sistema, estes são os pacotes disponibilizados pelo gerenciador de pacotes (apt): debian:~# apt-cache search bacula bacula-director-common - verificação, recuperação e "backup" via rede - arquivos comuns do Director bacula-server - verificação, recuperação e "backup" via rede - meta pacote de servidor bacula-console - verificação, recuperação e "backup" de rede - console de texto bacula-sd-pgsql - verificação, recuperação e "backup" via rede - ferramentas PostgreSQL SD bacula-traymonitor - verificação, recuperação e "backup" de rede - monitor de bandeja 52 bacula-director-mysql - verificação, recuperação e "backup" via rede - armazenamento MySQL p/ o Director bacula-sd-mysql - verificação, recuperação e "backup" via rede - ferramentas MySQL SD bacula-director-pgsql - verificação, recuperação e "backup" via rede - armazenamento PostgreSQL p/ o Director bacula-sd-sqlite3 - verificação, recuperação e "backup" via rede - ferramentas SQLite 3 SD bacula-console-wx - verificação, recuperação e "backup" de rede - console WxWindows bacula-director-sqlite3 - verificação, recuperação e "backup" via rede - armazenamento SQLite 3 p/ o Director bacula - verificação, recuperação e "backup" via rede - meta pacote bacula-sd - verificação, recuperação e "backup" de rede - daemon de armazenamento bacula-doc - documentação para o Bacula bacula-director-sqlite - verificação, recuperação e "backup" via rede - armazenamento SQLite p/ o Director bacula-console-qt - Ferramenta de Administração Bacula bacula-sd-sqlite - verificação, recuperação e "backup" via rede - ferramentas SQLite SD bacula-common - verificação, recuperação e "backup" via rede - arquivos de suporte comum bacula-fd - verificação, recuperação e "backup" de rede - daemon de arquivo bacula-client - verificação, recuperação e "backup" via rede - meta pacote cliente De igual sorte, na Internet e/ou no site “bacula.org”, existem vários pacotes compilados para diferentes distribuições Linux. Mas observe que, neste caso, os pacotes já estão traduzidos para o idioma brasileiro. Então, necessário saber quais pacotes devem ser instalados, de acordo com a 53 finalidade. Da lista de pacotes, destaque para o bacula-console-qt, que é uma interface gráfica bastante funcional para administração do “Bacula”. Entretanto ela não serve para modificar as configurações do sistema. Servidor de "backup": Se apenas selecionar o pacote “Bacula” (apt-get install bacula), o sistema automaticamente escolheu uma série de pacotes que possibilitariam a montagem de um servidor de "backup". Entretanto, também escolheu o banco de dados que será utilizado: Os pacotes extra a seguir serão instalados: bacula-client bacula-common bacula-console bacula-director- common bacula-director-sqlite3 bacula-fd bacula-sd bacula-sd-mysql bacula-server bacula- traymonitor mt-st mtx sqlite3 Pacotes sugeridos:bacula-doc dds2tar scsitools sg3-utils sqlite3-doc Pacotes recomendados: bacula-sd-tools Os NOVOS pacotes a seguir serão instalados: bacula bacula-client bacula-common bacula-console bacula- director-common bacula-director-sqlite3 bacula-fd bacula-sd bacula-sd-mysql bacula-server bacula- traymonitor mt-st mtx sqlite3 0 pacotes atualizados, 14 pacotes novos instalados, 0 a serem removidos e 71 não atualizados. É preciso baixar 3215kB de arquivos. Depois desta operação, 7041kB adicionais de espaço em disco serão usados. Você quer continuar [S/n]? 54 Portanto, está opção não serviria se desejássemos utilizar outro banco, que não o Sqlite. Observe que, o pacote mtx e o mailx são dependências importantes para manipulação de fitas magnéticas e mensageria. Assim, para instalar um servidor Bacula com o Mysql (exemplo), basta substituir os pacotes que contenham a expressão Sqlite, por Mysql. O mesmo para o Postgresql. No mínimo, para montar um servidor, estes seriam os pacotes: 1.bacula-fd (para fazer "backup" do próprio servidor de "backup") 2.bacula-common (arquivos comuns do “Bacula”) 3.bacula-console (caso deseje administrar o “Bacula” através do próprio servidor) 4.bacula-director-[nome_do_banco] (o “director” é o servidor “Bacula” propriamente dito) 5.bacula-sd-[nome_do_banco] (“storage daemon” - ou seja, manipula os dispositivos de armazenamento. O [nome_do_banco] pode ser opcional). 6.Bacula-traymonitor (apenas se o servidor possuir interface gráfica, e você desejar usá-la para administrar o “Bacula”) 7.bacula-doc (documentação do “Bacula”). A versão atual do repositório é a 2.4.4. A última antes da 3.*. Nas versões 3, existe mais uma dependência: o pacote libssl Durante a instalação, o “apt” perguntará se você configurou alguma senha no seu banco de dados (em caso afirmativo, deve informá-la). Ainda, perguntará se deseja configurar automaticamente o banco – (sim!). 55 Pós-instalação: Depois de instalado, você pode iniciar os “daemons” do “Bacula”, sempre na seguinte ordem: /etc/init.d/bacula-fd /etc/init.d/bacula-sd /etc/init.d/bacula-director Qualquer erro de sintaxe das configurações (que ficam em /etc/bacula), serão imediatamente demonstrados. Se der tudo certo, basta digitar “bconsole” para ter acesso ao “director” - seu sistema está funcionando. Entretanto, caso o “director” não retorne nenhum erro mas tenha sua execução terminada, muito provavelmente se trata de um problema de comunicação com o banco de dados. Caso isso aconteça, execute os três “scripts” a seguir: /etc/bacula/create_bacula_database (cria o banco de dados Bacula – no caso do mysql, há um “script” específico) /etc/bacula/make_bacula_tables (cria as tabelas do banco) /etc/bacula/grant_bacula_privileges (cria o usuário bacula e garante os privilégios no banco de mesmo nome) Atenção! Para todos os mencionados scripts, é possível passar o usuário do banco de dados e a senha. Ex.: create_bacula_database -u root -p123456 Entre o -p, e a senha (neste caso 123456), não há espaço. 56 Persistindo o erro, verifique como estão configurados o usuário e a senha do banco (/etc/bacula/bacula-dir.conf) Se ainda assim o “daemon” do “bacula-director” apresentar problemas, consulte a “log” do “Bacula” para maiores detalhes sobre o erro. Geralmente, a instalação por compilação apresenta melhores resultados quanto à ocorrência destes incidentes. Cliente de "backup": Obviamente, se a máquina for apenas um “cliente de "backup" Bacula”, não será necessário instalar um banco de dados para o catálogo. A instalação do cliente pode ser feita através do pacote de nome: bacula- client ou em algumas “distros”, bacula-fd. Instalando por compilação: Compilando o Servidor de "backup" (inclui o cliente e o storage daemons): 1. Acesse o endereço: www.bacula.com.br 2. Depois de acessar o “link” Download, clique em “Bacula”; 3. Baixe o código fonte (arquivo .tgz) 4. Descompacte o .tar.gz e vá para a pasta criada. Antes de compilar, não esqueça de instalar os compiladores e demais pacotes necessários. No caso do Debian / Ubuntu: apt-get install build-essential 5. Se estiver instalando a versão 3 ou superior do “Bacula”, instale o pacote: libssl-dev 57 6. Execute ./configure, com as possíveis opções: CFLAGS=”-g -O2 ″ ./configure –-sbindir=$HOME/bacula/bin –-sysconfdir=$HOME/bacula/bin –-with-pid-dir=$HOME/bacula/bin/working –-with-subsys-dir=$HOME/bacula/bin/working –-enable-smartalloc –-with-mysql –-with-working-dir=$HOME/bacula/bin/working –-with-dump-email=your@address.com –-with-job-email=your@address.com –-with-smtp-host=localhost 7. Caso escolha o mysql, há uma dependência específica: libmysql++- dev (no postgres, libpq-dev). 8. Provavelmente, você vai querer executar sem opções: ./configure (a apenas optando pelo banco Mysql -–with-mysql ou Postgresql --with-postgresql). 9. Depois, execute o comando: make Obs.: o autostart faz com que o “Bacula” seja inicializado junto com o sistema operacional. 10. make install 11. cd $HOME/bacula/bin 12. ./bacula start 13./etc/bacula/create_bacula_database (cria o banco de dados Bacula – no caso do mysql, há um “script” específico) /etc/bacula/create_bacula_tables (cria as tabelas do banco) 58 /etc/bacula/grant_bacula_privileges (cria o usuário bacula e garante os privilégios no banco de mesmo nome) Atenção! Para todos os mencionados scripts, é possível passar o usuário do banco de dados e a senha. Ex.: create_bacula_database -u root -p123456 Entre o -p, e a senha (neste caso 123456), não há espaço. 14. Configure os daemons do “Bacula” [próximo capítulo] 15. No caso de ter escolhido o Banco Postgresql, descomente o a linha que habilita o uso “dbi” driver, no arquivo: /etc/bacula/bacula-dir.conf (recurso Catalog {…}) e especifique o endereço e porta do Banco PostgresQL (default”: “5432) Compilando apenas o Cliente “Bacula”: 1.Descompacte o arquivo .tar.gz e, no diretório criado, digite: ./configure –-enable-client-only make make install autostart 2.Configure o bacula-fd [próximo capítulo] Compilando apenas um dos “daemons” do “Bacula”: As opções de compilação, para seleção dos daemons a serem instalados, são as seguintes: ./configure -–enable-client-only (apenas compila o File Daemon) -–enable-build-dird (também compilará o Director) -–enable-build-stored (também compilará o Storage Daemon) 59 Capítulo 9 Configurando o “Bacula” 9.1. Passo-a-passo: Configurando o “Bacula” pela Primeira Vez O arquivo criado automaticamente na instalação do “Bacula” vai funcionar* apenas como um ambiente de testes. Indispensável fazer certas modificações para que seja um sistema de útil. *Um dos erros mais comuns que podem acontecer na instalação do “Bacula” consiste na falha de autenticação como banco-de-dados (isso pode ser verificado através da log do “Bacula”). quando isso acontece, não é possível se conectar ao director (bacula-dir) – e o daemon deixa de estar em execução. Para corrigí-lo, tenha certeza de que rodou o script “/etc/bacula/grant_bacula_privileges” e que o login e senha de acesso ao Catálogo estão corretas (dento do recurtos Catalog em “/etc/bacula/bacula-dir.conf). 60 Com o “Bacula” funcionando (ou seja – acessível através do bconsole), estas são as alterações básicas de customização: 1. Alterar o nome do “Director” e do “Monitor”, para um nome personalizado. O instalador do “Bacula” utiliza para o nome do director o host da máquina. Se deseja modificar este nome, o melhor momento de fazê-lo é agora (quando você ainda está no início e não tem outros
Compartilhar