1. Introdução:

Apesar de possível, não se tem conhecimento de um cliente do Bacula que tenha sido compilado para o Netware 6.5.

Dessa maneira, para se ter acesso aos dados do servidor Netware, necessária a exportação dos volumes (neste caso para uma máquina Linux). Veja o diagrama:

2. Configuração:

Como vimos no diagrama, importante configurar o Netware para fazer o backup periódico de seus trustees para possibilitar a eventual restauração das permissões e outros atributos importantes dos arquivos.

2.1 Backup dos Trustees:

O software nativo do Netware, trustbar.nlm, pode ser utilizado para tal finalidade. A sua sintaxe é [1]:

trustbar [diretório_destino][arquivo_xml_saída] [-opções]

As opções suportadas são:

Por exemplo, se /mnt/netware1 corresponde a um volume exportado para o Linux e vol1: é o respectivo volume “NFS Gateway”  montado no Netware, então:

a) Faça o backup de Backup  de /mnt/netware1.

b) Crie um script no Netware que deverá conter o seguinte (exemplo):

trustbar vol1: sys:\etc\vol1\trustees.xml -B

Neste momento os trustees dos arquivos / diretórios no vol1: serão backupeados no arquivo sys:\etc\vol1\trustees.xml

2.2 Exportação dos Volumes:

Existem vários métodos para exportação de volumes via NFS pelo Netware, bem documentados pelo fabricante e disponíveis pela internet:

http://www.novell.com/documentation/nfsgynw65/esd/qrpnfsgynw65.html

http://www.novell.com/communities/node/3234/nfs-mount-netware-65-volume-sles-server-or-sled-client

http://www.techrepublic.com/article/add-nfs-support-to-your-netware-6-server/5031644

Segue um procedimento exemplo [2]:

2.2.1. Configure o Netware para exportar os volumes:

Edite o arquivo SYS:ETC/EXPORTS e adicione o seguinte:

/nome_do_volume/ -nwmode -rw -root

Exemplo: /VOL1/ -nwmode -rw -root

Edite o arquivo NFSSTART.NCF e modifique a linha…

load xnfs

para

load xnfs -nodnscheck.

Reinicie o serviço NFS.

Na consolde de administração submeta o comando:

nfsstop.ncf

E então, novamente:

nfsstart.ncf

2.2.2. No servidor Linux:

Crie um diretório no qual o volume do Netware Será montado:

Exemplo: mkdir /mnt/netware1/

Monte o volume do Netware em seu servidor Linux:

Exemplo:  mount -t nfs 151.155.194.44:/VOL1/ /mnt/netware1/

*Talvez seja aconselhado inserir uma entrada no arquivo fstab do Linux, para que sempre os volumes Netware sejam montados após uma reinicialização eventual do equipamento.

3. Restauração dos Dados:

Utilize o Bacula para restaurar os arquivos para dentro dos volumes exportados do Netware.

Restaure os trustees através do arquivo XML criado pela aplicação trustbar.nlm.

Baseado no exemplo acima, um exemplo de restauração do “vol1″ seria dado na linha de comando por:

trustbar sys:\etc\vol1\trustees.xml -R

[1] http://www.novell.com/documentation/nfsgynw65/

[2] http://www.novell.com/communities/node/3234/nfs-mount-netware-65-volume-sles-server-or-sled-client

Cada empresa devera verificar sua necessidade específica principalmente em atenção ao seu negócio, ANS, AOS e valor dos dados armazenados.

========================================================================================================

Política de Backup e Restauração de Arquivos

Versão x.x

1. Introdução

O presente documento estabelece uma política de cópias de segurança (backup) e restauração de arquivos digitais armazenados no parque tecnológico desta empresa.

Os donos dos dados deverão ter ciência dos tempos de retenção aqui estabelecidos para cada tipo de informação e os administradores / operadores de backup deverão zelar pelo cumprimento das diretrizes aqui estabelecidas.

2. Considerações iniciais

O serviço de backup deve ser orientado para a restauração das informações no menor tempo possível, principalmente havendo indisponibilidade de serviços que dependam da operação de restore.

Este documento deverá ter conhecimento e anuência da Diretoria.

3. Orientações Gerais:

