Bacula: immutable backup that survives ransomware, flat pricing

Your backup is no longer the last line of defence. It's the first victim.

In late March, Bacula Systems themselves published two articles that capture where this conversation sits today. One explains why backup infrastructure is a more valuable target to attackers than domain admin accounts, and the other lays out why Zero Trust breaks down at the backup layer. None of this is news to incident responders who've been saying the same thing for a couple of years. But seeing it documented in writing changes boardroom conversations that used to be impossible.

When clients call us to help clean up an incident, the pattern they describe is almost always the same, with small variations:

Look at that timeline for a second. Attackers spend more days neutralising the backup than actually running the encryption. It's not a mistake on their part. They know that if the backup survives, the victim doesn't pay, and then the whole attack loses its business case. It's cold criminal accounting.

This is why "do we have backups?" stopped being a useful answer to anything. The question you actually need to ask is uncomfortable: would those backups still be there if an attacker already had admin credentials inside your network? If you need to think about it, the honest answer is probably no.

What "immutable backup" actually means

Quick heads up: "immutable backup" has become marketing wallpaper. Pretty much every vendor claims to have it, and most of them mean wildly different things by it. So let's be precise about what we're talking about.

A backup is genuinely immutable when, once it's been written, nobody can modify or delete it before its retention expires. Nobody. Not the user who created it. Not your DBA with valid credentials. Not your own root account. And crucially, not an attacker who's already compromised the backup server itself. If any of those people can destroy the copy, the copy isn't immutable. It's a regular backup wearing a fancy label.

To get that guarantee in practice, there are three serious approaches, and Bacula supports all three:

The rule a lot of CISOs have been quietly adopting is called 3-2-1-1-0. You've probably come across it if you've been in the conversation recently: three copies, two different media, one offsite, one immutable, and zero errors in verification. That "1-0" is what changed from the classic 3-2-1 we all grew up with. Having copies isn't enough anymore — they need to be unalterable, and they need to be verified automatically without anyone having to remember to check. And here's the thing: Bacula does both as part of its normal operating cycle. It's not a premium add-on you license separately.

Why Bacula is such a good fit for this

Bacula has been protecting data for more than twenty years in banks, government agencies, hospitals, telcos and scientific data centres at petabyte scale. It's probably the most mature open source enterprise backup software out there, and we're not the ones saying it — the installs that have been running since the early 2000s say it, and so do the vendor's customers who've been trusting it with critical data for two decades. The current commercial flagship is Bacula Enterprise 18.0.8, and it brings things that would have sounded like science fiction five years ago: BGuardian for catalog poisoning detection, a security dashboard in BWeb, native support for Microsoft 365 and Azure, a Nutanix AHV plugin, CSI snapshots for Kubernetes.

But the real reason Bacula holds up so well against modern ransomware isn't the new plugins. It's a set of design decisions the project made twenty years ago that, as it turns out, have aged very well:

• Distributed by design. Director, catalog, storage daemons and clients are all separate processes. They can live on different hosts, with different credentials, on different network segments. Compromising one of them doesn't hand you the others — nowhere close.
• Catalog in a real database. PostgreSQL or MySQL with their own backups, their own access controls, their own audit trails. You can replicate it, put it behind its own firewall, treat it as the critical asset it actually is. It's not some binary file sitting in /var.
• Automated content verification. Bacula periodically re-reads volumes and compares checksums. If something's been tampered with — by a human, by a bad disk sector, by some weird hardware bug — you find out long before you need that emergency restore. This sounds boring but it's the difference between a scare and a catastrophe.
• Genuine open source with no asterisks. The volume format is documented. If SIXE goes away tomorrow, or if Bacula Systems goes away, your backups are still recoverable with community open source tools. You can't say that about almost any other vendor.
• LTO, Object Lock and air-gap built in since forever. These aren't recent features that got bolted on because ransomware became fashionable. They've been the natural way to run Bacula for decades. When the rest of the market woke up to the fact that tape mattered again, Bacula was already there.

