This article covers a version of Ubuntu that is no longer supported. If you are currently operate a server running Ubuntu 12.04, we highly recommend upgrading or migrating to a supported version of Ubuntu:
Reason: Ubuntu 12.04 reached end of life (EOL) on April 28, 2017 and no longer receives security patches or updates. This guide is no longer maintained.
See Instead:
This guide might still be useful as a reference, but may not work on other Ubuntu releases. If available, we strongly recommend using a guide written for the version of Ubuntu you are using. You can use the search functionality at the top of the page to find a more recent version.
The lines that the user needs to enter or customize will be in red in this tutorial! The rest should mostly be copy-and-pastable.
Bacula is a sophisticated backup solution that can handle local and remote backups by leveraging a client-server model. It has very flexible configuration options that provide complete control over the backup environment.
In this guide, we will be setting up a remote backup involving a backup cloud server and a client machine that will be completely backed up.
You will need two separate server instances. The first server must be set up according to the configuration outlined in the Installing and Configuring Bacula on an Ubuntu 12.04 VPS guide. The second server will be another Ubuntu 12.04 machine.
For the purposes of this guide, the backup VPS has a hostname of BackupServer and the client machine's host name is ClientMachine. Change these values to reflect the server names of the machines you are using.
No local backups will be stored on the remote client machine, so not all of the bacula components need to be installed.
Install the the bacula-fd (file-daemon) and the bconsole (bacula console) on this machine with apt-get using the bacula-client metapackage:
sudo apt-get update sudo apt-get install bacula-client
The necessary components are now installed and ready to be configured.
The configuration of the client environment is relatively straightforward. We will only be editing the bacula file daemon configuration file. Open the file with root privileges with the following command:
sudo nano /etc/bacula/bacula-fd.conf
We need to change a few items and save some information that we will need for our server configuration. Begin by finding the Director section.
The bacula director is located on the backup VPS. Change the "Name" parameter to the hostname of your backup server followed by "-dir".
You also need to copy the password that bacula generated for your client file daemon to some place that you'll have available when you are configuring your backup server settings:
Director { Name = BackupServer-dir Password = "u2LK-yBrQzfiEsc6NWftHEhymmdPWsklN" # Copy this password for later reference! }
Next, we need to adjust one parameter in the FileDaemon section. We will change the "FDAddress" parameter to match the IP address or domain name of our client machine. The "Name" parameter should already be populated correctly with the client file daemon name:
FileDaemon { # this is me Name = ClientMachine-fd FDport = 9102 # where we listen for the director WorkingDirectory = /var/lib/bacula Pid Directory = /var/run/bacula Maximum Concurrent Jobs = 20 FDAddress = ClientMachine.DomainName.com }
We also need to configure this daemon to pass its log messages to the backup cloud server. Find the Messages section and change the "director" parameter to match your backup cloud server's name.
Messages {
Name = Standard
director = BackupServer-dir = all, !skipped, !restored
}
Save the file and exit.
Check that your configuration file has the correct syntax with the following command:
sudo bacula-fd /etc/bacula/bacula-fd.conf
If the command returns no output, the configuration file has valid syntax. Restart the file daemon to use the new settings:
sudo service bacula-fd restart
The client machine is now correctly configured.
In this example, we would like to restore to a folder on this same machine. Create the file structure and lock down the permissions and ownership for security with the following commands:
sudo mkdir -p /bacula/restore sudo chown -R bacula:bacula /bacula sudo chmod -R 700 /bacula
The client machine is now configured correctly. Next, we will configure the backup cloud server to pull the file data from the client.
Log into the backup cloud server to complete this stage of the configuration.
The bulk of the configuration is actually done on the backup server. That is because the bacula "director" manages all other bacula processes and must be able to communicate correctly with a number of different components.
To start, open the "bacula-dir.conf" file with administrator privileges:
sudo nano /etc/bacula/bacula-dir.conf
Begin by finding the Job Section. The current configuration is named "BackupClient1" and is used for the backup server's local backup. We need to change the name to reflect this:
Job {
Name = "LocalBackup"
JobDefs = "DefaultJob"
}
Now that we have identified the first job as backing up on the local machine, we want to create a similar job for backup up our remote client. To do this, copy and paste the job definition below the one you just modified.
Change the name to reflect the fact that this is a remote backup scenario. The "Client" parameter identifies our remote client file daemon as the target for our backup. The Pool parameter allows bacula to store its remote backups separate from our local backups. We will define the pool we're referencing later in the file:
Job { Name = "RemoteBackup" JobDefs = "DefaultJob" Client = ClientMachine-fd Pool = RemoteFile }
Next, define a place for the remote backups to restore. We will use the directory that we created on the client machine to restore remote backups.
Find the "RestoreFiles" job definition. Copy the current entry and paste it below. We will then modify some entries to label it accurately and work with client machine:
Job { Name = "RestoreRemote" Type = Restore Client=ClientMachine-fd FileSet="Full Set" Storage = File Pool = Default Messages = Standard Where = /bacula/restore }
Find the Client definition. We will change the "Address" parameter to reflect our actual backup cloud server IP address instead of using localhost. The password should already be set correctly for the local machine.
Client { Name = BackupServer-fd Address = BackupServer.DomainName.com FDPort = 9102 Catalog = MyCatalog Password = "CRQF7PW-mJumFtENX2lqGvJ6gixPTyRQp" # password for Local FileDaemon File Retention = 30 days # 30 days Job Retention = 6 months # six months AutoPrune = yes # Prune expired Jobs/Files }
The next step is to actually define the client machine that we've been referencing in our configuration. Copy the Client entry we just modified paste it below the current definition. This new definition will be for the remote machine that we are backing up.
Match the name to your client machine's hostname followed by "-fd". The "Address" line needs to match the client machine's IP address or domain name as well.
Finally, this is where you enter the password that you copied from the remote client's file daemon configuration file. Make sure that you modify this password value, or else bacula will not function correctly.
Client { Name = ClientMachine-fd Address = ClientMachine.DomainName.com FDPort = 9102 Catalog = MyCatalog Password = "u2LK-yBrQzfiEsc6NWftHEhymmdPWsklN" # password for Remote FileDaemon File Retention = 30 days # 30 days Job Retention = 6 months # six months AutoPrune = yes # Prune expired Jobs/Files }
Next, change the "Address" parameter in the Storage section with the IP address or domain name of the backup VPS. Once again, the password should already be correct here:
Storage { Name = File # Do not use "localhost" here Address = BackupServer.DomainName.com # N.B. Use a fully qualified name here SDPort = 9103 Password = "097dnj3jw1Yynpz2AC38luKjy5QTnGoxS" Device = FileStorage Media Type = File }
Find the Pool definitions section. We will first add a parameter to the "File" pool definition. Add the "Label Format" parameter to the definition and choose a prefix to name local file backups. For this guide, local backups will have "Local-" as a prefix.
Pool {
Name = File
Pool Type = Backup
Recycle = yes # Bacula can automatically recycle Volumes
Label Format = Local-
AutoPrune = yes # Prune expired volumes
Volume Retention = 365 days # one year
Maximum Volume Bytes = 50G # Limit Volume size to something reasonable
Maximum Volumes = 100 # Limit number of Volumes in Pool
}
Next, we need to copy the section we just modified and paste it below the current entry. This will be set up for remote backup storage.
Change the name of the new pool to reflect its job of storing remote backups. Also, change the prefix by adjusting the "Label Format" parameter to be "Remote-"
Pool { Name = RemoteFile Pool Type = Backup Recycle = yes # Bacula can automatically recycle Volumes Label Format = Remote- AutoPrune = yes # Prune expired volumes Volume Retention = 365 days # one year Maximum Volume Bytes = 50G # Limit Volume size to something reasonable Maximum Volumes = 100 # Limit number of Volumes in Pool }
Save and close the file.
Next, open the "bacula-sd.conf" file with root privileges:
sudo nano /etc/bacula/bacula-sd.conf
Change the "SDAddress" parameter to reflect the backup server's IP address or domain name:
Storage { # definition of myself
Name = BackupServer-sd
SDPort = 9103 # Director's port
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
Maximum Concurrent Jobs = 20
SDAddress = BackupServer.DomainName.com
}
Save and close the file.
Check the configuration with the following commands:
sudo bacula-dir /etc/bacula/bacula-dir.conf sudo bacula-sd /etc/bacula/bacula-sd.conf
If no output is returned, the configuration files have valid syntax. If this is the case, restart the daemons to use the new settings:
sudo service bacula-director restart sudo service bacula-sd restart
Log into the bacula console to test the backup functionality.
sudo bconsole
Test that the bacula director can connect to the remote machine by typing the following:
status
Status available for: 1: Director 2: Storage 3: Client 4: All Select daemon type for status (1-4):
Choose #3 to check on the client connection and then select the remote machine:
3: Client
2: ClientMachine-fd
It should return a summary with some statistics, confirming that we can connect to the remote file daemon.
Run a test backup of the remote system by typing the following command:
run
Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" A job name must be specified. The defined Job resources are: 1: LocalBackup 2: RemoteBackup 3: BackupCatalog 4: RestoreFiles 5: RestoreRemote Select Job resource (1-5):
Select the "RemoteBackup" option to run a backup of the remote machine. Type "yes" to begin the backup:
2: RemoteBackup
The director will send the backup task to the remote file daemon and which will pass its information to the backup server's storage daemon. You can check the status of the job using the "status" command as we did above. You should also check the messages using the "messages" command.
messages
If you continue to check messages, eventually you will receive a summary of the backup operation. It should contain the line "Termination: Backup OK" if everything went as expected.
Now, test the restore functionality:
restore all
Choose the "Select the most recent backup for a client" option. Select the remote client that we have just backed up:
5: Select the most recent backup for a client
2: ClientMachine-fd
You will be dropped into a file tree where you are able to select the files you would like to restore with the "mark" and "unmark" commands.
We have chosen to restore everything, so we can just type "done" to move on. Select the job that we defined for remote restoration and type "yes" to run the restoration:
done
2: RestoreRemote
Again, you can check the restoration with the "status" and "messages" commands. You should eventually get a summary in the messages that contains the line "Termination: Restore OK". This means the restoration was successful. Type "exit" to leave the bacula console.
exit
We can check that our remote backup file has the correct file format with the following command:
sudo ls /bacula/backup
LocalBackup Remote-0002
As you can see, our backup file for the remote system has adapted the naming conventions we supplied. The local backup is not named according to our convention because it is from before our changes.
If we log into our remote client machine, we can check our restore with the following line:
sudo ls /bacula/restore
bin dev home lib media opt run selinux sys var boot etc initrd.img lost+found mnt root sbin srv usr vmlinuz
As you can see, we have restored the filesystem to this folder correctly.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
Bacula is sophisticated backup solution that can be used to back up servers over a network. In this series, we will cover how to install and configure Bacula on Ubuntu 12.04 servers. We will then demonstrate how to configure remote backups in order to set up a system to keep safe copies of any computer in your infrastructure.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
This tutorial is nice but needs 2 major additions.
In bacula-sd.conf: Device { Name = FileStorage Media Type = File
Archive Device = /nonexistant/path/to/file/archive/dir
Archive Device = <Should be specified> eg/ home/robert/bacula_dest
And bacula_dest should have the right permissions. sudo chown -R bacula:bacula /home/robert/bacula_dest sudo chmod -R 700 /home/robert/bacula_dest
List of files to be backed up FileSet { Name = “Full Set” Include { Options { signature = MD5 }
Put your list of files here, preceded by ‘File =’, one per line
or include an external list with:
File = <file-name
Note: / backs up everything on the root partition.
if you have other partitions such as /usr or /home
you will probably want to add them too.
By default this is defined to point to the Bacula binary
directory to give a reasonable FileSet to backup to
disk storage during initial testing.
}
Everything working well except for the last part : Checking the Filesystem. Seems like it only backed and restore the /usr directory. What’s wrong? Also, is this automated backed? When does it run? How can I configure that? Thanks
@bphillips: Does 192.168.1.106 have a firewall installed? Is port 9102 open?
I am having some issues testing the remote connection. I get “connecting to client ubuntu-fd at 192.168.1.106:9102. Failed to connect to Client ubuntu-fd.”
*status Status available for: 1: Director 2: Storage 3: Client 4: All Select daemon type for status (1-4): 3 The defined Client resources are: 1: home-server-fd 2: ubuntu-fd Select Client (File daemon) resource (1-2): 2 Connecting to Client ubuntu-fd at 192.168.1.106:9102 Failed to connect to Client ubuntu-fd.
I know that’s the correct address. Is there any easy way to figure out my connection problem? I’m no expert, but I followed the steps perfectly.
Thanks, Brad
@isirguezglez: You have a configuration/syntax error in <pre>/etc/bacula/bacula-fd.conf </pre>
Did you follow the article correctly?
??? I thought that i could use markdown. Let’s see if I try HTML <pre>test</pre>
<pre> echo “hello world” echo “this is a test” </pre>
Hi!!
When i was configuring the clien I got this error when I use
bacula-fd bacula-fd.conf