Usando robôs com múltiplos drives gravando simultaneamente [Using autochangers with multiple drives writing at the same time]
18 de Janeiro de 2010, 0:00 - sem comentários aindaDepois de tudo, não foi necessário criar duas pools. Consegui utilizar dois drives simultâneamente (numa mesma pool) – com isso os backups estão mais rápidos. Configurei a próxima “flag” como “*no*”, no recurso JobDefs (bacula-dir.conf):
Prefer Mounted Volumes = <yes|no>
“Se a diretiva “Prefer Mounted Volumes” (Preferir Volumes Montados) estiver em “yes” (default yes), o Storage daemon é solicitado para escolher volumes já montados nos drives de fita, em detrimento a volumes que não estejam montados. Isso significa que os “jobs” tentarão escrever no mesmo Volume (desde que o Volume seja correto, ou seja, pertença à “pool” correta, para aquele “job”). Se nenhum Volume adequado estiver disponível, ele escolherá o primeiro drive. Observe que any Volume que for montado será considerado valido para os outros “jobs”. Se múltiplos Jobs começam ao mesmo tempo, todos eles irão preferir múltiplos volumes. Se a diretiva escolhida é *no*, o “Storage daemon” vai preferir um drive não utilizado. Escolher “no” para “Prefer Mounted Volumes” pode ser útil no uso de autochangers com múltiplos drives e que preferem maximizar a taxa de transferência para backup, a custa de mais volumes e drives. Isso significa que o “job” irá escolher um drive não utilizado, em detrimento de um drive em uso.”
Fonte: bacula.org documentation.
After all, it was not necessary creating two pools. I’ve managed to use both drivers at same time (and a single pool) – backups are really faster now. I set up the following flag, as “*no*”, in the JobDefs resource (bacula-dir.conf):
*”Prefer Mounted Volumes = <yes|no>* If the Prefer Mounted Volumes directive is set to *yes* (default yes), the Storage daemon is requested to select either an Autochanger or a drive with a valid Volume already mounted in preference to a drive that is not ready. This means that all jobs will attempt to append to the same Volume (providing the Volume is appropriate — right Pool, … for that job). If no drive with a suitable Volume is available, it will select the first available drive. Note, any Volume that has been requested to be mounted, will be considered valid as a mounted volume by another job. This if multiple jobs start at the same time and they all prefer mounted volumes, the first job will request the mount, and the other jobs will use the same volume. If the directive is set to *no*, the Storage daemon will prefer finding an unused drive, otherwise, each job started will append to the same Volume (assuming the Pool is the same for all jobs). Setting Prefer Mounted Volumes to no can be useful for those sites with multiple drive autochangers that prefer to maximize backup throughput at the expense of using additional drives and Volumes. This means that the job will prefer to use an unused drive rather than use a drive that is already in use.”
Source: bacula.org documentation.
“Backup” de Máquinas Virtuais “Xen”
15 de Janeiro de 2010, 0:00 - sem comentários aindaEm relação às máquinas virtuais, continuo adepto da estratégia: instalação um cliente do “Bacula” em cada uma das máquinas virtuais – ou seja: trate elas como se fossem máquinas dedicadas (físicas).
A questão aqui, novamente, reside no “backup” dos arquivos que correspondem às máquinas virtuais em si (para fins de disaster recovery), que aparentemente não podem ser diretamente “backupeados” com a máquina virtual em execução.
Assim, pesquisamos alguns métodos utilizados:
1. Pausar a Máquina Virtual Xen para a cópia dos arquivos:
A disvantagem desse processo é óbvia: a indisponibilidade temporária da máquina virtual. Se isso não é um problema, estes seriam os procedimentos:
1. Pausar o “domU” utilizando o comando “xm pause” (script RunBeforeJob do “Bacula”)
2. Sincronize o “domU” utilizando o comando “xm sysrq” (num segundo script “RunBeforeJob”)
3. Faça o “backup” das configurações do Xen e do arquivo correspondentes à máquina virtual.
4. Despause o “domU” através do comando “xm unpause”
Este “backup completo” da máquina virtual pode ser executado numa peridiocidade menor (Ex.: semanalmente ou mensalmente).
Fonte: [http://lists.xensource.com/archives/html/xen-users/2006-10/msg00476.html]
2. Criar um Snapshot LVM:
Parece se tratar do método mais popular entre os administradores de Xen. O LVM é utilizado como uma camada intermediária entre a máquina virtual e o disco rígido, permitindo a cópia integral da VM com a mesma em produção.
Para isso, vários scripts estão na Internet (que devem ser chamados pelo “Bacula” com um RunBeforeJob). Gostei bastante desse aqui:
#!/bin/bash # Backup das VM's do Xen # Tiago Cruz - tiagocruz@everlinux.com # Mar/2008 export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
VMS=`xm list | awk '{print $1}' | egrep -v '(Name|Domain-0)'` BACK="_snap" LOG=/var/log/backup # Particao root, geralmente a segunda eh swap ROOT="1"
[ ! -d "/mnt/back" ] && mkdir -p /mnt/back [ ! -d "/dados/backup" ] && mkdir -p /dados/backup
for i in $VMS; do echo "=================================================================" >> $LOG echo "Backup $i iniciado em `date` com load de `cat /proc/loadavg`" >> $LOG DEVICE=`grep disk /etc/xen/$i | awk -F "Vol_LVM" '{print $2}' | cut -d / -f 2 | cut -d , -f 1` echo "Maquina Virtual $i usa $DEVICE como storage device" >> $LOG
lvcreate --snapshot -L 15G -n $i$BACK /dev/Vol_LVM/$DEVICE >> $LOG [ $? -ne 0 ] && echo "Erro $i: criando LVM $i$BACK" >> $LOG kpartx -a /dev/mapper/Vol_LVM-$i$BACK >> $LOG mount /dev/mapper/Vol_LVM-$i$BACK$ROOT /mnt/back/ >> $LOG [ $? -ne 0 ] && echo "Erro $i: montando $i$BACK$ROOT" >> $LOG SIZE1=`df -hP /mnt/back/ | awk '{print $3}' | grep -v Used` SIZE2=`df -hP /mnt/back/ | awk '{print $2}' | grep -v Size` echo "Backup de /dev/mapper/Vol_LVM-$i$BACK$ROOT - $SIZE1 de $SIZE2 usados" >> $LOG tar zcf /dados/backup/$i-xen.tar.gz /mnt/back >> $LOG [ $? -ne 0 ] && echo "Erro $i: criando /dados/backup/$i.tar.gz" >> $LOG SIZE3=`ls -lh /dados/backup/$i-xen.tar.gz | awk '{print $5}'` echo "Criado /dados/backup/$i-xen.tar.gz com $SIZE3" >> $LOG umount /mnt/back/ >> $LOG [ $? -ne 0 ] && echo "Erro $i: desmontando $i$BACK" >> $LOG kpartx -d /dev/mapper/Vol_LVM-$i$BACK >> $LOG [ $? -ne 0 ] && echo "Erro $i: desmapeando $i$BACK" >> $LOG echo "Removendo snapshot ja backupeado $i$BACK" >> $LOG lvremove /dev/Vol_LVM/$i$BACK -f >> $LOG done
echo "Backup finalizado em `date` com load de `cat /proc/loadavg`" >> $LOG echo "=================================================================" >> $LOG echo "=================================================================" >> $LOG
Fonte: [http://everlinux.com/blog/2008/04/03/fazendo-backup-das-suas-vms-do-xen]
Mais uma coisa: você deverá incluir a pasta [/dados/backup/] no “FileSet” do “Bacula”, para fazer a cópia dos arquivos gerados (que são os snapshots da LVM comprimidos em .tar.gz).
Outra coisa: inclua também, no “FileSet” correspondente, os arquivos de configuração do “Xen”.
Última coisa: opcionalmente, crie um “RunAfterJob” para limpar o [/dados/backup], dessa forma desocupando o espaço utilizado pelas LVM.
Fonte: [http://wiki.sepsoftware.com/wiki/index.php/Online_backup_of_virtual_XEN_machines]
Abracetas,
Heitor Faria
Fazendo o Backup de Máquinas Virtuais do Vmware
15 de Janeiro de 2010, 0:00 - 2 comentáriosDe bobeira, na Internet, encontrei a o guia oficial para backup das máquinas virtuais VMware [http://www.vmware.com/pdf/vi3_301_201_vm_backup.pdf]
O mesmo apresenta duas maneiras de proteger as máquinas virtuais, ambas suportadas pelo “Bacula”:
1. Utilizando a Solução do Fabricante – o VMWare Consolidated Backup
Este seria o procedimento nativo do VMWare – uma maneira de criar imagem das máquinas ou extrair arquivos delas, mesmo que estejam desligadas. Este método, requer a integração com uma ferramenta de “backup” – exemplo: o “Bacula”, para executar “scripts” que coloquem o Vmware Consolidated Backup para extrair os dados das máquinas e depois jogar para o armazenamento.
Particularmente não gostei dessa solução, por que:
a) Você teria uma camada a mais de “backup” para administrar e para operar manualmente, no momento do “restore”.
b) Seria mais um ponto de falha.
c) O fabricante sugere o uso opcional de um servidor proxy (que só funciona no Windows), para diminuir a carga de processamento do “backup” consolidado (altamente temerário!!!)
d) O fabricante sugere que apenas algumas soluções de “backup” seriam “suportadas” para trabalhar em conjunto com a solução, omitindo as demais, principalmente as livres. [http://www.vmware.com/support/vi3/doc/releasenotes_vcb103.html]
e) O uso da solução nativa só se justificaria se não fosse fazer “backup” das máquinas virtuais inteiras com uma margem de segurança, para a recuperação de desastres. No entanto ele mesmo admite que é possível, ainda mais com o “Bacula” que faz “backup” de arquivos abertos:
“Run backup clients from the ESX Server Service Console, backing up virtual machines in their entirety as .dsk and .vmdk files residing in the ESX Server host VMFS file system.” (p. 17)
Ele diz aqui, que você pode fazer “backup” dos arquivos .dsk e .vmdk (máquinas virtuais) diretamente do servidor hospedeiro das mesmas.
2. Métodos Tradicionais [recomendado]
O método tradicional de “backup” consistira a instalação dos “clientes” do “Bacula” (por exemplo) em cada uma das máquinas virtuais – ou seja: seriam tratadas como se máquinas dedicadas fossem.
O grande mérito, na minha opinião, seria a manutenção de um banco-de-dados único de controle, administração, ponto de falha e operação do “backup”. E de forma alguma haveria prejuízo à eficiência e integridade dos dados. Não enxergo nenhum benefício no uso do VMWare Consolidated Backup.
Como mecanismo complementar (útil para a recuperação de desastres rápida, quando uma máquina virtual se corrompa), a própria documentação citada sugere que você faça “backup” dos arquivos .dsk e .vmdk, como fora citado, isso numa periodicidade menor (ex.: semanalmente ou mensalmente), conforme a citação:
É altamente recomendável que o “Director” do “Bacula” seja instalado em uma máquina dedicada, obviamente diversa da que hospeda as máquinas virtuais, e esta recomendação também é feita no supramencionado Guia.
Abracetas!
Heitor Faria
Fazendo Backup do Banco Microsoft SQL
11 de Janeiro de 2010, 0:00 - sem comentários aindaComo meu amor pelo “Bacula” é maior pelo meu desprezo à Microsoft, seguem algumas dicas de como fazer o backup de um banco do Microsoft SQL.
De costume, deveremos configurar um script RunClientBeforeJob (isso considerando que o referido banco esteja instalado em uma máquina com o cliente Bacula) para que seja gerado um dump do banco, que então deverá ser salvo pelo “Bacula” no seu storage.
Criando o RunClientBeforeJob script:
O script deverá ser um arquivo “.bat” do Windows (ex.: c:\bkpbanco.bat), contendo algo parecido com os comandos abaixo:
Program Files\Microsoft SQL Server\90\Tools\Binn\osql.exe” -E -Q “BACKUP DATABASE mydatabase TO DISK=’C:\tmp\mydatabase.bak’ WITH FORMAT”
No bacula-dir.conf, no recurso “Job” específico para backup deste servidor, você deve configurar o Bacula para chamar o script criado:
Job {
…
RunClientBeforeJob = C:/bkpbanco.bat
Fail Job On Error = Yes
…
}
O “Fail Job On Error” serve para abortar o “job”, caso o script termine em erro – o que é muito útil para garantir o sucesso de seu backup.
Não esqueça que no fileset correspondente ao referido job, o arquivo “dump“ criado deverá ser incluído!
Você deve também criar um “ClientRunAfterJob” para chamar um script que apague o arquivo de dump criado, após a realização do “job” de backup pelo “Bacula”.
Restaurando:
Para restaurar o banco, primeiro você deverá restaurar o arquivo de dump, através do Bacula.
Daí então, pode utilizar a linha de comando ou a interface gráfica do Microsoft SQL para restaurá-lo.
Ex.: http://msdn.microsoft.com/en-us/library/aa238405(SQL.80).aspx
Referências Bibliográficas:
Documentação Backup através da Linha de Comando: http://msdn.microsoft.com/en-us/library/aa225964(SQL.80).aspx
Shell-script para Ejetar Fita
23 de Dezembro de 2009, 0:00 - sem comentários aindaO script para desmontar e ejetar a fita magnética de um drive manual, pode ser executado após todos os jobs do “Bacula” terem sido concluídos, isso de maneira automática (..sombra e água fresca! Melhor que isso só um robô-de-fitas ou um grande storage em disco… =P).
Para tanto, uma boa opção é chamá-lo através da opção “RunAfterJob“, isso no job do Catálogo – que é sempre o último a ser executado. Exemplo de configuração do job no bacula-dir.conf:
Job {
Name = “BackupCatalog”
JobDefs = “Padrao”
Level = Full
FileSet=”Catalog”
Schedule = “AgendaPadrão”
RunBeforeJob = “/etc/bacula/make_catalog_backup bacula bacula”
RunAfterJob = “/etc/bacula/delete_catalog_backup”
RunAfterJob = “/etc/bacula/scripts/ejeta-fita.sh”
…
Neste caso, ejeta-fita.sh seria algo parecido com isto:
exec 6>&1
exec > /etc/bacula/scripts/status_ejeta-fita.log # grava um log do script [records script log]
/etc/bacula/bconsole -c /etc/bacula/bconsole.conf <<END
umount storage=”nome_do_storage[storage_name]”
END
exec 1>&6 6>&-mt -f /dev/nst0 rewind # se necessário, substitua o nst0 por outro dispositivo de fitas (st0, nst1, etc).
mt-f /dev/nst0 eject
Abraços,
Heitor Faria (www.bacula.com.br)