Melhorias Gerais (nativas):
Melhorias de performance do bconsole
Nas versões anteriores do Bacula certos comandos bconsole poderia esperar um longo tempo devido a conexão com o banco de dados estar travada. Isto era especialmente notável quando um grande número de jobs estava em execução e colocando seus atributos no catálogo. Esta versão usa uma conexão de catálogo em separado que deve aumentar significativamente o desempenho.
Comando: status storage
O status storage foi melhorado para não exibir recursos duplicados e se tornar mais compacto.
Comando: status schedule
O status schedule, ao contrário do status director que exibe apenas os jobs agendados para as próximas 24 horas, permite a listagem cronológica dos próximos agendados por padrão (até 20 linhas). Exemplo:
Scheduled Jobs: Level Type Pri Scheduled Job Name Schedule ====================================================================== Differential Backup 10 Sun 30-Mar 23:05 BackupClient1 WeeklyCycle Incremental Backup 10 Mon 24-Mar 23:05 BackupClient1 WeeklyCycle Incremental Backup 10 Tue 25-Mar 23:05 BackupClient1 WeeklyCycle ... Full Backup 11 Mon 24-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup Full Backup 11 Wed 26-Mar 23:10 BackupCatalog WeeklyCycleAfterBackup ... ====
No entanto, a listagem pode ser customizada:
- days=nn Número de dias a posterior para listar.
- limit=nn Número de linhas para exibir.
- time=”YYYY-MM-DD HH:MM:SS” Tempo futuro para realizar início da listagem. O padrão é o tempo atual.
- schedule=schedule-name Especifica apenas um agendamento (schedule) a ser listado.
- job=job-name Especifica apenas a agenda de um determinado job.
Medidor de Progresso do Backup
O novo File Daemon foi aprimorado para enviar seu progresso (arquivos processados e bytes escritos) dos jobs ao Diretor a cada 30 segundos. Estes números podem ser exibidas com um comando do bconsole status director.
Novo Comando truncate
Esse volume irá truncar um volume (liberar o espaço dos dados gravados) se o volume estiver purged e se a opção: Action On Purge = Truncate (Pool – bacula-dir.conf).
Novo Comando Resume
O comando resume faz exatamente a mesma coisa que o comando restart: re-submete um job terminado com erro ou cancelado.
Melhorias para o comando Cancel e Restart
O comando”restart” permite informar um conjunto de jobs a ser reiniciado. Além disso, tanto o comando “cancel” e “restart” permitem introduzir um número de JobIds separados por vírgulas ou um intervalo de JobIds indicado por um traço entre o início e o final da seleção (por exemplo, 3-10). Finalmente, os dois comandos também permitem introduzir a palavra-chave especial “all” para selecionar todos os trabalhos apropriados.
Melhoria de Performance nos Jobs: Migration/Copy/VirtualFull
O SD agora permite múltiplos jobs simultâneos de leitura no mesmo volume de disco, aprimorando bastente os jobs de Migration, Copy, ou VirtualFull jobs that read disk Volumes. Testes indicam que esses jobs podem ser até 10 vezes mais rápidos dessa maneira. Essa opção é nativa do SD, não sendo necessária configuração adicional.
Melhorias na Consolidação do Backup VirtualFull
Por padrão o Bacula seleciona jobs automaticamente para um job VirtualFull, entretanto você pode querer criar um Job Virtual baseado em determinado ponto do tempo.
Por exemplo:
+-------+---------+-------+----------+----------+-----------+ | JobId | Name | Level | JobFiles | JobBytes | JobStatus | +-------+---------+-------+----------+----------+-----------+ | 1 | Vbackup | F | 1754 | 50118554 | T | | 2 | Vbackup | I | 1 | 4 | T | | 3 | Vbackup | I | 1 | 4 | T | | 4 | Vbackup | D | 2 | 8 | T | | 5 | Vbackup | I | 1 | 6 | T | | 6 | Vbackup | I | 10 | 60 | T | | 7 | Vbackup | I | 11 | 65 | T | | 8 | Save | F | 1758 | 50118564 | T | +-------+---------+-------+----------+----------+-----------+
and you want to consolidate only the first 3 jobs and create a virtual backup equivalent to Job 1 + Job 2 + Job 3, you will use jobid=3 in the run command, then Bacula will select the previous Full backup, the previous Differential (if any) and all subsequent Incremental jobs.
e que pretende consolidar apenas os primeiros três jobs e criar um backup equivalente virtual de Job Job 1 + 2 + 3 Job, você usará jobid = 3 no comando run, entãoo acula irá selecionar o anterior backup completo, o diferencial anterior (se houver) e todos os trabalhos incrementais subseqüentes.
run job=Vbackup jobid=3 level=VirtualFull
Se você quiser consolidar uma lista de jobs específica, você deve informar lista exata de jobs na linha de comando. Por exemplo, para consolidar o último diferencial e tudo subseqüente incremental, você usará jobid = 4,5,6,7 ou jobid = 4-7 na linha de comando executado. Como um dos Job na lista é um backup Diferencial, Bacula irá definir o novo nível de trabalho para diferenciais. Se a lista é composta apenas com trabalhos incrementais, o novo trabalho terá um nível definido para Incremental.
run job=Vbackup jobid=4-7 level=VirtualFull
Ao usar esse recurso, Bacula descartará automaticamente os trabalhos que não estão relacionados com o trabalho atual. Por exemplo, especificar jobid = 7,8, Bacula descartará JobId 8, porque não é parte do mesmo trabalho de backup.
Nós não recomendamos usá-lo, mas se realmente desejar consolidar trabalhos que têm nomes diferentes (clientes, portanto, provavelmente, diferentes conjuntos de arquivos, etc ..), você deve usar alljobid = palavra-chave em vez de jobid =.
run job=Vbackup alljobid=1-3,6-8 level=VirtualFull
Limitar tráfego de job
A nova directiva Job Bandwidth limitação pode ser adicionado ao arquivo de daemon e / ou configuração do Diretor para limitar a largura de banda utilizada por um job em um cliente. Ele pode ser definido no arquivo conf do arquivo do daemon de todos os trabalhos executados em que File daemon, ou pode ser definida para cada trabalho em arquivo conf do diretor. A velocidade é sempre especificada em bytes por segundo.
Por exemplo:
FileDaemon {
Name = localhost-fd
Working Directory = /some/path
Pid Directory = /some/path
...
Maximum Bandwidth Per Job = 5Mb/s
}
O novo trabalho de largura de banda flexível exemplo acima faria com que todos os trabalhos que executam com o FileDaemon não exceder 5 megabytes por segundo de taxa de transferência, quando o envio de dados para o Storage Daemon. Note, a velocidade é sempre especificada em bytes por segundo (não em bits por segundo), e o caso (superior / inferior) dos personagens especificação é ignorada (ou seja, de 1 MB / s = 1Mb / s).
Você pode especificar os seguintes modificadores de parâmetros de velocidade: k / s (1.000 bytes por segundo), kb / s (1.024 bytes por segundo), m / s (1.000.000 bytes por segundo), ou MB / s (1.048.576 bytes por segundo).
Por exemplo:
Job {
Name = locahost-data
FileSet = FS_localhost
Accurate = yes
...
Maximum Bandwidth = 5Mb/s
...
}
O exemplo acima causaria trabalho localhost-data não superior a 5 MB / s de taxa de transferência ao enviar dados do daemon de arquivo para o servidor de armazenamento.
Um novo comando do console setbandwidth licenças para definir dinamicamente a taxa de transferência máxima de um trabalho em execução ou para trabalhos futuros de um cliente:
* setbandwidth limit=1000 jobid=10
Por favor, note que o valor especificado para o parâmetro de linha de comando limite é sempre em unidades de 1024 bytes (ou seja, o número é multiplicado por 1024 para dar o número de bytes por segundo). Como consequência, o limite acima de 1000 será interpretado como um limite de 1000 * 1024 = 1.024.000 bytes por segundo.
Multiple Console Directors
Suporte para múltiplos Directors no bconsole e bat (bconsole.conf e bat.conf) foi implementado e / ou melhorado.
Agendamento para o Último dia do Mês
Esta versão do Bacula agora permite especificar a palavra-chave lastday na directiva de execução de um recurso de agendamento. Se lastday for especificado, ele será aplicado apenas aos meses especificados na directiva prazo. Nota: por padrão, todos os meses são especificados.
Novas funcionalidades opcionais:
Storage daemon para Storage daemon
Aprimorados os jobs de cópia e migração, permitindo a transferência diretamente de um SD para o outro. Comumente permite a replicação off-site de dados do backup. O diagrama a seguir fornece uma explanação:
Fonte: http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html
SD conecta no Cliente (FD)
Se a diretiva “SD Calls Client” for configurada como “true” num recurso Client (bacula-dir.conf) qualquer job de Backup, Restore, Verify, Copy, or Migration Job para este cliente irá esperar o Storage Daemon se conectar nele. Por padrão essa opção é falsa e acontece o contrário: cliente se conecta no SD. Essa diretiva pode ser útil se o seu SD está atrás de um firewall que não permite o recebimento de conexões.
Fonte: http://www.bacula.org/7.0.x-manuals/en/main/New_Features_in_7_0_0.html
Next Pool
A Next Pool pode configurada por job, de maneira que os trabalho de cópia e migração para um Job específico tenham como destino outra pool, e não a “Next Pool” especificada na pool de origem.
Configuração de Cifra de Encripitação
Bacula versão 7.0 e posterior agora permite configurar a cifra de criptografia de dados e o algoritmo de “digestão”. A cifra foi forçado a AES 128, e agora é possível escolher entre as seguintes cifras:
AES128 (padrão)
AES192
AES256
blowfish
O algoritmo digestão foi definido para SHA1 ou SHA256, dependendo das opções do OpenSSL locais. Aconselhamo-lo a não modificar a configuração padrão PkiDigest. Por favor, consulte a documentação do OpenSSL para saber sobre prós e contras sobre estas opções.
FileDaemon {
…
PkiCipher = AES256
}
Storage Address no FD
Quando o Director está atrás de um NAT, em uma WAN, para se conectar ao Storage Demon, o Director usa um IP externo e o File Daemon deve utilizar um IP interno para se conectar ao SD.
O caminho normal para lidar com esta situação é usar um nome canônico como “storage-server” que será resolvido no lado do diretor como o endereço WAN e no lado do cliente como o endereço LAN. Isso agora é possível configurar esse parâmetro usando a nova directiva FD StorageAddress no recurso Cliente ou Storage (bacula-dir.conf).
Storage {
Name = storage1
Address = 65.1.1.1
FD Storage Address = 10.0.0.1
SD Port = 9103
...
}
Client {
Name = client1
Address = 65.1.1.2
FD Storage Address = 10.0.0.1
FD Port = 9102
...
}
Note que usando a diretiva Cliente FDStorageAddress não permitirá a utilização múltiplos SD e todos backup ou restauração pedidos serão enviados para o FDStorageAddress especificado.
Maximum Concurrent Read Jobs
Esta é uma nova directiva que pode ser usado no arquivo bacula–dir.conf no recurso de armazenamento. O principal objetivo é limitar o número de concorrentes Copiar, Migração e VirtualFull para que eles não monopolizem todas as unidades de armazenamento, causando uma situação de impasse em que estão alocados todos os drives para a leitura, mas nenhuma delas conseguir gravar. Esta situação de impasse pode ocorrer durante a execução múltipla simultânea de cópia, Migração e empregos VirtualFull.
O valor padrão é definido como 0 (zero), o que significa que não há limite para o número de postos de trabalho de leitura. Note-se, limitando os trabalhos de leitura não se aplica a jobs de restauração, que são normalmente iniciados com manualmente. Um valor razoável para esta directiva é a metade do número de unidades que o recurso de armazenamento foi arredondado para baixo. Ao fazê-lo, vai deixar o mesmo número de unidades para a escrita e geralmente evitar o excesso de cometer unidades e um gargalo.
Director job Codes em Message Resource Commands
Before submitting the specified mail command to the operating system, Bacula performs character substitution like in Runscript commands. Bacula will now perform also specific Director character substitution.
Antes de submeter o comando de email mail especificado para o sistema operacional, o Bacula executa comandos de substituição de caracteres como na opção “runscript”. Agora, o Bacula também irá agora realizar substitução específica de caráteres a partir do Director, facilitando a leitura dos códigos..
Adições para as variáveis RunScript
As seguintes variáveis agora estão disponíveis:
- current PID usando %P
- se o job for um clone, usando %C
RunAfterJob = "/bin/echo Pid=%P isCloned=%C"
Read Only Storage Devices
Esta versão do Bacula permite que um storage daemons tenha acesso somente leitura. Isto é, se a directiva ReadOnly é especificada e ativada a unidade só pode ser usada para operações de leitura. A directiva pode ser o ReadOnly é definida em qualquer recurso “Device” (bacula-sd.conf), e é mais útil para reservar uma ou mais unidades para restaurações. A opção é configurada assim:
Read Only = yes
Novo comando prune “expired” volumes
Agora é possível prunar todos os volumes (de um pool, ou globalmente) que estão com o status “expired”. Esta opção pode ser agendada antes ou depois do backup do catálogo e pode ser combinado com a opção “Truncate on Purge” A opção de Prune Expired pode ser usado em vez do script manual_prune.pl.
* prune expired volumes * prune expired volumes pool=FullPool
Para programar esta opção automaticamente, ele pode ser adicionado à definição de trabalho BackupCatalog.
Job {
Name = CatalogBackup
...
RunScript {
Console = "prune expired volume yes"
RunsWhen = Before
}
}
Melhorias de performance para Hardlinks
Se você usar um programa como o Cyrus IMAP que cria um grande número de hardlinks, o tempo para construir a árvore restaurar interativa pode ser excessivamente longo. Esta versão do Bacula tem um novo recurso que mantém automaticamente os hardlinks associadas à árvore restaurar na memória, que consome um pouco mais de memória, mas em muito acelera a construção da árvore. Se o uso de memória é muito grande para o seu sistema, você pode reduzir a quantidade de memória usada durante o comando de restauração, adicionando a opção optimizespeed = false noe comando run do bconsole.
Diretiva DisableCommand
Há uma nova directiva denominada DisableCommand que pode ser colocada no file deamon ou recurso cliente do diretor. Se é no cliente, aplica-se a apenas a ele, caso contrário, a diretiva aplica-se ao Diretor em que se encontra, afetando todos os jobs. O Comando Disable adiciona segurança ao seu daemon Arquivo desativando certos comandos. Os comandos que podem ser desativados são:
backup cancel setdebug= setbandwidth= estimate fileset JobId= level = restore endrestore session status .status storage verify RunBeforeNow RunBeforeJob RunAfterJob Run accurate
Uma ou mais destas palavras-chave de comando podem ser colocado entre aspas duplas e separados por espaços na opção DisableCommand. Nota: os comandos devem ser escritos exatamente como aparecem acima.
Disponível em: 
Português
