Backups and point-in-time recovery

Backups are always on for MySQL. There is nothing to enable and no way to turn them off — only the schedule is yours to tune.

What is backed up

Two things, in every region the instance runs in:

• Database dumps. Each database in the instance is dumped on the instance's backup schedule — by default once a day, at 02:00. A dump is a complete, consistent copy of one database at one moment.
• Binary logs. MySQL records every change in its binary log. The platform ships the binary log off the instance every 15 minutes, continuously.

A dump on its own lets you go back to the moment it was taken. A dump plus the binary logs after it lets you go back to any second in between — that is point-in-time recovery.

Changing the schedule

Set a cron expression on the instance — in the console, with reis mysql:update <id> --backup_schedule "0 3 * * *", or with Terraform's backupschedule. Leave it empty for the platform default.

The recovery window

The instance's Backups tab in the console — and reis mysql:backups <instance-id> — show, per region:

• The recovery window: from the oldest dump still held to the newest binary log shipped. Any second inside it can be targeted by a point-in-time restore.
• The dumps: each database's dumps, with their time and size.

Because binary logs ship every 15 minutes, the end of the window trails the present by up to 15 minutes. Changes made in that most recent interval are not yet backed up off the instance.

Regions are backed up independently, just as they run independently — each region's window describes that region's copy.

What backups cost

Backup storage is billed per GB stored, per region — not per server, because all the servers in a region share one set of backups. What is stored, dumps and binary logs together, is measured once a day, and each hour is billed at the size most recently measured. Billing stops when you terminate the instance; the backups it leaves behind expire on their own and are not billed. The pricing page lists the current rate.

Restoring to a point in time

A restore never overwrites your instance. It creates a new instance in the same project, holding your databases exactly as they were at the second you choose. Your running instance keeps serving traffic throughout, and you decide what to bring back from the copy.

Choose:

• The region whose backups to restore from. The new instance runs in that region.
• The second, in UTC, inside that region's recovery window. Changes committed at or after that second are not included.
• The databases: all of them, or just one.
• What the restore becomes:
  • A staging copy, reachable from your project's containers, for reading data back. It has no backups of its own.
  • A staging copy with outside access, the same, plus SQL access from outside and/or phpMyAdmin, from the addresses you allow.
  • A new instance to keep, an ordinary instance with its own backups, under a handle you choose.

Start a restore from the instance's Backups tab in the console (Restore to a point in time), or with Reis:

reis mysql:restore <instance-id> --region falkenstein-1 --time 2026-10-04T13:30:00Z
reis mysql:restore <instance-id> --region falkenstein-1 --time 2026-10-04T13:30:00Z \
  --kind instance --handle orders-restored --database orders

Things to know:

• The new instance is a single node in this release, whatever the tier of the instance it was restored from.
• It accepts the same database users and passwords as the instance it was restored from, so your application's credentials work against it. Its root password is its own; reveal it like any instance's.
• It is billed as one node until you terminate it. Staging copies stay until you discard them.
• One staging copy at a time. Discard the current staging copy before starting another restore of the same instance.
• Watch its restore status. The new instance shows Waiting, then Restoring, then Ready. Use it only once it reads Ready. If a restore fails, the reason is shown on the instance; terminate it and try again.

Restores are started from the console or Reis. There is no Terraform resource for a restore, because a restore is an action, not a piece of infrastructure to keep in state.

Durability within an instance

Backups protect against mistakes — a dropped table, a bad migration, a buggy deploy. Failures are handled by the tier: a single node restarts from its own disk with every committed transaction intact, and an ha instance keeps a majority-acknowledged copy of every write across its group. See Tiers and replication.

Deleting an instance

Deleting an instance deletes its data. Take a dump of anything you want to keep, with your own tools, before you delete.