Backups to the Future: Eliminate Tape Backups with FreeNAS and Bacula

The future of backups is here, but unfortunately, there aren't any Delorians.
Bacula

With the FreeNAS system in place, let's start building the Bacula system. The test system used here was built on Fedora 8 (Werewolf) with GNOME, because it includes Bacula and its dependencies in its core RPM library. To add the necessary packages and related dependencies, all you need to do is use the Add/Remove Software utility under the Applications menu. When ready, install the following packages:

  • bacula-client

  • bacula-common

  • bacula-console

  • bacula-gnome

  • bacula-console-gnome

  • bacula-console-wxwidgets

  • bacula-director-common

  • bacula-director-mysql

  • bacula-docs

  • bacula-storage-common

  • bacula-storage-mysql

  • bacula-traymonitor

  • mysql

When the installs are complete, start mysqld, and set it to start runlevel 5 from the Services utility in GNOME or use chkconfig. If you're using a different distribution, you need to use the Bacula source files and make/configure the install to get to the next step. This can be more challenging than using an RPM, because of the numerous command-line install options available.

Next, open a terminal to create the MySQL tables needed for Bacula to operate. Run the following scripts created by the Bacula RPM:

/etc/alternatives/create_bacula_databases 
/etc/alternatives /make_bacula_tables
/etc/alternatives /grant_bacula_privileges

After setting up the database, create a local mountpoint (like /mnt/freenas), and mount the FreeNAS share created previously. An easy way to do this on every startup is to add the following line to your /etc/fstab file:

FreeNASServerHostName:/mnt/DATA   /mnt/freenas   nfs   defaults	0 0

To mount the partition immediately, type mount -a.

Before moving on to editing Bacula's configuration files, here's how Bacula works. The Bacula program is composed of three separate dæmons: the director, the storage dæmon and the file dæmon. The director is the boss. It's the main server dæmon that defines jobs, pools, schedules and most of the important settings related to backups. As such, the majority of setup deals with its configuration file /etc/bacula/bacula-dir.conf. The storage dæmon (SD) controls the media written to by Bacula, usually either tapes or disks. These items are configured in the bacula-sd.conf file. The file dæmon (FD), also referred to as the client, runs locally on any system you want to back up. Two other related utilities used here are the GNOME console (gnome-console.conf) and the tray-monitor (tray-monitor.conf) utility.

With this basic knowledge of Bacula's interoperation, open your /etc/bacula/bacual-dir.conf file, and add the following lines (for brevity, I have added only those sections used in our scenario):

JobDefs {
  Name="UserHomes" Type=Backup Client = bacula-fd FileSet =
  "UserHomeFolders" Storage = File Messages = Daemon
}

Job {
  Name = "WeeklyHomeBackups"
  JobDefs = "UserHomes"
  Level = Full
  Schedule = WeeklyFullandDiffs
  Pool = Weekly
  Priority = 10
  Write Bootstrap = "/var/spool/bacula/WeeklyHomeBackups.bsr"
  
}

Job {
  Name = "MonthlyHomeBackups"
  JobDefs = "UserHomes"
  Level = Full
  Schedule = MonthlyFull
  Pool = Monthly
  Priority = 10
  Write Bootstrap = "/var/spool/bacula/MonthlyHomeBackups.bsr"
  
}

Schedule {
  Name = "WeeklyFullandDiffs"
  Run = Level=Full Pool=Weekly sun at 3:00
  Run = Level=Differential Pool=Diffs mon-fri at 3:00
}

Schedule {
  Name = "MonthlyFull"
  Run = Level=Full Pool=Monthly 1st sat at 3:00
}

FileSet {
  Name = "UserHomeFolders"
  Include {
    Options {
      compression=GZIP
      signature = MD5
    }
    File = /home
  }
}

Pool {
  Name = Weekly
  Pool Type = Backup
  Recycle = yes                       
  AutoPrune = yes                     
  Volume Retention = 6 days       
  Maximum Volumes = 5
  Label Format = Bkup-Full
  
}

Pool {
  Name = Diffs
  Pool Type = Backup
  Recycle = yes 
  AutoPrune = yes           
  Volume Retention = 23 hours 
  Maximum Volumes = 1
  Label Format = Bkup-Diff
}

Pool {
  Name = Monthly
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 364 days 
  Maximum Volumes = 12
  Label Format = Bkup-Monthly
}

Although it may seem odd to start at the bottom and discuss the Pool section, it is vital that it is configured correctly. A pool is simply a collection of volumes. Volumes are tapes or disks to which the backup files are written. A pool can contain any number of volumes, but it must have at least one volume. Here, we have set up three pools: a weekly full, a differential and a monthly. This allows us to maintain backups for the current week up until the previous day and a 12-month rotation for our monthly backups.

Then, going from the top section down, there is a Job Definitions (JobDefs) section, and two Jobs modeled around our backup strategy. The JobDefs section defines common properties that several jobs share, like a template. In it, we have listed settings common to both jobs. The Schedule section defines when a given job runs and how often. The schedules listed here run weekly backups every Sunday, daily differentials Monday through Friday and a monthly backup the first Saturday of every month. The Fileset section lists what folders and files to back up and with what options. For this example, we have set Bacula to back up the local users' home folders, a common scenario for backups. Recursion is enabled by default on FileSets, so we need to specify only the parent folder. The backup files also are set to compress using gzip and to hash/encrypt themselves using MD5. Doing both is good practice.

Before saving and closing the file, go through and change any instance of @@Password@@ or like entries to a common password. Rather than cover how each Bacula dæmon authenticates with the other, it's easier simply to change all of them to the same password for the time being and get the system up and running. You can change these passwords later if desired. Change any other password-related fields in the following files to the common password as well: bacula-sd.conf, bacula-fd.conf, bconsole.conf, gnome-console.conf and tray-monitor.conf. After changing the passwords, you also need to change any references to your host in all the .conf files, so each dæmon can communicate with each other. If all of the dæmons run locally, you can use localhost. You also could use an FQDN or IP address. The field you want to edit is listed under each section as Address. So, for example, change the line:

Address = server.example.com

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Tape Sets

zied's picture

Hi,

I followed this article with great interest, it's really instructive.

I implemented the same "algorithm" but with tapes.

I'm confused about how many do I need, and when to change ??

can you help please ?

kind regards,
Zied.

Share what you learn what you don't

ahhhhhh!

uslacker's picture

Did he really tell us to change all the passwords to a default so we can get the system up and running? Then go back later....

Isn't this how we got ourselves in to the security quagmire we've been trying to get out of for years? Too many simple passwords or "we'll do it later.." has left back doors the size of trucks in our networks.
Please, teach us better than this!

\\uSlacker

\\uSlacker

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState