🦇Bacula - Install & configure (Part-2)🦇#
1303 words | 17 min read
We configured the Bacula Director, Storage Daemon and the Disk autochanger (vchanger) in the previous article.
Now, we will configure the clients to backup the data to the USB disk. We will also configure the Director to run the backups on scheduled days/times, and also specify the directories/files that should be backed up, as well as the ones to be excluded.
1. Configure the File Daemon#
The File Daemon is also known as the client. The File daemon needs to be installed on every computer that needs to be backed up.
On server01, the daemon will be called server01-fd and the /etc/bacula/bacula-fd.conf should already be configured correctly. But if any changes are needed, you can make them. In our case, we are going to leave it as-is.
2. Configure the Bacula Director#
Again, the /etc/bacula/bacula-dir.conf on server01 should be mostly correct. We will, however, update a few parts of the file to get it working the way we want.
2.1. The “Client” section#
Locate the “Client” section for server01-fd (remember, the file daemon is the client). If you have enough disk space, you can leave the retention period at the default settings. Otherwise, reduce the File Retention and Job Retention to smaller values. I am using “30 days” and “3 months” in my example below.
Additionally, define a “fake” client too, for later use, when you need to satisfy syntactic requirements.
# Client (File Services) to backup
Client {
Name = server01-fd
Address = localhost
FDPort = 9102
Catalog = MyCatalog
Password = "SImNMIe-t3SGyBMvJ3NGZqnvxFsNukxoS" # password for FileDaemon
File Retention = 30 days # 30 days
Job Retention = 3 months # three months
AutoPrune = yes # Prune expired Jobs/Files
}
# Client (File Services) to backup
#
# Fake client
#
Client {
Name = None
Address = localhost
Password = "bZZ0cMAfE5Vg/Nt5SLkxLHCWSphpiOg7b" # Console password
Catalog = MyCatalog
}
2.2. The “JobDefs” section#
Define a new JobDefs section for the weekly backup that we are setting up. I prefer to leave the “DefaultJob” unchanged, and unused.
Copy the “DefaultJob” JobDef section to a new one right below it, and edit it to look as shown below.
JobDefs {
Name = "WeeklyBackupJob"
Type = Backup
Level = full
Client = server01-fd
FileSet = "Full Set"
Schedule = "MyWeeklyCycle"
Storage = vchanger0
Messages = Standard
Pool = vchanger0-pool
SpoolAttributes = yes
Priority = 10
Write Bootstrap = "/var/lib/bacula/%c.bsr"
}
2.3. Define Jobs#
Next, we will define 2 jobs
A job to update the slots in the virtual autochanger: This also spins up the USB disk from idle, and reduces errors. Depending on your USB disk and how it’s set up, you may not need this one.
The actual job to backup server01
# Update Slots
Job {
Name = "UpdateSlots"
Type = Admin
# Client = None
# FileSet = None
Schedule = "MyWeeklyCycle"
Storage = vchanger0
Messages = Standard
Pool = File
Priority = 8
RunScript {
RunsWhen = Before
RunsOnClient = no
Fail Job On Error = no
Console = "update slots storage=vchanger0 drive=0"
}
}
# Backup This Computer
Job {
Name = "Daily server01"
JobDefs = "WeeklyBackupJob"
}
Note
We are setting the priority for the “UpdateSlots” job to be a smaller number than other backup jobs, so that it runs first.
The “UpdateSlots” runs on the same schedule as the other backup jobs.
2.4. Define the Schedule for the backup#
2.4.1. Understanding the various backup levels#
In the previous sections, we used the “MyWeeklyCycle” schedule. Now, we need to define it in order for the correct backup (Full/Differential/Incremental) to run on the correct day at the correct time.
And here, we need to be clear about what each backup level (or type) type is.
Full backup: This is pretty self-explanatory. It will backup all the files that you specify
Incremental backup: This will backup files created/modified since the last backup
Differential backup: This will backup files created/modified since the last Full backup
The diagram below should help clarify the difference between these backup types
In this example setup, we will configure Full backups every Sunday, and Differential backups on all other days of the week.
The tradeoff of this setup is that, only 2 backups (at most) will be needed to recover any lost files. But, each differential backup will be bigger than an incremental backup.
To illustrate this, consider the diagram above again. If the disk crashed (or files were accidentally deleted on a Thursday afternoon), the recovery steps would be:
With Incremental Backup:
Restore the Full Backup
Restore Incremental Backup From Monday
Restore Incremental Backup From Tuesday
Restore Incremental Backup From Wednesday
With Differential Backup:
Restore the Full Backup
Restore Differential Backup From Wednesday
The number of recovery steps is smaller. But each (differential) backup will be bigger.
I prefer fewer steps for recovery (especially when I’m under stress from losing a disk or data). I also have enough disk space to accommodate daily differential backups, but probably not daily full backups.
If your preference/circumstance is different - feel free to configure incremental backups (or even full backups every day!)
2.4.2. Define the backup schedule#
In the bacula-dir.conf, find existing schedule definitions and add a section similar to eh one below:
Schedule {
Name = "MyWeeklyCycle"
Run = Level=Full sun at 00:01
Run = Level=Differential mon-sat at 00:01
}
We are scheduling the backups to run immediately after midnight each day. But you can change the timing (and the backup level) for each day, if you so prefer. You can also define different schedules for different computers (e.g. a laptop that’s going to be turned on only between 8 AM and 5 PM on weekdays).
2.5. Define the FileSet#
The FileSet resource in Bacula, as the name implies, defines the set of files that should be included in (or excluded from) the backup.
2.5.1. Define a fake FileSet#
Find exiting FileSet definitions in bacula-dir.conf and add a fake FileSet definition below one of the existing FileSets
# List of files to be backed up
#
# Fake fileset
#
Fileset {
Name = None
Include {
Options {
signature = MD5
}
}
}
2.5.2. Modify the FileSet to be used for the backup#
In our case, we are using a JobDef with the “Full Set” FileSet refernced. This can be overridden as desired, but for now, let’s find the “Full Set” FileSet definition and include the root directory to backup. And we will remove the “nonexistant” directory from the exclude list. The “Full Set” FileSet should resemble the one below.
# List of files to be backed up
FileSet {
Name = "Full Set"
Include {
Options {
signature = MD5
}
File = /
}
#
# If you backup the root directory, the following two excluded
# files can be useful
#
Exclude {
File = /var/lib/bacula
File = /proc
File = /tmp
File = /sys
File = /.journal
File = /.fsck
}
}
3. Verify the configuration#
sudo bacula-fd -t
sudo bacula-dir -t
4. Restart the Bacula Daemons#
sudo systemctl restart bacula-dir
So far, in this post, we looked at the File Daemon (client) which was already configured suitably for our purposes.
Then, we updated the bacula-dir.conf to add various section (Client, JobDefs, Job, Schedule and FileSet). We also verified the configurations and restarted the Bacula Director (and any other daemons whose configuration was modified).
Your bacula-dir.conf file should now resemble this.
Now, you are ready to run your first backup and enjoy the fruits of all this labor (Yay!).
5. Backup the Bacula Server#
For testing, we are going to run the backup manually from the Bacula Console (bconsole).
sudo bconsole
You should see messages about connecting to the director, and finally a prompt to enter a command
Connecting to Director localhost:9101
1000 OK: 103 server01-dir Version: 9.6.7 (10 December 2020)
Enter a period to cancel a command.
*
The Bacula Console has a lot of options that you can read about and explore. For now, we will type “run” (to run a job) and hit “enter”.
This should bring up a list of configured jobs - and among them, our “Daily server01” job.
Connecting to Director localhost:9101
1000 OK: 103 server01-dir Version: 9.6.7 (10 December 2020)
Enter a period to cancel a command.
run
You should see output similar to this:
Connecting to Director localhost:9101
1000 OK: 103 server01-dir Version: 9.6.7 (10 December 2020)
Enter a period to cancel a command.
*run
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
A job name must be specified.
The defined Job resources are:
1: BackupClient1
2: BackupCatalog
3: RestoreFiles
4: UpdateSlots
5: Daily server01
Select Job resource (1-5):
Next, choose the job number that you want to run (in our case, 5). And then, type “yes” (the full word - not just “y”)
You should see a message bout the job being queued. You should be back at the bconsole prompt.
6. Monitor the backup job#
At the bconsole prompt, you can type “status dir” to see the status of the job. With luck, it should be in a “running” state. And after several minutes, it should finish (terminate) with a status “OK”.
status dir
You should see output with a section showing the running job:
Running Jobs:
Console connected at DD-MMM-YY HH:MM
JobId Type Level Files Bytes Name Status
======================================================================
12 Back Full 6,794 630.9 M Daily server01 is running
====
7. Check the backup media#
Remember we set up vchanger to create a set of vitual tapes? Let us use bconsole to check the status of these tapes now and check which ones are full, in use etc.
status slots storage=vchanger0 drive=0
You should see output similar to the one below
*status slots storage=vchanger0 drive=0
Connecting to Storage daemon vchanger0 at localhost:9103 ...
3306 Issuing autochanger "slots" command.
Device "usb-vchanger0" has 10 slots.
Connecting to Storage daemon vchanger0 at localhost:9103 ...
3306 Issuing autochanger "list" command.
+------+----------------------+-----------+-----------------+--------------------+
| Slot | Volume Name | Status | Media Type | Pool |
+------+----------------------+-----------+-----------------+--------------------+
+------+----------------------+-----------+-----------------+--------------------+
| 1 | vchanger0_0000_0000 | Append | File | vchanger0-pool |
+------+----------------------+-----------+-----------------+--------------------+
| 2 | vchanger0_0000_0001 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 3 | vchanger0_0000_0002 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 4 | vchanger0_0000_0003 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 5 | vchanger0_0000_0004 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 6 | vchanger0_0000_0005 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 7 | vchanger0_0000_0006 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 8 | vchanger0_0000_0007 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 9 | vchanger0_0000_0008 | Append | File | Scratch |
+------+----------------------+-----------+-----------------+--------------------+
| 10 | vchanger0_0000_0009 | Append | File | Scratch |
*
Note that the volume “vchanger0_0000_0000” is in the “vchanger0-pool” and is being appended to. When this volume becomes full, Bacula - using vchanger - will automatically switch to the next one and so on.
We want to try and have enough free volumes available until the “File Retention” period (30 days in our case) passes. In such a case, Bacula will cycle back and reuse one of the previous volumes (since it’s past the retention policy). If all volumes become full within 30 days - you will need to set up a new disk and configure it. Otherwise, your backups won’t run.
You can type “q” at the bconsole prompt to quit bconsole. If any backup jobs are running, they will continue to do so.
In the next post, we will look at configuring the bacula client on our other computers - db01 and ws01, as well as configuring the Director to back up these additional computers too. These steps should be relatively quick, from this point onwards.
Comments
Comments powered by giscus, use a GitHub account to comment.