Home / server / Questions / 411856
Accepted
Ethabelle
Asked: 2012-07-28 06:38:54 +0800 CST

Bacula -- splitting volumes?

  • 772

I've been utilizing Bacula for backups. I implemented the system and it works great! However, one of the things I did was just have everything fall under one volume. I decided that I wanted to complicate it just a little bit so that Incrementals would only be kept for a week and then it would purge and rewrite those in that volume, thus making sure space doesn't become an issue because we keep 30 days worth of Incrementals.

So what I tried to do was have a Volume called DAILY, a volume called WEEKLY, and a volume called MONTHLY. The Daily is incremental, the weekly is differential, and the monthly is a full. We would keep daily for 7 days, monthly for 30 days, and full for a year (because we need to!).

Now, I know this can be done with tapes. The problem is I use disks... and if I try to do the above it either a) crashes (if the Full/Incremental Jobs are under the same Schedule) or b) doesn't work (it creates a full backup on the daily volume, etc).

Has anyone attempted this? Or can give me an idea on how they have theirs set up? I'm just not sure why it's having issues with this...

Bacula Example;

The Pools

Pool {
   Name = Daily
   Pool Type = Backup
   Volume Retention = 3 days
   Recycle = yes
   AutoPrune = yes
   LabelFormat = DAILY
   Maximum Volume Bytes = 50G
}

Pool {
   Name = Weekly
   Pool Type = Backup
   Volume Retention = 30 days
   Recycle = yes
   AutoPrune = yes
   LabelFormat = WEEKLY  
   Maximum Volume Bytes = 100G
}

Pool {
   Name = Monthly
   Pool Type = Backup
   Volume Retention = 365 days
   Recycle = yes
   AutoPrune = yes
   LabelFormat = MONTHLY
}

The Job/Client/Schedule

Client {
   Name = centos13
   Password = *IMAHAPPYLITTLEPASSWORD*  
   Address = centos13
   FDPort = 9102
   Catalog = MyCatalog
   File Retention = 30 days
   Job Retention = 6 months
}

FileSet {
   Name = centos13
   Include {
     File = /etc/bacula/bacula-fd.conf
     Options {}
   }
}

Schedule {
   Name = centos13
   Run = Level=Full Pool=Monthly 1st sat at 00:05
   Run = Level=Differential Pool=Weekly sat at 00:05
   Run = Level=Incremental Pool=Daily mon-fri at 00:05
}


Job {
   Name = centos13
   Type = Backup
   Client = centos13
   FileSet = centos13
   Schedule = centos13
   Storage = File
   Messages = Standard
   Full Backup Pool = Monthly
   Incremental Backup Pool = Daily
   Differential Backup Pool = Weekly
}
bacula

1 Answers

  1. Best Answer

    In order to get Bacula to do what you want you need more than just volumes - you need to put those volumes into separate pools and let your jobs know that you want to use different pools for different backup levels.

    The magic syntax is:

    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
}

    (shamelessly thieved from http://wiki.bacula.org/doku.php?id=sample_configs -- Check the bacula docs as I think there are probably other places you can specify the per-level pools, like JobDefs & possibly Client)

    You would then set retention periods on the pool (or constituent volumes) to meet the requirements you outlined earlier.

    On the subject of disk space, I've found it's better with disk backups to treat them like they're tapes.
    I suggest you define a "reasonable" `Maximum Volume Bytes in your Pool resource (and update any existing volumes to reflect it), and then create a bunch of volumes that Bacula will cycle through on its own as it "fills" each volume, and recycle in accordance with whatever retention policies you've set up.
    In my case I have 200G of space for backups, broken out as 100 2GB files.

    This has a few advantages:

    • The backup volumes fit on a DVD
      (so if I need to archive them forever I can just chuck them onto a disc)

    • Off-Site sync only needs to push the files that changed
      (smaller than one 200G volume)

    • Faster disaster recovery
      (If I ever need to recover a server using my remote archive I only need to download its bootstrap (.bsr) and the volumes I need to restore it.)

    • If my hard drive dies I have some hope that it will only kill some of the files.

    • 3