Why Bacula gets cheaper every year (and the big vendors don't)

The price gap between Bacula and the big proprietary players isn't some discount trick. It comes down to the licensing model itself. Veeam, Veritas NetBackup and Commvault all bill based on how much data you protect, or how many hosts you have, or some creative combination of the two. The result is always the same: when your company grows, your backup bill grows at exactly the same rate. And companies grow every year.

Bacula Systems, on the other hand, licenses by number of clients and the plugins you activate. The price stays flat even if your data doubles. The first time a CFO realises this in a meeting with us, the silence across the table is very revealing.

It gets worse on the other side. Veeam has announced price increases of 4-8% for both January 2025 and January 2026, and that's just the headline number — customers on the Veeam forums regularly report cumulative increases of 25% or more across 2021-2024, with some individual renewals coming back at +49%. People in the industry have started comparing it to what Broadcom did to VMware after the acquisition. It's not unfounded.

In the migrations we've run from Veeam or Veritas, first-year savings typically land between 60% and 85%. The sweet spot is mid-sized environments, roughly 20-200 TB protected — that's where proprietary capacity pricing hurts the most and where Bacula shines the brightest. And the gap widens every year, because your data keeps growing and Bacula doesn't punish you for it.

How to design a Bacula that survives an attack

Installing Bacula isn't the hard part. Designing a Bacula that survives someone who already has root inside your network — that's where the real engineering happens. These are the five architectural decisions that make the difference between a backup that saves the company and one that goes down with it:

1. Separate the control plane from the data plane

The Bacula director and its PostgreSQL catalog should not live on the same network as the clients they protect. There needs to be a separate admin network with its own firewall rules, its own MFA, and ideally a zero-trust architecture applied to the backup servers themselves. Sounds obvious — but we see this done wrong most of the time we go in to audit someone else's install.

2. At least two truly independent repositories

One fast repository on disk, or on Ceph with Object Lock, for day-to-day restores. And a second air-gap repository for long retention: LTO tape, or a physically isolated Ceph cluster in another location, or both. The 3-2-1-1-0 rule isn't an optional suggestion, it's the minimum you should reasonably aim for. If your current backup plan fits in a single repository, you have a problem.

3. Automated verification. Actually turn it on.

Bacula lets you schedule jobs that re-read volumes and compare checksums. Use them. Seriously. It's the only way to catch tampering, media degradation, or weird hardware errors before you find them out on the worst possible day — the day you need an emergency restore. Our usual recommendation is weekly at minimum, more often where the infrastructure can handle it.

4. Retentions you can't shorten after the fact

Retention periods are defined in the director and "sealed" at write time on immutable volumes. Once a volume has been written to a WORM tape or an Object Lock bucket, there's no Bacula console and no database client that can shrink that retention. The volume is going to exist until it expires, end of story. This is exactly what protects your backup from a disgruntled insider or an attacker with valid credentials.

5. A recovery plan that's written down and actually rehearsed

A backup you never restore doesn't exist. Bacula makes the restore side genuinely manageable, but rehearsing the drill — with timings, ownership, decision points — is the team's job. At SIXE we bake this into the client's Disaster Recovery Plan, with actual drills scheduled at least twice a year. There's no shortcut for this one.

Migrating from Veeam or Veritas without losing a single byte

The objection we hear on almost every first call is word for word the same: "we've got seven years of history in Veeam, we can't afford to lose it." And they're absolutely right. In banking, healthcare, public administration or any environment governed by GDPR, ISO 27001, HIPAA or sector-specific frameworks, long retention isn't a preference — it's a legal requirement. The good news is there's no technical reason to lose anything. You just have to design the migration properly.

At SIXE we do it in three phases:

1. Coexistence window. We leave the old system running at full tilt, doing its daily backups exactly as before. Bacula starts protecting in parallel. For a few weeks you have double coverage and zero risk. This tends to reassure security teams that were raising eyebrows at the start.
2. Real restores before we switch anything off. This is where migrations are actually won or lost. We don't do the classic test VM restore — we restore workloads that would genuinely hurt if they failed. A critical database. A regulated file server. When those restores confirm the design works, we move to the next phase. Not before.
3. Read-only historical archive. Your old system's history doesn't get touched. It stays accessible for as long as your retention policy needs, in read-only mode, as a live archive. If someone asks for a 2023 file next year, it's still there. And Bacula handles everything new in the meantime.

This is honestly one of the services we're being asked for the most right now. It's a perfect storm: proprietary licensing costs going up every year, the new pressure around immutable backups, and a growing realisation that backup has been quietly sitting in the "unaddressed risk" pile for too long. If you want the full breakdown of the service — SLAs, use cases, sector examples — it's all here: Bacula support and migration services.

Where to start today

If you've read this far and you're thinking "I should probably take another look at our backup", you're almost certainly right. You don't need to launch a huge project to take the first step. Honestly, the most useful starting point is usually a short audit answering three questions honestly:

• Are our backups actually immutable? If an attacker had admin credentials on my network right now, could they destroy the backups?
• Are they being verified automatically? Or will I only find out they were corrupted on the day I actually need a restore?
• How much am I paying per protected TB per year, and what will that number look like in three years?

You can answer all three with your current team, without calling anyone. If any of the answers make you uncomfortable, let's talk. No sales pitch, no slides, directly with someone on the engineering team who's had their hands inside projects very much like yours.

Further reading

• 10 Architecture & ROI Mistakes in the Post-VMware Exodus — another case where proprietary licensing is forcing people to rethink decisions they'd been avoiding for years
• Migrating from VMware to Proxmox VE — Bacula integrates cleanly with Proxmox for consistent VM-level backup, and the two projects often go hand in hand
• Ceph technical support — if your immutable repository is going to be Ceph with Object Lock, this is the other half of our specialty