Bacula setup: why backups fail to restore
Bacula setup is designed in such a way that a job completing successfully guarantees nothing. The Director receives a data-send report from the Client, writes an entry to the catalog — and the job closes with the status "completed".
But if the wrong media ended up in the volume pool, and the retention policy has already moved it to overwrite status, recovery will hit a void: the needed data is physically absent from the tape or the storage.
Bacula configuration errors almost always surface not at the moment a copy is created, but at the moment of a failure — when a rollback is needed urgently.
The classic source of problems is a desync between the Bacula Director and the Client.
The include file on the Client describes one set of paths, while the job on the Director describes another; meanwhile the catalog stores metadata that does not match the actual contents of the volume.
The second common case is backup levels: the full-incremental-differential chain breaks if one of the intermediate volumes drops out, and the differential copy references a base set that no longer exists.
Then "the backup fails to restore" is not a media failure but a logical hole in the chain.
A separate category is permissions and environment. The agent runs under a service account that lacks access to some of the directories, and the job formally succeeds while skipping those paths.
The same goes for exclusions: a mask added "temporarily" stays in the configuration and quietly cuts data out of every copy.
That is why verifying backups must be a regular procedure rather than a one-off action: a test restore to a separate node, checksum comparison, and chain-completeness control via the catalog.
We break down how to build your Bacula setup so that a copy is guaranteed to come up at the moment of a failure.
What a well-structured backup system provides
A well-established backup policy changes not the "presence of copies" but the behavior of the infrastructure during a failure.
Recovery time stops depending on who is on duty and whether they remember the sequence of steps: the recovery scenario is documented, tested on a training environment, and takes predictable minutes instead of hours of improvisation.
Storage volume stops growing uncontrollably.
Scheduled full copies, incremental copies between them, and a retention policy with generational rotation provide a clear history depth: recent points are at hand, old ones are retired according to policy rather than by remaining disk space.
Data integrity is confirmed by checks — checksums, test recovery of individual files and databases, reconciliation of the catalog with the actual contents of the storage.
A separate effect is that the class of failures related to human error disappears. Backup tasks run on schedule rather than "when someone remembered"; access to the catalog and storage is segregated, and deleting copies requires a separate action and is logged.
A single engineer's mistake no longer means a lost backup window: the system reports a task failure instead of staying silent until the moment a copy is needed.
A backup policy defines what is copied, at what frequency, where it is stored, and how it is verified — this turns backup from a set of scripts into a managed process with measurable indicators: recovery time, retention depth, share of successful tasks, and results of integrity checks.
Comparison of approaches: full, incremental, and differential
In Bacula, the job type determines not the "completeness" of the copy, but how much data will have to be re-read and transferred within the backup window.
A full backup reads the entire file set, an incremental one reads only what has changed since any previous job, and a differential one reads everything that has changed since the last full backup.
This is where the difference in load comes from: the more frequent the full run, the more predictable the recovery, but the more expensive each window.
In practice, a retention strategy is assembled from a combination of levels rather than choosing just one. Below is how these three modes behave in terms of resources and what limits their use.
| Option | When it fits | Limitations |
|---|---|---|
| Full backup | Baseline level for the chain; critical sets with a short retention period | Maximum load on disk and network, requires a wide backup window |
| Incremental | Daily runs of large sets where a small share of files changes | Recovery requires the entire chain from full to the required level — time and the number of tape accesses grow |
| Differential | A compromise: daily, but with fast recovery | The volume grows every day until the next full; headroom for space is needed |
The key parameter is the depth of the chain. The longer the series of incrementals, the more links must be read during recovery and the higher the risk that one corrupted link will bring down the entire chain. A differential backup shortens this depth to two steps, but pays for it with growing volume.
That is why a retention strategy is defined through a schedule of levels and a retention policy: for example, a weekly full, a daily differential, and a periodic incremental for sets with a high change rate. The backup window is planned so that the full run does not overlap with peak load on services.
Implementation stages: from audit to handover to operation
Backup implementation begins not with installing packages, but with an inventory: which servers, which databases, what volume of changes per day, what load windows are acceptable.
At this stage we fix the target metrics — the recovery point and recovery time for each system separately, because a file server and a database cluster require different policies.
- Infrastructure audit. We compile a map of systems, data volumes, their growth rate, current backup methods and their weak points. We check the network and storage: the throughput between the client and the director determines whether the nightly copy will fit into the window.
- Schema design. We define the roles of director, storage daemon and file daemon, distribute them across servers, choose volume pools and retention policies. We coordinate the schedule of full and incremental copies taking into account the load on the sources.
- Bacula configuration. We configure the catalog, pools, schedules and jobs, connect clients, set up channel encryption and deduplication. Separately, we define the retention policy: how many full copies we keep, when volumes are overwritten.
- Restore test. We restore data to an isolated test bench — first individual files, then an entire system as a whole. We measure the actual time and compare it with the target metrics; a discrepancy is a reason to rebuild the schedule or add storage.
- Monitoring and alerts. We set up alerts about job status, errors and volume usage, so that a backup failure is not discovered at the moment when the data is already needed.
- Documentation. We describe the schema, schedules, pools and the procedure for recovery — so that the on-duty engineer can bring up the data without the person who set it up.
- Training and handover. We conduct a walkthrough with your team: how to read reports, how to start a restore, what to do in case of a failure. We hand the system over to operation with a clear regulation.
What the client receives after the work is completed
Once the work is handed over, you are left not with a "configured server" but with a complete package that any administrator — yours or a contractor's — can use to maintain backups without us.
Everything we do in the configuration is documented and handed over together with the access credentials.
- Configuration files for Director, Storage, and File Daemon with comments: which directories are included in the jobs, why caches and temporary data are excluded, and how a new client was added.
- Backup scheme: what is backed up and how often, where full and incremental backups alternate, and how jobs are distributed across low-load windows.
- Retention policies: how many versions and generations are stored on each medium, when a record is moved to archive and deleted, and how volume rotation is configured.
- Recovery procedure: a step-by-step sequence of actions for the loss of a file, a directory, or an entire server — from selecting the required copy to verifying data integrity after deployment.
- Administrator's guide: typical operations — adding a client, running an unscheduled backup, checking job status, and troubleshooting a failed job using the log.
- Configured monitoring: alerts for failed jobs and full media, so that a problem surfaces before recovery is needed.
- Acceptance test report: a control recovery from a backup with recorded time and result — proof that the backups are actually readable.
The package is designed to be handed over: configurations are kept in a version control system, and documents are in your knowledge base. If an administrator leaves, a new engineer is onboarded using these materials, not the previous person's memory.
Case study: reducing recovery time by three times
A client came to us with a classic pain point: backups exist, but you can't restore from them.
Nightly jobs failed halfway through, the operator sifted through logs manually, and an incident involving database loss stretched into hours of downtime — the business lost orders while engineers searched for the right volume on the tape library.
We started with an audit: we checked what actually makes it into the archive and what is silently skipped due to configuration errors.
What it was before
The Bacula catalog stored jobs that no one verified against the actual state of the files. Some incrementals couldn't find the previous full backup and failed, but this was only discovered when attempting a restore.
The average time to return data to a working state was about six hours, most of which went to manually searching for the right version and checking integrity.
What we changed
We rebuilt the schedule: a full backup once a week, incrementals daily, a separate retention policy for critical databases.
We set up automatic verification of every job — if the archive isn't created or is corrupted, the system immediately alerts the on-call engineer instead of waiting for an incident.
We added regular test restores to a separate staging environment: once a month we deploy a copy and verify the checksums.
What it became
Recovery time dropped from six hours to two, and typical scenarios — restoring a file or a table — are handled in minutes without human involvement. Manual log sifting is gone: the engineer sees the job status and the recovery point in a single panel.
Over six months, not a single incident led to data loss, and the share of successful jobs grew from 82% to 99%.
Reliability here is not an abstraction but a measurable quantity: how many jobs run to completion, how quickly data is restored, how many manual operations remain. Describe your task — we'll come back with an estimate and a plan.
How Bacula differs from Bareos and which one to choose
Bareos is a fork of Bacula that split off at the turn of major versions. The fork carried over a compatible catalog format and largely the same set of daemons, so at the level of configuration and storage structure the systems look almost identical.
The difference shows up further on: in the pace of development, support for new platforms, and how actively the project closes vulnerabilities and releases fixes.
Bacula is a mature system with a long history and a large volume of documentation, but development moves more slowly, and some improvements arrive with a delay.
Bareos develops more actively: releases come out more often, support for modern distributions and cloud storage is broader, ready-made packages are available, and the update cycle is more predictable. For infrastructure that lives for years, this means a lower risk of hitting an unsupported branch.
Compatibility during migration is the key practical question.
The Bareos catalog is historically compatible with the Bacula format, so migration is usually done by transferring the catalog and adapting the configuration: resource names and the structure of directives are close, but not identical.
Some parameters have been renamed or changed, so the configuration is transferred not by copying but by rebuilding it with verification on a test bench. Reverse migration is more difficult: changes in the catalog schema may not roll back to the older version.
The choice depends on the scenario. If a system is already running on Bacula and is stable, there is no need to rush the transition — first assess whether it is hitting the absence of needed features.
If new infrastructure is being built or fresh platforms and regular updates are required, Bareos offers a more predictable support horizon. In both cases, we first set up a test bench, transfer the catalog, and verify recovery, and only then touch the production system.
Common technical concerns when setting up backup
Before agreeing on the architecture, customers usually check a few places where backup most often breaks down in practice: nighttime load on production servers, encryption of data off-site, deduplication, and trust in the copies. Below is a substantive breakdown of each concern.
Won't backup take down prod during peak hours?
The load is managed through scheduling and parallelism: jobs are spread across low-activity windows, the number of concurrent streams is limited, and for databases a snapshot mode or a preliminary dump is used so that files are not read while being written.
Incremental jobs read only changed blocks, so the backup window is reduced severalfold. If necessary, bandwidth is throttled at the job level — production gets priority for disk and network.
How is data protected when copies are moved off-site?
Copies are encrypted on the client side before being sent to external storage — the keys stay with you, not with the provider. Off-site storage is built according to the 3-2-1 rule: working data, a local copy for fast recovery, and an off-site copy in case the entire site fails.
Transfer goes over a secure channel, and access to the storage is restricted to a separate account with write-only permissions.
Doesn't deduplication interfere with recovery and doesn't it save at the expense of reliability?
Deduplication removes duplicate blocks between jobs and versions, so storage volume stops growing linearly with the number of copies.
Importantly, it does not replace recovery testing: retention policies and version chains are configured so that rolling back to the required point remains possible. Saving on volume is a consequence, not a goal.
How can you be sure that a copy will actually restore?
Integrity is checked automatically after each job, and once per agreed period a test restore is performed to a separate staging environment — this is the only way to catch a broken chain before a failure.
A report on the checks and the results of test restores is recorded, so that you have a history rather than a promise.
Describe your infrastructure and storage requirements — we will come back with an assessment and a setup plan.
Let's discuss your backup task
To come back with an estimate and an implementation plan rather than generalities, we need to understand your infrastructure: how many servers and which OSes, where the data is stored — local disks, storage systems, virtual machines — how much space a full copy takes and how fast it grows.
Separately, it's important to know what is already used for backup and whether there are requirements to store copies off-site.
Next, we clarify the target metrics: the acceptable service downtime window during copying, retention depth, frequency of full and incremental copies, and the procedure for restoring individual files and entire systems.
From this, the architecture takes shape: where the catalog, storage devices, and agents are located, and how the schedule and retention policies are configured.
With these inputs, we prepare a work estimate and a phased implementation plan — from designing the scheme to going live and testing restoration.
- Analysis of the current infrastructure and data growth points
- Backup scheme with schedule and retention policies
- Estimate of storage volume for copies and a plan for its expansion
- Phased implementation plan with roles and timelines
- Restoration testing procedure and incident response regulations
- Engineer consultation on contentious points in your scheme
Describe the task — the number of servers, volumes, and storage requirements. We'll come back with a work estimate and an implementation plan you can use to launch backup.