Skip to content

SYSTEM Cited by 1 source

VTBackup

What it is

VTBackup (Vitess docs) is the Vitess program that orchestrates a per-shard backup on a dedicated ephemeral MySQL instance rather than on the production primary or an existing replica. It is the canonical primitive behind the dedicated-backup-instance-with-catchup-replication pattern and the substrate that makes shard-parallel backup operationally viable at PlanetScale.

What it does

Per the 2024-07-30 PlanetScale post (Source: sources/2026-04-21-planetscale-faster-backups-with-sharding), VTBackup runs on a fresh compute instance spun up in the same cluster as the shard's primary and replicas, and executes the following choreography:

  1. Restore the previous backup (if one exists — the common case) from Amazon S3 or Google GCS. Uses the Vitess builtin backup policy. Backups are decrypted on arrival.
  2. Spin up a new MySQL instance on the restored data.
  3. Connect that MySQL to the primary VTGate and replicate the delta: "It will request a checkpoint in time, and then all changes between the last backup and the checkpoint will be replicated. This is typically a very small % of the total database size."
  4. Stop the catchup-replication MySQL once caught up.
  5. Run the regular Vitess backup workflow, storing the new full backup to S3/GCS.

The resulting backup is a consistent-as-of-checkpoint snapshot of the shard's data, produced without reading full-DB contents from any production node.

Why it shows up on this wiki

VTBackup is the canonical wiki instance of the off-primary backup architecture — the production choice PlanetScale makes to protect the primary from backup-induced load while still producing consistent backups. The dedicated-instance approach trades compute (one ephemeral MySQL per shard per backup cycle) for primary-side isolation.

It's also the composition primitive under concepts/shard-parallel-backup: because each shard's VTBackup runs on its own ephemeral instance, backups across shards are trivially parallel — no shared resources, no coordinator bottleneck.

Backup engine

PlanetScale uses the Vitess builtin backup engine (physical backup — raw InnoDB data files) rather than the Vitess 21 experimental mysqlshell engine (logical backup — SQL-replayable dumps). Per the post: "Internally, PlanetScale uses the builtin backup engine since it works well for our backup procedure." Self-managed Vitess clusters can swap in other engines per the Vitess backup docs.

Storage backend

Backups are stored in Amazon S3 or Google GCS depending on which cloud the database cluster resides in. All backups are encrypted at rest.

Replication source

VTBackup replicates from the primary VTGate for catchup, not from a replica. The primary-as-source decision is explicit and trade-off-aware: "If taken from a primary, it will have the most up to date information. If taken from the replica, we avoid sending additional compute, I/O, and bandwidth demand to the primary server. However, in our case, the primary is already performing replication to two other nodes. Also, unless it is the first backup, the primary does not need to send the full database contents to the backup server. It only needs to send what has changed since the last backup, ideally only 12 or 24 hours prior."

Compose with

Seen in

  • sources/2026-04-21-planetscale-faster-backups-with-sharding — canonical wiki disclosure. Names VTBackup as the Vitess program behind the seven-step per-shard backup. Verbatim: "This instance will handle running VTBackup, which manages the backup process." Measured throughput: ~210 MB/s per VTBackup instance at 32-shard scale, ~137 MB/s at 256-shard scale. Used with the builtin backup engine + S3/GCS storage + primary-VTGate replication source.
Last updated · 347 distilled / 1,201 read