Entendendo um pouco da estrutura de backup do Bacula.

logo
Backup Storage – Copy (Cópia) ou Migration (Migração).
O Migration (Migração) – Tem como função mover os dados de um volume (storage1) para um novo volume (storage2). Em particular, refere-se a um job de trabalho. Como parte desse processo, os registros do catálogo de arquivos associados com o primeiro trabalho de backup são expurgados, ficando somente os registro no segundo Volume/Storage.
O processo de Copy (cópia) é idêntico ao recurso de migração, com a ressalva de que o trabalho que é copiado é deixado inalterado no segundo Volume/Storage. Criando se então duas cópias idênticas de um mesmo backup. No entanto, a cópia é tratada como uma cópia em vez de um trabalho de backup. Portanto, não está diretamente disponível para restauração da forma mais fácil. (bconsole).
storage_1 (1)

Ajustando o servidor ba-vm-bkp-02 – 192.168.0.251.
Instalando o bacula-sd (Storage) no segundo servidor.
# apt-get install bacula-sd -y
Configurando o arquivo bacula-sd.conf, ajustando os parâmetros Storage, Director e Device.
# cd /etc/bacula
# vim bacula-sd.conf

Storage {                             
     Name = ba-vm-bkp-02               # NOME DO STORAGE 2.
     SDPort = 9103                 
     WorkingDirectory = "/var/lib/bacula"
     Pid Directory = "/var/run/bacula"
     Maximum Concurrent Jobs = 20
     SDAddress = 192.168.0.251         # IP OU FQDN DO STORAGE 2. 
}
No parâmetro abaixo, será configurado o Director do servidor Bacula (ba-vm-bkp-01/192.168.0.218). Lembrando que a senha precisa ser exatamente igual ao arquivo bacula-dir.conf.
Director {
  Name = bacula-dir
  Password = "centos"
}
No parâmetro abaixo esta a configuração do Device, local onde serão armazenados os volumes físicos do backup.
Device {
     Name = FileStorage
     Media Type = File
     Archive Device = /backup   # Diretório de armazenamento.
     LabelMedia = yes;                   
     Random Access = Yes;
     AutomaticMount = yes;              
     RemovableMedia = no;
     AlwaysOpen = no;
}
Criando o diretório /backup e ajustando as permissões de acesso.
# mkdir /backup
# chown -R bacula.bacula /backup
Reiniciando o serviço do bacula-sd no segundo servidor (ba-vm-bkp-02).
# /etc/init.d/bacula-sd restart
Stopping Bacula Storage Daemon: bacula-sd
Starting Bacula Storage Daemon: bacula-sd
Ajustando o servidor ba-vm-bkp-01 – 192.168.0.218.
Ajustando o arquivo bacula-dir.conf. Este ajuste tem como objetivo adicionar o segundo Storage.
# cd /etc/bacula

# vim bacula-dir.conf
Adicionando o segundo Storage.
# Segundo Storage - bacula-sd
Storage {
        Name = File2
        # Do not use "localhost" here    
        Address = 192.168.0.251                # N.B. Use a fully qualified name here
        SDPort = 9103
        Password = "centos"
        Device = FileStorage
        Media Type = File
}
Validando o ajuste.
# /etc/init.d/bacula-dir restart
Stopping Bacula Director services:                         [  OK  ]
Starting Bacula Director services:                         [  OK  ]
Verificando o status do Storage 2.
# bconsole 
Connecting to Director localhost:9101
1000 OK: 1 bacula-dir Version: 7.0.5 (28 July 2014)
Enter a period to cancel a command.
*status
Status available for:
     1: Director
     2: Storage
     3: Client
     4: Scheduled
     5: All
Select daemon type for status (1-5): 2
The defined Storage resources are:
     1: File
     2: File2
