If you’ve managed servers, applications or backup systems, you know the challenge. Settings change over time and after a few months, it’s easy to forget why those changes were made.
Configuration as Code (CaC) helps prevent this problem. Rather than relying on memory or scattered notes, you store your configuration in text files. You can keep these files in Git, share them with your team, review changes, and roll back if needed.
For backup systems, this is more than just a nice feature. Backups are essential for incident response. When you need to restore, it’s important that your configuration is clear, consistent, and easy to repeat.
Manual Setup vs. Configuration as Code
| Manual setup | Configuration as Code |
|---|---|
| Admins click through GUIs or edit configs directly on servers | Config is stored in text files, usually under version control |
| Changes are hard to track | Every change has a history – who, what, when |
| Rollback is tricky, often guesswork | Rollback is a simple git revert |
| Documentation drifts out of date | Config files are the documentation |
How It Looks in Bareos
# List of files to be backed up
FileSet {
Name = "MyFileSet"
Include {
Options {
Signature = XXH128
}
File = /home
Exclude Dir Containing = .nobackup
}
}Learn how Bareos configuration is structured → https://docs.bareos.org/Configuration.html
With Bareos, you don’t have to click through menus. You simply describe backup jobs, clients and storage devices in easy-to-read text files.
What Problems CaC Solves in Real Life
CaC removes guesswork. Your configuration is not spread across people’s memory, old tickets or random server changes. It’s written down, easy to review, and simple to share.
It also makes dealing with problems easier. If a change causes trouble, you can quickly compare versions and return to the last setup that worked. This matters for backups, since issues like missed jobs, wrong retention settings, full storage or plugin updates often appear much later.
CaC is also useful as your setup grows. If you manage several sites, teams or customer systems, you can reuse a base configuration and make small, controlled changes for each one.
Why It Matters Especially for Backups and Recovery
Backup configuration is full of details that have real consequences:
- Coverage: what is backed up and what is not
- Retention and storage policies: how long data stays available and where
- Restore readiness: whether restores are tested and repeatable
- Audit trail: who changed what and when
- Consistency: the same rules across systems and environments
With CaC, you can review and approve changes before they go live. Retention rules stay consistent. You can run restore tests regularly and confidently. When it’s time for an audit, you have a real change history to show, instead of piecing things together later.
Common Pitfalls and Best Practices
CaC is most effective when you follow a few basic guidelines.
- Do not store secrets in Git.
Manage passwords, keys, and tokens separately. This keeps your configuration files easy to read and safe to share within your team. - Separate environment-specific values.
Paths, hostnames, and storage targets often vary between sites. Use a shared base configuration and add small environment-specific changes as needed. - Validate before you reload.
Handle configuration changes the same way you handle code changes. Test them before rolling out to avoid disrupting backup schedules. - Use naming conventions.
Using clear names for jobs, clients, schedules, and pools makes your configuration easier to read and helps prevent mistakes.
From Theory to Practice: What does this mean for me?
It’s one thing to know about Configuration as Code, but how do you actually use it in your daily work?
In many places, backup systems are still set up manually, either by editing configs on servers or clicking through GUIs. This works until you need to recover something and find that no one remembers what was changed or why.
This is where Configuration as Code helps. When your backup settings are in text files, you can:
- Keep everything in Git so you can see who changed what, when, and why.
- Roll back safely. If a change causes a problem, simply revert to a previous version.
- Share configurations with your team, so important details aren’t just in one person’s head.
- Use configuration files as documentation, since they show exactly how the system works.
Bareos and Configuration as Code go together perfectly
If you use Bareos, you already have a good starting point. Bareos uses text-based configuration files, so you can treat your backup setup as code: store it in Git, share it with your team, review changes and recreate the same setup whenever needed.
In combination with configuration management tools like Ansible, Puppet, Chef and SaltStack, this configuration can be easily automated and distributed. Together with the other automation options in Bareos, the whole lifecycle from provisioning to decommissioning clients can be automated.