Jobs de Cópia e Migração

Os Jobs de cópia e migração (copy e migration) do Bacula são ótimos para mover dados de backup de hardware de armazenamento antigo para novos, executar backups disk-to-disk-to-tapes (disco para disco para fitas) ou implementar um segundo armazenamento off-site.

A cópia e migração acontecem no nível de granularidade de Job, desta forma o tamanho da fita ou mídia de origem ou destino não é importante. Os Jobs a serem copiados de um Pool (e Storage) Bacula de origem devem ser selecionadas a partir de alguns critérios definidos e são armazenadas em uma Pool (e Storage) de destino.

A diferença entre os jobs de cópia e migração é que o Bacula descarta os Jobs gravados da Pool de origem no caso da migração.

Quando o backup original de um Job copiado é reciclado ou excluído por algum motivo, o Bacula selecionará automaticamente a cópia para fazer uma restauração de um cliente naquele determinado momento, se solicitado.

Os trabalhos de cópia e migração não requerem conexão com os Clientes do Bacula. Isso geralmente significa que ele pode ser executado durante o dia, sem risco de impacto nos demais serviços.

O escopo de seleção dos Jobs para a cópia, pode ser:

  • um ou vários Jobs de backup configurados;
  • um ou vários Volumes, pelo nome.
  • Jobs de um cliente, pelo nome.
  • Jobs realizados que correspondam a uma expressão regular;
  • se um trabalho existe em um determinado volume;
  • volumes com o somatório de ocupação em uma Pool inferior ou superior a um dado valor;
  • tamanho do volume.

Em um resumo, para executar um Job de cópia ou migração, você deve definir um recurso Job especial em bacula-dir.conf com a diretiva Type igual a Copy ou Migrate; a especificação de uma Pool origem; e, pelo menos, mas não menos importante, um dos SelectionType (e muitas vezes SelectionPattern) que define os critérios de seleção capazes de encontrar Jobs para serem copiados.

Nos recursos Pool (ainda em bacula-dir.conf), você deve especificar na Pool de origem a diretiva Storage (o mesmo nos quais seus volumes já estão sendo gravados, que também será a origem da cópia), além da diretiva NextPool, que deve informar o nome de outra Pool de destino da cópia. Por fim, no recurso da Pool de Destino, também deve ser especificado uma diretiva Storage para um dispositivo de armazenamento diferente, que será o de destino.

Agora vamos ver mais informações sobre cada uma dessas diretrizes necessárias. Mais adiante há também um exemplo completo de configuração:

a) Para o recurso Job

Pool =

Determina onde o algoritmo de seleção de trabalhos para cópia será aplicado. É a Pool de origem.

Type = Migrate

Os Jobs selecionados são movidos da Pool de origem para a de destino (os trabalhos originais são descartados). Ou…

Type = Copy

Os Jobs são copiados para o Pool de destino. Eles receberão os tempos de retenção e reciclarão o comportamento da nova Pool, de igual sorte.

Selection Type =

Determina como os JobIds para cópia ou migração serão selecionados. Esses são os valores possíveis:

  • SmallestVolume – seleciona todos os Jobs do menor volume de pool de origem.

  • OldestVolume – seleciona todos os Jobs do volume mais antigo.

  • Client – se utilizado, requer também uma outra diretiva (SelectionPattern) que deve ser uma Expressão Regular que corresponda aos nomes dos clientes para cópia / migração apenas dos Jobs dos mesmos.

  • Volume – Se utilizada, essa diretiva também requer a SelectionPattern, neste caso uma Expressão Regular que corresponderá aos nomes de volume cujos Jobs serão copiados.
  • Job – Neste caso a SelectionPattern deve corresponder a nomes de Jobs.

  • SQLQuery Uma query SQL para encontrar JobIds diretamente do banco de dados Bacula a serem copiados.

  • PoolOccupancy o Bacula somará o tamanho de todos os volumes da Pool de origem. Se for menor do que as diretivas acessórias (necessárias no próprio recurso da Pool) MigrationLowBytes ou superior a MigrationHighBytes, ele migrará os trabalhos até que a ocupação da Pool volte aos limites definidos.
  • PoolUncopiedJobs – Este é bastante popular para backups off-site. Ele copiará todos os trabalhos que não tiverem uma cópia no Pool de destino.

Selection Pattern =

Esta diretiva não é necessária para SelectionType, OldestVolume nem SmallestVolume, mas indispensável para Client, Volume e Job. O valor de SelectionPattern deve ser um RegExp que encontrará os respectivos nomes de diretiva. Exemplo:

Selection Type = SQLQuery 
Selection Pattern = "select '<Jobid>';" # seleciona um Job apenas para copia

b) Para o recurso Pool de Origem

Migration Time =

Um período de tempo que, quando acabou, os Jobs de backup podem ser migrados se um Job de Migração for executado.

Migration High Bytes =

Tamanho máximo da ocupação da Pool.

Migration Low Bytes =

Tamanho mínimo da ocupação da Pool.

Next Pool =

Especifica o que é o pool de destino da cópia (obrigatório). No entanto, também é possível substituir esta especificação de NextPool no recurso Schedule, permitindo que você execute Jobs de cópia ou migração para Pools de destino diferentes de acordo com o tempo.

Storage =

Neste caso, o nome do Storage de origem1 deve ser especificado. O mesmo que provavelmente já vem sendo utilizado para gravar os backups desta Pool. De qualquer sorte, este é o melhor lugar para associar as Pool aos seus Storages, independente de estar configurando um job de cópia.

c) Para o recurso Pool de Destino

Storage =

O nome do Storage de destino deve ser especificado, onde os Jobs de cópia ou migração serão armazenados.

      1. Um exemplo de configuração de Job de Cópia

a) Recursos Pool (bacula-dir.conf)

# Pool de Origem
Pool {  
  Name = Monthly-Disk   
  Pool Type = backup 
  Storage = File1     # storage de origem
  Next Pool = Copy    # nome pool de destino
  ...
}

# Pool de Destino
Pool {
  Name = Copy
  Pool Type = backup 
  Storage = File2      # storage de destino
  ...
}

b) Job Resource (bacula-dir.conf)

Job {
  Name = "CopyJobs" 
  JobDefs = DefaultJob
  Type = Copy 	# ou Migrate
  Pool = Monthly-Disk   	# pool de origem
  Selection Type = PoolUncopiedJobs
  Schedule = CopySchedule  	# recomendado
}

Aplique as alterações na configuração e execute (comando run) o Job criado como teste. Neste exemplo, a primeira cópia pode levar muito tempo, uma vez que irá selecionar todos os Jobs nunca copiados da Pool de origem (SelectionPattern = PoolUncopiedJobs). Portanto, planeje o seu início cuidadosamente pois essa primeira carga de trabalho pode ser grande. Você também deve querer criar e especificar para este Job um Schedule diferente de seu backup regular, como no exemplo.

1Esse Storage já deve existir no bacula-dir.conf na forma de um recurso.

Disponível em: pt-brPortuguêsenEnglish (Inglês)esEspañol (Espanhol)

Deixe uma resposta