1. Cabem aos administradores prever a realização de testes periódicos de restauração, no intuito de averiguar os processos de backup e estabelecer melhorias.
2. A administração dos backups também deve ser orientada para que seus trabalhos respeitem as janelas para execução, inclusive realizando previsão para a ampliação da capacidade dos dispositivos envolvidos no armazenamento.
3. As mídias (ou dispositivos de armazenamento) deverão ser armazenados em cofre corta-fogo, ou em localidade diversa da origem dos dados (backup off-site).
4. As mídias defeituosas ou inservíveis serão encaminhadas para picotamento, incineração, procedimentos de sobrescrita de dados remanescentes (disco rígido) ou outro procedimento que impossibilite a recuperação dos dados por terceiros.
5. As solicitações de restauração de arquivos deverão ser abertas formalmente através de ferramentas de abertura de chamados e / ou formulário que deverá conter os nomes dos arquivos e pastas que deverão ser recuperados e, principalmente, a data do aquivo que se pretende ter acesso.

4. Estratégia Geral Backup:

De acordo com a natureza dos dados trazemos a seguinte classificação:

• Arquivos dos Sistemas Operacionais;
• Servidores de Arquivos;
• Bancos de Dados;
• Máquinas Virtuais (imagem);
• Servidores de E-mail;

Por padrão será adotada o seguinte esquema de realização de backups, baseado no esquema GFS (exceto se especificada necessidade especial no item 5):

• Backups diferenciais (denominados diários) de segunda à quinta-feira, realizados a partir das 20:00h., com uma semana de retenção;
• Backups completos (full – denominados semanais) nas segundas, terças e quartas sexta-feiras do mês, realizados a partir das 20:00h., com um mês de retenção;
• Backups completos (full – denominados mensais) na primeira sexta-feira do mês, realizados a partir das 20:00h., com um ano de retenção;

5. Necessidades especiais de backup (exceções):

5.1 Máquinas Virtuais (imagem);

O backup das máquinas virtuais como imagem (adequado para fins de disaster recovery – ou seja: restauração da máquina como um todo), será feito apenas na seguinte periodicidade:

• Backups completos (full – denominados mensais) na primeira sexta-feira do mês, realizados a partir das 20:00h., com um ano de retenção;

No mais, as Máquinas Virtuais serão tratadas como outras máquinas físicas, devendo o cliente de backup ser instalado em cada uma delas.

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

1. Discos independentes (em paralelo):

Se eles forem montados separadamente você terá a limitação de ter, no mínimo, uma Pool de volumes por disco (na medida que volumes de uma Pool precisam pertencer sempre a um mesmo storage). Além disso cada disco usado para backup representará no mínimo um storage para o Bacula. Isso pode tornar complexa a configuração / administração dos backups.

2. LVM:

Se os discos estiverem conectados diretamente no mesmo sistema operacional (que hospeda o storage daemon), pode ser utilizada uma solução nativa para a mesclagem dos discos (ex.: LVM). Essa solução, quando possível, se mostra bastante atraente. Permite por exemplo ampliar a capacidade desse “storage virtual” criado através do acréscimo de novos discos. Veja o diagrama:

Os procedimentos para criação de um grupo LVM no Linux são abundantes na Internet. Na. configuração do bacula-sd basta especificar o ponto de montagem do seu LVG – onde o backup será gravado.

O Webmin é uma poderosa interface web desenvolvida em Perl para administração de servidores e conta com suporte nativo ao Bacula.

Uma vantagem interessante é a possibilidade de editar as configurações dos componentes do Bacula graficamente. Provavelmente foi a primeira ferramenta a trazer essa funcionalidade de maneira tão completa.

1. Instalação do Webmin

Através do nosso guia rápido, nossa implementação deve ficar assim:

Optei por utilizar o sistema operacional Debian 6 para este manual e, dessa maneira, satisfiz as seguintes dependências:

apt-get install libnet-ssleay-perl libauthen-pam-perl libio-pty-perl apt-show-versions libpg-perl

Após umas mensagens de aviso o apt recomendou que fosse executado o seguinte comando:

apt-get -f install

Dependências instaladas. Neste momento fui ao site do Webmin para fazer o download do pacote mais atual para Debian (www.webmin.com/download.html):

Debian package suitable for Debian, Ubuntu or other derived Linux
http://prdownloads.sourceforge.net/webadmin/webmin_1.580_all.deb 14.8 MB

Na linha de comando utilizei o comando wget + o endereço para o pacote, assim:

wget http://downloads.sourceforge.net/project/webadmin/webmin/1.580/webmin_1.580_all.deb

