Knowledge Base

The question nobody asks — until it’s too late

Hard drives fail. Ransomware encrypts. Employees delete. Databases corrupt. Cloud providers have outages. Every one of these events has one thing in common: without a backup, the data is gone.

The question isn’t if you’ll need a backup. It’s when.

What backups protect against

The cost of no backup

Consider what your data is worth:

• Financial records — years of accounting, invoices, tax documents
• Customer data — CRM, contracts, communication history
• Intellectual property — source code, designs, documentation
• Operational data — configurations, automation scripts, infrastructure state

Rebuilding any of these from scratch costs more than any backup solution. For many businesses, losing critical data means closing the doors.

What makes a good backup

A backup is only useful if it can be restored. Key principles:

1. Regular — backups run on a schedule, not “when someone remembers”
2. Tested — restore tests prove the backup actually works
3. Offsite — at least one copy is stored away from the primary location
4. Monitored — failed backups are detected immediately, not weeks later
5. Documented — the restore process is known before the emergency

Where Bareos fits in

Bareos is an open source backup solution that handles all of this — scheduling, monitoring, offsite copies, restore testing. It’s battle-tested in production environments from small offices to large enterprises.

Onesimus gives Bareos a modern visual interface. Instead of memorizing bconsole commands, you manage your entire backup infrastructure through a native desktop application.

Learn about the 3-2-1 backup rule →

The simplest rule that saves businesses

The 3-2-1 rule is the most widely accepted backup strategy. It’s simple, effective, and technology-agnostic:

• 3 copies of your data
• 2 different storage media
• 1 copy offsite

Why three copies?

One copy is no copy. If your only backup sits on the same server as your data, a single event (fire, ransomware, hardware failure) destroys both.

Two copies is better, but still risky. If both copies are on the same media type (e.g., two hard drives), a manufacturing defect or firmware bug could affect both.

Three copies makes simultaneous loss statistically improbable. You’d need three independent failures at the same time.

Why two media types?

Different storage technologies fail differently:

Using two different media types means a single failure mode can’t wipe all your copies. Common combinations:

• Disk + Tape — the classic enterprise approach
• Disk + Cloud — modern hybrid strategy
• NAS + External Drive — small business approach

Why one offsite?

Local disasters don’t care about your backup strategy. Fire, flood, theft, or a power surge can destroy everything in one location. One copy must be physically separated:

• Remote datacenter — another building, another city
• Cloud storage — geographically distributed by design
• Tape vaulting — physical tapes stored offsite

The 3-2-1 rule with Bareos

Bareos supports all of these scenarios natively:

• Multiple pools for different copy levels (Primary, Copy, Archive)
• Copy jobs that duplicate backups to a second storage
• Cloud storage integration for offsite copies
• Tape support for air-gapped backups

Onesimus will visualize this in the Pro edition — see all your copies, pools, and storage locations in one view. Community already lets you manage the jobs and schedules that make 3-2-1 work.

Beyond 3-2-1: The 3-2-1-1-0 rule

Modern best practices extend the rule:

• 3-2-1 plus 1 air-gapped or immutable copy
• 0 errors — verify every backup with automated restore tests

The extra “1” protects against ransomware that specifically targets backup systems. An air-gapped tape or an immutable cloud snapshot can’t be encrypted by malware.

Learn about backup levels: Full, Incremental, Differential →

Not all backups are the same

Backing up everything every time is safe but wasteful. Backing up only changes is efficient but complex. The right strategy combines both — and understanding backup levels is the key.

Full Backup

A Full backup copies every file, regardless of whether it has changed.

Use for: Weekly or monthly base backups, critical systems, compliance requirements.

Incremental Backup

An Incremental backup copies only files that changed since the last backup of any level.

Use for: Nightly backups between Fulls, environments with high change rates.

Example chain:

Mon: Full (100 GB)
Tue: Incremental (2 GB) — changes since Mon
Wed: Incremental (3 GB) — changes since Tue
Thu: Incremental (1 GB) — changes since Wed

Restoring Thursday requires: Full + Tue-Inc + Wed-Inc + Thu-Inc.

Differential Backup

A Differential backup copies all files that changed since the last Full backup.

Use for: Environments where restore speed matters more than storage efficiency.

Example chain:

Mon: Full (100 GB)
Tue: Differential (2 GB)  — changes since Mon
Wed: Differential (5 GB)  — changes since Mon (cumulative)
Thu: Differential (6 GB)  — changes since Mon (cumulative)

Restoring Thursday requires: Full + Thu-Diff only.

VirtualFull Backup