Select Storage resource (1-2): 2
Novamente no bacula-dir.conf, será configurado os parâmetros da Pool de cópia e também alguns ajustes na Pool Diario.
# vim bacula-dir.conf
Ajustando a Pool que terá o volume sendo copiado para o segundo storage
Observação: No exemplo, vou utilizar a Pool Diario para ser copiada para o segundo Storage.
Pool {
        Name                    = Diario
        Pool Type               = Backup
        Recycle                 = yes
        AutoPrune               = yes
        Volume Use Duration     = 24 hours
        Volume Retention        = 1 days
        Maximum Volume Bytes    = 10G
        Maximum Volumes         = 4
        Label Format            ="diario-${NumVols}"
        # Informando a Pool Diario que teremos uma Poll copia chamada Diario-copia
        Next Pool               = Diario-copia
        # Informando em qual storage será armazenado
        Storage                 = File
}

Pool {
        Name                    = Diario-copia
        Pool Type               = Backup
        Recycle                 = yes
        AutoPrune               = yes
        Volume Use Duration     = 24 hours
        Volume Retention        = 1 days
        Maximum Volume Bytes    = 10G
        Maximum Volumes         = 4
        Label Format            ="diario-copia-${NumVols}"
        # Informando em qual storage será armazenado
        Storage                 = File2
}
Parâmetros importantes.
PoolUncopiedJobs – Seleciona os jobs que nunca foram copiados.
Selection Pattern – Para o OldestVolume e SmallestVolume, esta opção será ignorada. Para a opção Client, Volume e Job, esta “pattern” deve ser uma expressão regular válida para filtrar os nomes encontrados na pool. Diretivas para a pool de onde os volumes serão migrados.
Migration Time – Define um tempo após o qual os jobs realizados serão migrados.
Migration High Bytes – Numero de bytes após o qual os jobs excedentes serão migrados..
Migration Low Bytes – Mínimo de bytes para que a migração ocorra.
Next Pool (indispensável!) – Específica para qual pool os jobs serão migrados.
Storage – Especifica um storage específico para a migração (terá prioridade sobre todas as outras especificações de storage. Ex.: “schedule”, jobs, etc).
Criando o Job da cópia (“Diario-Copia – Segundo Storage”), para que tudo funcione perfeitamente.
Job {
        Name            = "Diario-Copia - Segundo Storage"
        JobDefs         = "DefaultJob"
        Type            = Copy                  # Se for migração Migrate
        Pool            = Diario                # Pool de origem
        Storage         = File                  # Storage de origem
        Selection Type  = PoolUncopiedJobs      # copiar tudo que não foi copiado para o segundo Storage da Pool Diario.
}
Reiniciando o bacula-dir.
# /etc/init.d/bacula-dir restart
Stopping Bacula Director services:                         [  OK  ]
Starting Bacula Director services:                         [  OK  ]
Validando todas as alterações.
# bconsole
*run
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
A job name must be specified.
The defined Job resources are:
     1: BackupClient1
     2: Backup do cliente Debian
     3: Backup do cliente Windows
     4: Diario-Copia - Segundo Storage
     5: BackupCatalog
     6: RestoreFiles
