Database backup/restore add-on

The Database Backup add-on automates dump-and-store for MySQL-family databases (MySQL, MariaDB, Percona), PostgreSQL, and Redis. It runs on a schedule, writes snapshots to a dedicated backup storage instance, and exposes a one-click restore from the dashboard.

The add-on is paired with a Backup Storage instance — a separate storage environment that holds all the dumps. Splitting the storage from the database itself means the backups survive a database redeploy, and a single backup storage can serve as many databases as you need.

Engine notes

Before you install, two engine-specific points are worth flagging:

• PostgreSQL. Before you redeploy a PostgreSQL instance to a new version, run a manual backup with this add-on. PostgreSQL major-version upgrades are not handled by the dump format alone; check the official pg_dumpall / pg_upgrade documentation for the upgrade path.
• MariaDB Galera cluster. The cluster has its own known limitations around restore. The add-on handles them automatically when you use the dashboard’s restore flow. For a manual dump restore on a Galera cluster, follow the linked engine guide before importing.

Step 1 — set up a backup storage

If you do not already have one:

1. Open the platform Marketplace and install the Backup Storage package.
2. Choose Standalone or Cluster. Cluster gives you a replicated multi-node storage; standalone is a single node.
3. For a cluster, specify the Number of nodes and the Storage size.
4. Provide the environment domain, the display name, and pick a region.
5. Click Install and wait for the environment to come up. It joins the Backup storage nodes group automatically.

One backup storage can host backups for many databases. You do not need a dedicated storage per database.

Step 2 — install the add-on on the database

1. Hover over the database environment in the dashboard and click the Add-Ons icon.

2. Find Database Backup/Restore Add-On and click Install.

3. Configure:

   • Schedule — pick one of the presets (hourly, daily, weekly, monthly), or Custom (time, days of the week, timezone), or Manual (crontab) (cron expression in UTC).
   • Backup storage — which backup storage environment to write to.
   • Number of backups — how many of the most recent backups to keep. Older ones are pruned automatically.
   • Database user / password — credentials the add-on uses to dump the database.

4. Click Install. From there, the add-on runs on schedule with no further intervention.

What gets stored

Each backup is a snapshot of the database dump file. On the backup storage, snapshots are organized:

• One folder per backed-up database.
• One file per snapshot, named by the execution timestamp.

This layout keeps things readable when one storage holds backups from several databases. You can browse the folder tree directly through the storage environment if you ever need to grab a dump out-of-band.

Managing the add-on

After installation, the add-on entry on the database exposes:

• Backup Now — run a backup immediately, outside the schedule.
• Configure — change schedule, storage target, retention count, or credentials.
• Restore — restore from a previous snapshot. See below.
• Uninstall — remove the add-on. Existing snapshots on the backup storage are not deleted.

Restoring a database

A restore overwrites the current database completely. Any changes since the snapshot was taken are lost. Treat the operation as irreversible.

1. From the database, open the add-on’s Restore option.
2. Choose:
   • Restore from — the source environment, if you have the add-on running on multiple databases.
   • Backup — which snapshot (named by timestamp) to restore.
3. Click Restore and confirm.

The platform mounts the relevant snapshot folder from the backup storage onto the database master node, applies the SQL dump, and reports success. The operation cannot be canceled mid-flight.

Important constraints on the topology side:

• The restore writes to the master node of the database layer only. For non-clustered databases with multiple nodes, only that one node ends up with the restored data.
• For primary-secondary topologies, make sure the primary is the layer master before restoring. Otherwise, the restore lands on a secondary and replication will get confused.

Where to go from here

• Database overview — the managed database tier and its topologies.
• Cluster recovery add-on — for cluster-level recovery, beyond the dump/restore model.
• Persistent data — broader patterns for keeping application data through container lifecycle.