Best Backup Solutions for FreeBSD

Backups on FreeBSD benefit from a unique advantage that no other mainstream operating system offers: ZFS snapshots. But snapshots alone are not a backup strategy. A real backup plan requires off-site copies, encryption, deduplication, and automated retention.

This guide compares the major backup tools available on FreeBSD, from lightweight deduplicating archivers like BorgBackup and Restic to enterprise solutions like Bacula and Bareos. We also cover how ZFS snapshots fit into a complete backup strategy.

For a head-to-head between the two most popular deduplicating tools, see our BorgBackup vs Restic comparison.

TL;DR -- Quick Verdict

Best overall for most FreeBSD users: BorgBackup. Fast deduplication, strong encryption, mature tooling, excellent space efficiency. The only downside is that it requires a Borg server on the remote end.

Best for cloud backends: Restic. Native support for S3, B2, Azure, GCS, SFTP, and REST server. No special software needed on the remote end.

Best for enterprise: Bareos (or Bacula). Client-server architecture, tape support, central management, web UI, scheduling.

Best for local snapshots: ZFS send/receive with automated snapshot management (zfsnap or sanoid). Zero-cost local snapshots with efficient remote replication.

Backup Tool Comparison

|---|---|---|---|---|---|

| Language | Python/C | Go | C++ | C++ | C (kernel) |

| Central management | No | No | Yes (Director) | Yes (Director + WebUI) | No |

| Tape support | No | No | Yes | Yes | No |

BorgBackup

BorgBackup (Borg) is a deduplicating archiver with compression and encryption. It is fast, space-efficient, and designed for regular backups of workstations and servers.

Installation and Setup

sh
# Install BorgBackup
pkg install py311-borgbackup

# Initialize a local repository
borg init --encryption=repokey /backup/borg-repo

# Initialize a remote repository via SSH
borg init --encryption=repokey ssh://backup@remote-server/backup/borg-repo

Basic Backup Workflow

sh
# Create a backup with timestamp name
borg create --stats --progress --compression zstd \
  /backup/borg-repo::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
  /etc /usr/local/etc /home /var/db/pkg \
  --exclude '*.cache' \
  --exclude '/home/*/.cache'

# Prune old backups (keep 7 daily, 4 weekly, 6 monthly)
borg prune --stats --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
  /backup/borg-repo

# Compact repository to reclaim space
borg compact /backup/borg-repo

# List backups
borg list /backup/borg-repo

# Restore a specific backup
borg extract /backup/borg-repo::myhost-2026-04-09_02:00 --target /restore

Strengths

Excellent deduplication ratio. Typically 10:1 or better for daily system backups.
Fast: variable-length chunking means small changes produce small backup deltas.
Mature encryption with authenticated encryption (repokey or keyfile modes).
borg mount lets you browse backups as a FUSE filesystem.
Active development, strong community.

Weaknesses

Requires borg serve on the remote end (or a local/SFTP repository). No native cloud storage support.
Single-threaded compression (though deduplication itself is fast).
Repository format is Borg-specific; cannot read backups with other tools.

Restic

Restic is a Go-based backup tool that emphasizes simplicity and native cloud storage support. It supports more backends than any other backup tool.

Installation and Setup

sh
# Install Restic
pkg install restic

# Initialize a local repository
restic init --repo /backup/restic-repo

# Initialize an S3 repository
export AWS_ACCESS_KEY_ID="your-key"
export AWS_SECRET_ACCESS_KEY="your-secret"
restic init --repo s3:s3.amazonaws.com/my-backup-bucket

# Initialize a Backblaze B2 repository
export B2_ACCOUNT_ID="your-account-id"
export B2_ACCOUNT_KEY="your-account-key"
restic init --repo b2:my-backup-bucket

Basic Backup Workflow

sh
# Create a backup
restic backup /etc /usr/local/etc /home /var/db/pkg \
  --repo s3:s3.amazonaws.com/my-backup-bucket \
  --exclude-caches \
  --tag freebsd-server

# List snapshots
restic snapshots --repo s3:s3.amazonaws.com/my-backup-bucket

