All about backups

Cyberfusion creates backups on three separate tracks:

• Local backups on the master node — Cyberfusion-managed, short-term, used for quick restores. You control the interval and retention.
• Borg repositories — customer-configured, long-term, with the retention policy you set.
• Disaster recovery backups — Cyberfusion-managed, off-cluster, no customer-facing controls. A last-resort safety net.

This article explains what each is for and what you control on each.

Local backups on the master node

For each backup-capable service (MariaDB, PostgreSQL, Meilisearch, etc.), the cluster's master node holds a rolling set of recent backups. They are created automatically — you don't set them up.

You control two things per service, in 'Cluster Properties' for that service:

• The interval (e.g. 'MariaDB Backup Interval') — how often a backup is taken.
• The local retention (e.g. 'MariaDB Backup Local Retention') — how many recent backups are kept on the master node.

These backups exist so Cyberfusion can restore quickly when needed. They live on the master node only and rotate automatically as new ones are taken.

Borg repositories

Borg repositories are for long-term, customer-configured backups. You create a repository, point it at a UNIX user or a database, and decide how many backups to keep at each interval.

What can be backed up

A Borg repository backs up one of:

• A UNIX user — typically used for file backups of a project's data.
• A database — for database-level backups separate from the local-on-master rotation.

Retention: the keep settings

A Borg repository has five retention dials:

• 'Keep Hourly'
• 'Keep Daily'
• 'Keep Weekly'
• 'Keep Monthly'
• 'Keep Yearly'

Each holds an integer. After each backup, Borg keeps that many most-recent archives at each interval and prunes the rest.

At least one keep value must be set. Leaving them all blank isn't valid — Borg needs to know what to keep.

For the full picture of how Borg's pruning logic decides which archives survive, see the Borg prune example.

Frequency

The 'Frequency' field controls how often a new Borg archive is created from the repository's source.

Automatic pruning

The cluster has an 'Automatic Prune Enabled' toggle under 'Cluster Properties' > 'Borg'. When on, Cyberfusion runs borg prune automatically using each repository's keep settings. When off, pruning is manual.

Disaster recovery backups

Cyberfusion runs a third backup track for disaster recovery — off-cluster, taken on a Cyberfusion-internal schedule, with retention managed entirely by Cyberfusion.

You can't see, configure, or restore from these backups yourself. They exist so that if a catastrophic incident wipes out a cluster, Cyberfusion has something to rebuild from. For normal restore scenarios (a database dropped this morning, a file deleted last week), the local-on-master rotation or your Borg repository is what you'll be working with.

Picking the right track

• For fast restore of recent state (e.g. "oops, undo this morning's migration"): the local-on-master rotation has you covered already.
• For long-term retention (compliance, yearly archives, file-level history beyond a week or two): use a Borg repository.
• Most production setups use both — they don't conflict.

Use cases by target group