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, with no customer-facing controls. These are only used if a whole cluster is lost.

This article explains what each is for and what you control on each, and how to create, browse and restore an archive yourself.

Which track you can restore from yourself

Most production setups use the first two. They do not conflict.

Working with your backups

The 'Backups' page lists the archives in a Borg repository. From there you create a backup, look inside one, download it, and restore it.

Where to find it

Directly

1. Navigate to 'Advanced' > 'UNIX Users'.
2. Select the UNIX user.
3. Navigate to 'Backups'.

Via the project

1. Navigate to 'Projects'.
2. Select the project.
3. Navigate to 'Backups'.

The project's page shows the file backups and the database backups of the selected environment together.

For a database's backups directly: 'Advanced' > 'Databases' > the database > 'Backups'.

'Backups' only works once a Borg repository exists for that site or database. Without one, the item is disabled and shows 'No backup repositories configured'. Local-on-master and disaster recovery backups aren't listed here and can't be restored by you; ask Cyberfusion support if you need one of those.

Reading the list

Archives are grouped into 'Files' and 'Database'. Each row shows:

• 'Name' — 'Automatic' for archives the cluster created on the repository's own frequency, or the name you typed if you created it yourself.
• 'Created' — when the archive was made. Hover for the exact date and time.

To put a site back in full you need one of each. The files archive holds the website's code and uploads; the database archive holds its content, users and settings.

Creating a backup yourself

Worth doing right before something risky, such as a CMS update or a migration, so you have a known-good point that is not tied to the automatic schedule.

• On a UNIX user or database page: 'Create Backup'.
• On a project page: 'Create File Backup' and 'Create Database Backup'. The database one also asks which 'Database'.

A button is disabled when there is no repository of that kind yet.

Give the backup a 'Name' so you can recognise it later. Letters, numbers, hyphens and underscores, up to 64 characters.

Browsing a files archive

Click the name of a files archive to look inside it without restoring anything.

You get a directory listing with 'Name', 'Size', 'User', 'Permissions' and 'Modified'. Click a directory to go into it, 'Directory up' to go back, 'Close' to return to the list.

Use this to check an archive holds what you expect before you overwrite anything with it.

Database archives cannot be browsed — a database backup is one file holding the whole database, not a directory tree.

Restoring

Every archive has a 'Restore' icon, and so does every file and directory in the archive browser.

• A whole files archive — puts back everything in it.
• A single file or directory from the browser — leaves the rest of the site alone. This is what you want when one plugin directory needs to go back but the rest is fine.
• A database archive — puts back the contents of that database.

After a hack, a restore is usually safer than removing the attacker's files one by one. See Clean up after a hack.

Downloading

Every archive, file and directory also has a 'Download' icon. It generates a download link and writes nothing back to the site, so it is the safe option when you only want to look at a backup or keep a copy of one file.

A large archive takes a few minutes.

Local backups on the master node

Created automatically, so you do not set them up. For each backup-capable service (MariaDB, PostgreSQL, Meilisearch, and so on), the cluster's master node holds a rolling set of recent backups.

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

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

These exist so Cyberfusion can restore quickly when needed. They live on the master node only and rotate automatically.

Borg repositories

You create a repository, point it at a site's files or at a database, and decide how many backups to keep at each interval.

A repository backs up one of:

• A site's files — the usual choice for backing up a project's data.
• A database — database-level backups separate from the local-on-master rotation.

Retention: the keep settings

Five dials, each an integer:

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

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 is not valid, because Borg needs to know what to keep.

How Borg's pruning logic decides which archives survive: the Borg prune example.

'Frequency'

How often a new Borg archive is created from the repository's source.

Automatic pruning

'Automatic Prune Enabled' under 'Cluster Properties' > 'Borg'. On: Cyberfusion runs borg prune using each repository's keep settings. Off: pruning is manual.

Disaster recovery backups

Off-cluster, taken on a Cyberfusion-internal schedule, with retention managed entirely by Cyberfusion.

You cannot see, configure or restore from these. They exist so that if a catastrophic incident wipes out a cluster, Cyberfusion has something to rebuild from.

For normal restores — a database dropped this morning, a file deleted last week — the local-on-master rotation or your Borg repository is what you work with.

Suggested keep settings

• One repository per client site — Daily: 14, Weekly: 8, Monthly: 6. If a client deletes a media library, you have file-level history to restore from.
• A webshop database — Hourly: 24, Daily: 14, Monthly: 12, so order-table corruption mid-day is recoverable to the previous hour rather than to yesterday.
• Compliance retention — a database repository with long retention, paired with a UNIX-user repository for uploaded files. Run a quarterly restore drill against a staging cluster: a backup you have never restored is not proven to work, and the drill catches a silently broken repository.
• Long audit windows — Yearly: 7, with 'Automatic Prune Enabled' on so old archives do not pile up unnoticed.