Select Job resource (1-6): 4
Run Copy job
JobName:       Diario-Copia - Segundo Storage
Bootstrap:     *None*
Client:        bacula-fd
FileSet:       Full Set
Pool:          Diario (From Job resource)
NextPool:      Diario-copia (From Job Pool's NextPool resource)
Read Storage:  File (From Pool resource)
Write Storage: File2 (From Job Pool's NextPool resource)
JobId:         *None*
When:          2015-05-14 16:40:36
Catalog:       MyCatalog
Priority:      10
OK to run? (yes/mod/no):yes
Se tudo correu bem, com o comando list jobs será possível verificar se o backup foi feito realmente e se também foi copiado para o segundo Storage.
Parâmetros importantes:
c – Significa cópia.
T – Backup concluído sem erro.
|   266 | Diario-Copia - Segundo Storage | 2015-05-14 16:44:55 | c    | I     |        0 |             0 | T         |
|   268 | Diario-Copia - Segundo Storage | 2015-05-14 16:44:57 | c    | I     |        0 |             0 | T         |
|   270 | Diario-Copia - Segundo Storage | 2015-05-14 16:45:00 | c    | I     |        0 |             0 | T         |
|   272 | Diario-Copia - Segundo Storage | 2015-05-14 16:45:03 | c    | I     |        0 |             0 | T         |
|   274 | Diario-Copia - Segundo Storage | 2015-05-14 16:45:07 | c    | I     |        0 |             0 | T         |
Na dúvida, basta acessar o servidor do segundo Storage (ba-vm-bkp-02), e verificar se no diretório /backupcontém os volumes de cópia.
root@ba-vm-bkp-02:~# cd /backup/
root@ba-vm-bkp-02:/backup# ls
diario-copia-0 diario-copia-1
Continua…
Fonte:
http://www.bacula.com.br


http://www.bacula.org

http://tutoriaisgnulinux.com/?p=13811

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Como mapear permanentemente uma unidade de rede no Ubuntu

Imagem
Como mapear permanentemente uma unidade de rede no Ubuntu Se você precisa ter acesso constante a uma pasta de rede, aprenda a mapear permanentemente uma unidade de rede no Ubuntu e resolva seu problema. Este tutorial mostrará como mapear permanentemente uma unidade de rede, que pode ser por exemplo, um compartilhamento do Windows. Antes de fazer isso, é preciso preparar o sistema, ou seja, fazer algumas medidas, instalar alguns softwares, para que o sistema possa montar unidades de rede. Preparando o Ubuntu para mapear permanentemente uma unidade de rede Para mapear permanentemente uma unidade de rede no Ubuntu, faça o seguinte: Passo 1. Abra um terminal (No Unity, use o Dash ou pressionando as teclas CTRL+ALT+T); Passo 2. Instale o pacote cifs-utils, para obter suporte ao compartilhamento de arquivos com o Microsoft Windows, OS X e outros sistemas Unix. Para isso, use a Central de programas do Ubuntu ou use o comando abaixo: sudo apt-get install cifs-utils -y Passo 3. Abra o...
Leia mais

Instalando e Configurando o Citrix XenServer 6.5 - Parte 1

Imagem
Instalando e Configurando o Citrix XenServer 6.5 - Parte 1 Como dispositivos de computação superam rapidamente os requisitos de sistemas operacionais, tem se tornado cada vez mais eficiente para as organizações investir/migrar para sistemas virtualizados. Operarem as tecnologias de virtualização do sistema não são nada de novo, mas ao longo dos últimos anos tornaram-se cada vez mais popular como centros de dados olhar para fornecer mais funcionalidade nos mesmos ou menos quantidades de espaço físico. Por simplesmente alavancando recursos não-utilizados em servidores poderosos/workstations empresas podem efetivamente executar múltiplos servidores lógicos em um ou vários servidores físicos. XenServer Guia de Instalação e Configuração - Parte 1 Citrix oferece uma solução deste tipo, conhecido como  XenServer, que utiliza o popular,  hypervisor Xen  Linux.O hypervisor Xen é referido como um  "hypervisor   bare-metal", significando que ele é instalado no s...
Leia mais

CLI Linha de comando de Interface

Imagem
CLI Linha de comando de Interface Uma interface de linha de comando (CLI) é um meio de interação com um programa de computador onde o usuário (ou cliente) emite comandos para um programa na forma de sucessivas linhas de texto (linhas de comando). A interface de linha de comando evoluiu de uma forma de diálogo, uma vez realizada por seres humanos mais teleprinter máquinas, em que operadores humanos trocaram informações remotamente, geralmente uma linha de texto por vez. Os primeiros sistemas de computador utilizados frequentemente as máquinas de telex como meio de interacção com um operador humano. O computador tornou-se uma das extremidades do modelo de tele-tipo humano para humano. Portanto, em vez de um ser humano a comunicar com outro humano ao longo de um telex, de um ser humano comunicados com um computador. Em tempo, o tele-tipo real mecânica foi substituído por um de vidro tty (teclado e tela, mas emulando o tele-tipo , e depois por um terminal (on...
Leia mais