# Apply retention policy
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune \
  --repo s3:s3.amazonaws.com/my-backup-bucket

# Restore a snapshot
restic restore latest --target /restore \
  --repo s3:s3.amazonaws.com/my-backup-bucket

# Mount backups via FUSE
restic mount /mnt/restic-mount \
  --repo s3:s3.amazonaws.com/my-backup-bucket

Strengths

Native support for S3, B2, Azure Blob, Google Cloud Storage, SFTP, REST server, and local storage.
Single binary, no dependencies. Easy to deploy.
Content-defined chunking with encryption by default.
Cross-platform: same repository format works from FreeBSD, Linux, macOS.

Weaknesses

Slightly lower deduplication ratio than Borg in benchmarks.
Prune operations can be slow on large repositories with cloud backends.
No built-in borg serve equivalent for append-only remote access (REST server fills this gap).

Bacula and Bareos

Bacula and Bareos are enterprise-grade backup systems. Bareos is a fork of Bacula with a more open development model and a built-in web UI. Both use a client-server architecture with three components: Director (scheduler), Storage Daemon, and File Daemon (client).

When to Choose Enterprise Backup

You need to back up dozens or hundreds of servers from a central location.
You require tape support (LTO).
You need role-based access control and audit logging.
Your organization requires scheduled backup windows with verification.

Bareos Setup

sh
# Install Bareos server components
pkg install bareos-server bareos-storage bareos-filedaemon bareos-webui

# Enable services
sysrc bareosdir_enable="YES"
sysrc bareossd_enable="YES"
sysrc bareosfd_enable="YES"

# Start services
service bareosdir start
service bareossd start
service bareosfd start

Comparison: Bacula vs Bareos

| Feature | Bacula | Bareos |

|---|---|---|

| License | AGPLv3 (community) | AGPLv3 |

| Web UI | BWeb (commercial) | bareos-webui (free) |

| Development model | Bacula Systems (commercial) | Community-driven |

| Plugin ecosystem | Commercial plugins | Open-source plugins |

| S3 backend | Plugin (commercial) | Plugin (free) |

| Documentation | Good (commercial bias) | Good (community) |

| FreeBSD support | Good | Good |

Verdict: For new enterprise deployments, Bareos is the better choice. It is fully open source, has a free web UI, and active community development.

ZFS Snapshots and Replication

ZFS is FreeBSD's killer feature for backups. Snapshots are instantaneous, cost nothing in additional space until data changes, and can be sent to remote systems efficiently.

ZFS Snapshot Strategy

sh
# Create a recursive snapshot of a dataset
zfs snapshot -r tank/data@daily-$(date +%Y-%m-%d)

# List snapshots
zfs list -t snapshot -r tank/data

# Send a snapshot to a remote system
zfs send tank/data@daily-2026-04-09 | \
  ssh backup-server zfs receive backup/data

# Send an incremental snapshot
zfs send -i tank/data@daily-2026-04-08 tank/data@daily-2026-04-09 | \
  ssh backup-server zfs receive backup/data

# Rollback to a snapshot
zfs rollback tank/data@daily-2026-04-08

# Destroy old snapshots
zfs destroy tank/data@daily-2026-03-01

Automated Snapshot Management

Use sanoid for policy-based snapshot management and syncoid for automated replication:

sh
# Install sanoid
pkg install sanoid

# /usr/local/etc/sanoid/sanoid.conf
# [tank/data]
#   use_template = production
#   recursive = yes
#
# [template_production]
#   frequently = 0
#   hourly = 24
#   daily = 30
#   monthly = 6
#   yearly = 0
#   autosnap = yes
#   autoprune = yes

# Enable sanoid timer
sysrc sanoid_enable="YES"

# Replicate to remote with syncoid
syncoid --recursive tank/data backup-server:backup/data

ZFS Snapshots vs Traditional Backups

| Aspect | ZFS Snapshots | Traditional Backup |

|---|---|---|

| Speed | Instantaneous | Minutes to hours |

| Space overhead | Zero (until changes) | Full copy (dedup helps) |

| Off-site copy | zfs send over SSH | Native cloud/remote |

