Backups

Learn how backup jobs connect volumes to repositories with scheduling, retention policies, and restore capabilities.

What are backup jobs?

A backup job is the central piece of Zerobyte. It defines four things:

• What to back up, a volume (your data source)
• Where to store it, a repository (your encrypted storage destination)
• When to run, a cron schedule
• How long to keep snapshots, a retention policy

Each time a backup job runs, Restic creates an incremental, encrypted snapshot of the volume's contents and stores it in the repository.

Creating a backup job

To create a backup job, navigate to Backups in the sidebar and click Create a backup job. First choose a volume, then fill in the backup form:

• Backup name, a descriptive name for the job (e.g., "Daily Database Backup")
• Backup repository, select from your configured repositories
• Backup frequency, choose Manual only, Hourly, Daily, Weekly, Specific days, or Custom (Cron)
• Retention policy, optionally define how many snapshots to keep

Scheduling

Backup jobs use cron expressions to define when they run. Cron syntax gives you precise control over scheduling.

Common cron patterns

Retention policies

Retention policies control how long snapshots are kept. After each backup, Restic automatically prunes snapshots that fall outside the defined policy, freeing up storage space.

You can configure the following retention rules:

Example retention policy

A balanced policy for most workloads:

• Keep Daily: 7, one snapshot per day for the past week
• Keep Weekly: 4, one snapshot per week for the past month
• Keep Monthly: 6, one snapshot per month for the past half year
• Keep Yearly: 1, one snapshot per year for long-term archival

Include and exclude paths

By default, the entire volume is backed up. You can refine this with include and exclude patterns.

Include paths

Specify subdirectories within the volume to back up. Only these paths will be included in the snapshot.

Exclude patterns

Exclude files or directories that do not need to be backed up. Common patterns:

• *.tmp, temporary files
• node_modules/, dependency directories
• .cache/, cache directories
• *.log, log files

Compression

Backups inherit the compression mode from the repository they write to. Compression is configured per repository and applies to all backup jobs targeting that repository.

Available modes are auto (default), off, and max. See Repositories for details on each mode.

Running backups

There are two ways to run a backup job:

• Scheduled, the job runs automatically according to its cron schedule. No intervention required.
• Manual, click Backup now on any backup job to trigger it immediately, regardless of the schedule.

Both methods produce identical snapshots. Manual runs are useful for verifying a new backup job or creating an extra snapshot before a major change.

Backup status

The UI exposes two related status views:

• In the Backups list, the status dot shows Active, Paused, Error, Warning, or Backup in progress
• In the backup job details page, the last run status shows Success, Error, Warning, or in progress
• If a backup job has not completed a run yet, the details page shows no last run value

Snapshots

Each successful backup creates a snapshot in the repository. Snapshots have several important properties:

• Immutable, once created, a snapshot cannot be modified
• Incremental, only changed data since the last snapshot is uploaded
• Browsable, you can explore snapshot contents directly in the web interface, viewing file sizes, modification times, and directory structure

The first backup uploads all data and may take longer. Subsequent backups are significantly faster because Restic deduplicates data at the chunk level and only transfers new or changed blocks.

Restoring data

Zerobyte lets you browse snapshots, restore them back to a filesystem path, or download the selected contents directly.

For the complete restore workflow, overwrite modes, custom-target guidance, and mounted-volume permission caveats, see Restoring Data.

At a high level, restoring works like this:

Mirror repositories

You can optionally copy snapshots to additional repositories after each backup. Mirrors provide:

• Geographic redundancy, store copies in different regions or data centers
• Provider diversification, avoid depending on a single cloud provider
• Compliance, meet data locality or regulatory requirements

Mirrors are configured per backup job. After each successful backup, snapshots are automatically copied to all enabled mirror repositories.

For a practical pattern that combines fast local restores with an offsite copy, see 3-2-1 Backup Strategy.

Monitoring

The Zerobyte web interface provides visibility into each backup job:

• Schedule, the cron expression or Manual only configuration for the job
• Last backup, when the most recent run happened
• Next backup, when the job is expected to run next
• Snapshot history, the list of snapshots created for that job
• Snapshot statistics, data added, data stored, files processed, bytes processed, and duration for the selected snapshot
• Restore actions, restore or download data from the selected snapshot

Best practices

Next steps