A VirtualFull is a synthetic Full backup constructed from existing backups without reading from the client. Bareos creates it by combining the last Full with all subsequent Incrementals on the storage side.

Use for: Reducing client and network load during Full backup windows.

Which strategy should you use?

Small environments (< 10 clients)

Weekly Full + Daily Incremental

Simple, low storage overhead, acceptable restore times.

Medium environments (10-100 clients)

Monthly Full + Weekly Differential + Daily Incremental

Balance between storage, backup window, and restore speed.

Large environments (100+ clients)

Monthly VirtualFull + Daily Incremental

Minimal client impact, synthetic Fulls keep restore chains short.

How Onesimus helps

Onesimus shows your schedules visually — color-coded by backup level. The Gantt timeline makes it obvious when Fulls run, how Incrementals fill the gaps, and where your backup windows are.

The schedule visualization is available in Community. Understanding which levels are consuming storage will be part of Onesimus Pro.

Learn about retention and how it affects storage →

What is retention?

Retention defines how long a backup is kept before it can be overwritten or deleted. It’s the bridge between “we have enough storage” and “we can still restore last month’s data.”

In Bareos, retention is set per pool and applies to volumes. When a volume’s retention expires, it becomes eligible for recycling — its space can be reused for new backups.

Why retention matters

Too short = no recovery points when you need them. Too long = storage fills up faster than expected.

Most regulatory environments require 30-90 days. Some industries require years.

How retention works in Bareos

Bareos tracks three types of retention:

File Retention

How long individual file entries are kept in the catalog. After expiry, you can no longer browse individual files in the backup — but the backup data itself is still on the volume.

Job Retention

How long job records are kept in the catalog. After expiry, the job metadata disappears from the catalog, but the volume data may still exist.

Volume Retention

How long a volume is kept before it can be recycled. This is the critical one for storage — when volume retention expires, Bareos can reuse the space.

The relationship:

File Retention <= Job Retention <= Volume Retention

File entries expire first, then job records, then the volume itself.

Choosing the right retention

Start with the question: “What’s the oldest data I might need to restore?”

Then consider storage:

Longer retention = more storage. The relationship isn’t linear — it depends on your backup levels and change rates:

• Full + Daily Incremental, 30-day retention: ~5x the data size
• Full + Daily Incremental, 90-day retention: ~12x the data size
• Monthly Full + Daily Incremental, 365-day retention: ~15x the data size

These are rough estimates. Your actual numbers depend on change rates, compression, and deduplication.

The retention trap

The most common mistake: setting retention without understanding the storage impact. An admin changes retention from 30 to 90 days — and three months later, the pool is full.

This is exactly question 4 of the 5 questions every backup admin asks: “What happens if I change retention?” The ability to simulate retention changes before applying them is planned for Onesimus Enterprise.

Retention vs. recycling

Retention is when a volume becomes eligible for reuse. Recycling is actually reusing it. A volume past retention isn’t automatically deleted — it stays until Bareos needs the space.

This distinction matters: you might have volumes that are past retention but still contain useful data. Smart recycling recommendations (planned for Onesimus Pro) will help identify which volumes are truly safe to reuse.

Learn about pools and how they organize your storage →

The storage hierarchy

Bareos organizes backup data in three layers:

Storage Daemon
  └── Pool (logical grouping)
       └── Volume (physical storage unit)
            └── Job data (backup content)

Understanding this hierarchy is essential for managing storage capacity — and it’s the foundation for everything Onesimus visualizes.

What is a Pool?

A Pool is a logical container that groups volumes with the same purpose and policies. Think of it as a filing cabinet with a specific label.

Common pool configurations:

Each pool has its own settings for:

• Volume Retention — how long data is kept
• Maximum Volume Size — how large a volume can grow
• Maximum Volumes — how many volumes the pool can hold
• Recycle — whether expired volumes can be reused
• Auto-Prune — whether Bareos automatically removes expired data

What is a Volume?

A Volume is a physical storage unit — typically a file on disk, or a tape. It holds the actual backup data from one or more jobs.

Volume states in Bareos:

The lifecycle: Append → Full → Used → Purged → Recycled → Append.

Why pools matter

Without pools, all backups go into one big pile. With pools, you can:

• Separate backup levels — Full backups to large volumes, Incrementals to smaller ones
• Different retention per type — keep Fulls for 90 days, Incrementals for 14
• Different storage targets — Fulls to tape, Incrementals to disk
• Copy and migration — move data between pools for offsite or archival

The Scratch Pool

The Scratch pool is special. It holds “blank” volumes that Bareos can automatically assign to any pool that needs space. When a pool needs a new volume and none are available, Bareos pulls one from Scratch.

This is useful because:

