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.

Local backups on the master node

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

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

• The interval, for example 'MariaDB Backup Interval', which sets how often a backup is taken.
• The local retention, for example 'MariaDB Backup Local Retention', which sets 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, because 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.

Working with your backups

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

Where to find it

There are two ways to navigate to the backups of a UNIX user, so to the file backups of a website or application:

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 'Backups' page shows the file backups and the database backups of the selected environment together. To reach a database's backups directly, navigate to 'Advanced' > 'Databases', select the database, and navigate to 'Backups'.

'Backups' only works once a Borg repository exists for that UNIX user 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 in if you created it yourself.
• 'Created': when the archive was made. Hover it 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

Click 'Create Backup' on a UNIX user or database page. On a project page there are two buttons, 'Create File Backup' and 'Create Database Backup'; the database one also asks which 'Database' to back up. A button is disabled when there's no repository of that kind yet.

Give the backup a 'Name' so you can recognise it in the list later. Names may contain letters, numbers, hyphens and underscores, up to 64 characters.

This is worth doing right before something risky, such as a CMS update or a migration, so you have a known-good point to go back to that isn't tied to the automatic schedule.

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' per entry. Click a directory to go into it, 'Directory up' to go back up, and 'Close' to return to the archive list.

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

Database archives can't be browsed, because a database backup is one file holding the whole database rather than a directory tree.

Restoring

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

Restoring overwrites what is currently on disk at that path with the version from the backup, so you're asked to confirm first. Anything changed since the backup was taken is lost.

• Restoring a whole files archive puts back everything in it.
• Restoring a single file or directory from the browser leaves the rest of the site as it is. This is what you want when, for example, one plugin directory needs to go back but the rest of the site is fine.
• Restoring 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. This generates a download link and writes nothing back to the site, so it's the safe option when you only want to look at a backup or keep a copy of one file. For a large archive this takes a few minutes.

Disaster recovery backups

Cyberfusion runs a third backup track for disaster recovery. These are 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, such as a database dropped this morning or 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, for example undoing this morning's migration, the local-on-master rotation has you covered already.
• For long-term retention, such as compliance, yearly archives, or 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