dpkg -i webmin_1.580_all.deb

https://localhost:10000

Clicando no link constante da mensagem “Module Configuration” fui direcionado para uma tela onde se deve configurar o acesso do Webmin ao Catálogo do Bacula (tipo, senha e usuário do banco etc.):

Pronto. O Módulo do Webmin para o Bacula deve estar funcional.

Retornando ao menu lateral System > Bacula Backup System, agora visualizo opções para, inclusive, alterar as configurações do Bacula:

Como exemplo, escolhi a tela para adicionar um cliente ao Director:

Show de Bacula, hein?

Na tela principal do módulo também é possível realizar as atividades cotidianas de operação do Bacula, tais como: submeter e restaurar jobs, gerenciar volumes e verificar status dos componentes. Ver exemplo:

Para o backup de centenas de milhares de arquivos a performance de escrita no banco de dados (catálogo) do Bacula pode tornar-se um gargalo.

Dessa maneira vamos abordar alguns pontos de melhoria no sentido que a capacidade de transações seja ampliada:

1. Múltiplos Bancos de Dados configurados num mesmo Director

Apesar de servir ao propósito este método traz algumas desvantagens, tais como:

a) Maior dificuldade na administração de bases distintas;

b) Limitação no uso dos storages, na medida que o acesso a determinado volume, pelo banco, precisa ser exclusivo (e consequentemente, as pools também terão de pertencer a apenas um BD). Veja o exemplo diagramado abaixo:

1.1. Configuração de Múltiplos Catálogos no Mysql*:

*Escolhi o MySql porque não possui até o momento (versão 5.x) funcionalidade de balanceamento de carga nativa, mas os procedimentos a seguir podem ser utlizados no Postgesql com as devidas adaptações.

Para criação de um segundo catálogo, após uma instalação fresca do Bacula, realizei um dump do banco de dados:

mysqldump -u root -p[senha_root_mysql] bacula > /etc/bacula/bacula1.sql

Em seguida, criei um novo banco de nome distinto – bacula1, isso através da console do Mysql.

mysql -u root -p[senha_root_mysql]

(agora você deve estar na console do Mysql. mysql>)

create database bacula1;

Na mesma console realizei a restauração do dump:

use bacula1

\. bacula1.sql

Garanti os direitos para o usuário do MySql Bacula, para o segundo banco (o bacula1):

grant all privileges on bacula1.* to bacula@localhost;

Com os dois bancos criados, editei o arquivo /etc/bacula/bacula-dir.conf para configurar o acesso do Bacula ao segundo banco. Minhas entradas ficaram assim:

Catalog {

Name = Catalogo1

dbname = bacula; DB Address = “”; dbuser = “bacula”; dbpassword = “123456″

}

Catalog {

Name = Catalogo2

dbname = bacula1; DB Address = “”; dbuser = “bacula”; dbpassword = “123456″

}

Depois de reiniciado o Bacula Director o mesmo irá te perguntar que base deve utilizar quando, por exemplo, for submeter um job manualmente.

Em relação ao agendamento de jobs necessário especificar em cada um dos clientes quais dos Catálogos ele deve utilizar. Neste momento você pode fazer um balanceamento de carga manual, dividindo os clientes que possuem maior quantidade de arquivos em Catálogos separados. Exemplo:

Client {

Name = debian-fd

Address = localhost

FDPort = 9102

Catalog = Catalogo1

…

}

Por último, basta apenas certificar-se de agendar os jobs no recurso Scheudle, de maneira jobs de catálogos diferentes utilizem pools distintas. Fiz isso implementando dois agendamentos:

Schedule {

Name = “Clientes Catatalogo1″

Run = Full   Storage = BackupDisco1  Pool = SemanalDisco  1st sun at 23:05

…

}

Schedule {

Name = “Clientes Catatalogo2″

Run = Full   Storage = BackupFita1  Pool = SemanalFita  1st sun at 23:05

…

}

2. Configuração de Load Balancer no Catálogo do Bacula (Postgresql)

Esta talvez seja a solução mais elegante para ampliar a capacidade do banco de dados utilizado pelo Bacula.

Além disso pode ser implementado com características de alta disponibilidade, dirimindo assim os impactos com um possível crash de Banco.

O balanceamento de carga com o Postgresql pode ser implementado através da ferramenta Pgpool-2, que dispõe de farta documentação na Internet.