| Encryption at rest | GELI or ZFS encryption | Built-in |

| Granularity | Entire dataset | File-level |

| Cross-platform restore | Requires ZFS | Standard formats |

| Protection from disk failure | No (same pool) | Yes (separate storage) |

Important: ZFS snapshots on the same pool are not backups. If the pool is lost, the snapshots are lost too. Always replicate snapshots off-site.

Cloud Backend Options

For off-site backups from FreeBSD:

|---|---|---|---|

| Tarsnap | No | No | $0.25/GB |

For Borg with cloud backends, use rclone as a transport layer:

sh
# Mount B2 bucket with rclone, then use Borg on the mount
pkg install rclone fusefs-libs
rclone mount b2:my-borg-bucket /mnt/b2-mount --daemon
borg create /mnt/b2-mount/borg-repo::backup-$(date +%Y-%m-%d) /data

Note: This approach is slower than Restic's native cloud support. If cloud backends are a priority, Restic is the better choice.

Recommended Backup Strategy for FreeBSD

A complete backup plan uses multiple layers:

ZFS snapshots for instant local recovery (hourly/daily, automated with sanoid).
ZFS replication to a second server or NAS for site-level redundancy.
BorgBackup or Restic to an off-site/cloud location for disaster recovery.
Periodic test restores to verify backup integrity.

sh
# Example cron setup for a three-tier backup strategy
# /etc/crontab additions

# Tier 1: ZFS snapshots every hour (managed by sanoid)
# (sanoid runs via its own cron/timer)

# Tier 2: ZFS replication to remote server every 6 hours
0 */6 * * * root /usr/local/bin/syncoid --recursive tank/data backup-server:backup/data

# Tier 3: Borg backup to off-site every night at 2 AM
0 2 * * * root /usr/local/bin/borg create --compression zstd \
  ssh://backup@offsite-server/backup/borg-repo::'{hostname}-{now:\%Y-\%m-\%d}' \
  /etc /usr/local/etc /home /var/db && \
  /usr/local/bin/borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \
  ssh://backup@offsite-server/backup/borg-repo && \
  /usr/local/bin/borg compact ssh://backup@offsite-server/backup/borg-repo

FAQ

Are ZFS snapshots a replacement for backups?

No. ZFS snapshots on the same pool protect against accidental deletion and allow instant rollback, but they do not protect against disk failure, pool corruption, fire, theft, or ransomware that destroys the pool. Always replicate snapshots to a separate system and maintain an off-site backup.

Should I use BorgBackup or Restic on FreeBSD?

Use BorgBackup if you are backing up to another server you control (via SSH). Use Restic if you are backing up directly to cloud storage (S3, B2, etc.). Both are excellent. See our detailed comparison for benchmarks and specifics.

How do I back up FreeBSD jails?

For iocage/bastille jails on ZFS, snapshot the jail's dataset. For file-level backups, include the jail's root directory in your Borg or Restic backup. Stop services inside the jail before snapshotting for consistency, or use ZFS snapshots which provide atomic point-in-time copies.

sh
# Snapshot all jails
zfs snapshot -r zroot/iocage/jails@backup-$(date +%Y-%m-%d)

What about Tarsnap on FreeBSD?

Tarsnap is a deduplicating, encrypted backup service written by Colin Percival (FreeBSD developer). It runs natively on FreeBSD and stores data in AWS. Tarsnap is excellent for small, critical datasets but costs $0.25/GB/month, making it expensive for large backups. Use it for configuration files, databases, and encryption keys -- not for terabytes of data.

How do I verify my backups are working?

Schedule periodic test restores. For Borg: borg check verifies repository integrity. For Restic: restic check does the same. For ZFS: zpool scrub verifies on-disk integrity. None of these replace actually restoring data and verifying it is correct.

Can I encrypt ZFS replication over the network?

zfs send | ssh ... zfs receive encrypts data in transit via SSH. For encryption at rest on the receiving end, use ZFS native encryption on the destination dataset or GELI on the destination pool. ZFS native encryption (available since FreeBSD 13) allows the receiving side to store data encrypted without needing the key.

Best Backup Solutions for FreeBSD