Guide and monitor 3-2-1-0-0 backup strategy

[borg-codex-bot]

Summary

Add a strategy layer that helps users configure, understand, and monitor a 3-2-1-0-0 backup strategy with Borg Backup UI.

The application can already cover many parts individually: multiple Borg backup jobs, different storage targets, offsite SSH/storagebox repositories, repository checks, backup result monitoring, and automated restore tests. What is missing is a UI and data model that recognizes these parts as one coherent backup strategy.

Goal

Users should be visually guided when creating or reviewing backups that follow the 3-2-1-0-0 strategy:

• 3: original data plus two backup copies
• 2: different storage media or storage classes
• 1: at least one offsite backup
• 0: no backup integrity errors, monitored through checks and run results
• 0: restore verification is current and successful

User value

This turns Borg Backup UI from a collection of job/storage/check pages into a tool that can show whether a user has a complete, healthy backup strategy.

For example:

• Original data on Unraid
• Backup copy on USB
• Offsite copy on SSH/Hetzner Storage Box/cloud repository
• Automated borg checks
• Scheduled restore tests

The UI should make these relationships visible and help the user see what is missing.

Current limitation

Today the user can configure the required parts, but each part is configured and evaluated independently:

• Jobs do not know whether they form a strategy group.
• Storage targets do not expose whether they are local, removable, offsite, cloud, or same-machine risk.
• Dashboard does not summarize strategy compliance.
• Restore tests are per job, but not evaluated against a strategy goal.
• Repository checks exist, but are not tied to 3-2-1-0-0 compliance.

Desired behavior

Add a feature that can model and visualize strategy compliance.

Possible UX ideas:

• A new Strategy or Backup Strategy page.
• A strategy card on the Dashboard.
• A wizard step or assistant when creating backup jobs.
• Group related jobs by protected source dataset/application.
• Show a 3-2-1-0-0 checklist per protected dataset.
• Highlight missing or weak points, e.g. no offsite copy, no restore test schedule, stale borg check, only one storage medium.
• Show clear status states: complete, partial, attention needed, failed.

Architecture considerations

This likely needs more than a small UI change.

Potential model additions:

• Protected dataset / backup set concept
• Relationship between one source and multiple backup jobs
• Storage classification metadata:
  • local
  • removable USB
  • SMB/NAS
  • SSH/offsite
  • cloud/rclone in the future
• Offsite flag or location/risk classification
• Strategy policy metadata:
  • required copies
  • required media diversity
  • offsite required
  • check freshness threshold
  • restore-test freshness threshold
• Derived compliance state from jobs, storage, history, checks, and restore-test reports

Backward compatibility matters. Existing jobs should continue to work, and strategy grouping should be optional or inferred where possible.

Suggested implementation phases

Phase 1: Analysis and data model

• Analyze current job, storage, history, repository check, and restore-test data.
• Define the minimum metadata needed for strategy grouping and storage classification.
• Decide what can be inferred automatically and what requires user input.
• Define migration/default behavior for existing jobs.

Phase 2: Read-only strategy overview

• Add a visual overview that evaluates existing jobs without changing backup execution.
• Show 3-2-1-0-0 compliance per protected source or job group.
• Identify missing pieces and stale/failed checks.

Phase 3: Guided setup

• Extend job creation or add a strategy assistant that helps create the missing second/offsite copy.
• Suggest restore-test schedules and check settings.
• Keep the existing job workflow usable for advanced/manual setups.

Acceptance criteria

• Users can see whether a protected source follows the 3-2-1-0-0 strategy.
• The UI can identify at least:
  • number of backup copies
  • storage/media diversity
  • offsite presence
  • check status/freshness
  • restore-test status/freshness
• Existing jobs remain backward compatible.
• Strategy grouping is either inferred safely or configurable by the user.
• Missing requirements are shown as actionable guidance, not just raw errors.
• The implementation is prepared for future storage types such as rclone/cloud.

Open questions

• Should strategy groups be explicit user-created objects, inferred from source paths, or both?
• How should storage media diversity be classified for SMB/NAS targets?
• Should offsite be a manual flag on a storage profile, an inferred property, or both?
• What retention/freshness thresholds should be default for checks and restore tests?
• Should this be a Dashboard widget first or a dedicated Strategy page first?

[borg-codex-bot]

Deferred to the post-publication phase. The 3-2-1-0-0 strategy assistant should be handled as a larger follow-up feature after the initial public release.