• You don’t need to pre-assign volumes to specific pools
• Storage is used on-demand
• Recycled volumes can return to Scratch for reuse anywhere

Pool management in Onesimus

Pool management is coming in Onesimus v0.3.0 — visual pool overview with volume status and lifecycle tracking. Onesimus Pro will add consumption analysis per job and client, growth trends, and recycling recommendations.

The 5 core questions every backup admin asks are all about understanding pools and volumes — where storage goes, when it runs out, and how to optimize it.

Back to Knowledge Base →

The schedule is the backbone

Every backup job needs a schedule. The schedule determines when the job runs, which backup level it uses (Full, Incremental, Differential), and how often. Get the schedule wrong, and everything downstream suffers — jobs collide, backup windows are missed, storage fills up unpredictably.

In Bareos, a schedule is a named resource that contains one or more Run directives. Each Run directive specifies a time, a day, and a backup level.

Anatomy of a Bareos schedule

A typical schedule looks like this:

Schedule {
  Name = "WeeklyCycle"
  Run = Full         1st sun at 02:00
  Run = Differential 2nd-5th sun at 02:00
  Run = Incremental  mon-sat at 21:00
}

This means:

A single schedule can be assigned to multiple jobs. That’s efficient, but it also means every job using WeeklyCycle starts at exactly the same time — which leads to the most common scheduling mistake.

The collision problem

When 10 jobs share the same schedule and all start at 21:00, they all hit the Storage Daemon simultaneously. The result:

• Network saturation — all clients sending data at once
• Disk I/O bottleneck — the Storage Daemon writes all streams in parallel
• Extended backup windows — jobs that should take 30 minutes take 3 hours
• Timeout failures — clients disconnect because the SD can’t keep up

The fix: stagger your start times

Instead of one schedule for everything, create multiple schedules with offset start times:

Schedule {
  Name = "Stagger_Group_A"
  Run = Incremental mon-sat at 20:00
}

Schedule {
  Name = "Stagger_Group_B"
  Run = Incremental mon-sat at 21:00
}

Schedule {
  Name = "Stagger_Group_C"
  Run = Incremental mon-sat at 22:00
}

Distribute your jobs across these groups so that only a few clients run at the same time.

Priority and ordering

Bareos supports a Priority directive on each job. Lower numbers run first. Jobs with the same priority run in parallel; higher-numbered jobs wait.

Job {
  Name = "BackupDatabase"
  Schedule = "WeeklyCycle"
  Priority = 5          # runs first
}

Job {
  Name = "BackupFileserver"
  Schedule = "WeeklyCycle"
  Priority = 10         # waits for priority 5 to finish
}

This is useful when:

• A database dump must finish before the file-level backup starts
• A critical server should get full bandwidth before less important clients begin
• You want sequential execution without creating separate schedules

Backup windows

A backup window is the time period available for backups — typically overnight or during low-usage hours. If your backup window is 20:00–06:00, all jobs must complete within that window.

Key factors that affect the backup window:

Sizing the window

Start by measuring your largest Full backup and work backwards:

Available window:  10 hours (20:00–06:00)
Largest Full:       4 hours
Remaining:          6 hours for all other jobs

If the remaining time isn’t enough, consider:

• Running Fulls on weekends when the window is longer
• Using VirtualFull to avoid client-side Full backups entirely
• Staggering Fulls across different days (not all on Sunday)

Common scheduling patterns

Simple weekly cycle

Full:        Sunday 02:00
Incremental: Monday–Saturday 21:00

Best for small environments with few clients and enough storage for weekly Fulls.

Monthly Full + weekly Differential

Full:         1st Sunday 02:00
Differential: 2nd-5th Sunday 02:00
Incremental:  Monday–Saturday 21:00

Reduces Full backup frequency. Differentials keep restore chains short.

Staggered multi-group

Group A (databases):     20:00 daily, Full Sunday
Group B (file servers):  21:30 daily, Full Saturday
Group C (workstations):  23:00 daily, Full Friday

Distributes load across the night. Each group has its own Full day to avoid Sunday congestion.

Common mistakes

How Onesimus helps

Scheduling is exactly where the console falls short. A list of Run directives doesn’t show you the big picture. Onesimus provides:

• Gantt timeline — see all jobs across a day or week, color-coded by level, with their estimated durations
• Collision detection — overlapping jobs are flagged automatically
• Job-to-schedule mapping — click a schedule and see which jobs use it
• Duration statistics — historical min/avg/max per job and level, so you know whether a job fits its window

The schedule visualization is available in Community. Understanding the storage impact of your schedule will be part of Onesimus Pro.

Learn about backup levels → · Learn about retention →