Para fazer com que o Bacula faça o que você quer, você precisa de mais do que apenas volumes - você precisa colocar esses volumes em pools separados e deixar seus trabalhos saberem que você deseja usar diferentes pools para diferentes níveis de backup.
A sintaxe mágica é:
Job {
Name = "Test"
Type = Backup
Client = backup-fd
FileSet = "FileSetTest"
Storage = SomeStorage
Schedule = "ScheduleTest"
Pool = Default
Full Backup Pool = FullTest
Incremental Backup Pool = IncrTest
Differential Backup Pool = DiffTest
}
(descaradamente ladrões de link - Verifique os documentos do bacula, pois acho que provavelmente existem outros lugares você pode especificar os pools por nível, como JobDefs
e possivelmente Client
)
Você definiria períodos de retenção no pool (ou volumes constituintes) para atender aos requisitos descritos anteriormente.
Sobre o tema do espaço em disco, descobri que é melhor usar backups em disco para tratá-los como se fossem fitas.
Sugiro que você defina um Bytes de Volume Máximo "razoável" no seu recurso Pool (e atualize todos os volumes existentes para refleti-lo) e, em seguida, crie vários volumes que o Bacula percorrerá por conta própria ao "preencher" cada volume, e reciclar de acordo com as políticas de retenção que você configurou.
No meu caso, tenho 200G de espaço para backups, divididos em 100 arquivos de 2GB.
Isso tem algumas vantagens:
-
Os volumes de backup cabem em um DVD
(por isso, se eu precisar arquivá-los para sempre, posso apenas jogá-los em um disco) -
A sincronização fora do local só precisa enviar os arquivos que foram alterados. (menor que um volume de 200G)
-
Recuperação de desastre mais rápida
(Se eu precisar recuperar um servidor usando o meu arquivo remoto, só preciso fazer o download do bootstrap (.bsr) e dos volumes necessários para restaurá-lo.) -
Se meu disco rígido morrer, espero que ele mate apenas alguns dos arquivos.