Skip to content

CONCEPT Cited by 1 source

Backup encryption at rest

Definition

Backup encryption at rest is the property that backup artifacts stored in object storage (S3, GCS, Azure Blob) are stored in encrypted form, decrypted only when restored onto a backup-consuming server. The encryption key is separate from the object store's own at-rest encryption (which protects the bucket-as-a-whole) and is specific to the backup payload.

Why it matters

  • Blast radius of object-store compromise. Even if an attacker gains bucket read access (misconfigured IAM, leaked credentials), encrypted backups are not directly readable.
  • Compliance. Many regulated deployments require per-artifact encryption-at-rest as distinct from object-store-provided encryption.
  • Defence-in-depth. Encrypted backups compose with encrypted connections (TLS in-transit) and encrypted primary storage to produce end-to-end encryption across the backup pipeline.

In PlanetScale

Per the 2024-07-30 post (Source: sources/2026-04-21-planetscale-faster-backups-with-sharding), backups in S3 / GCS are encrypted at rest: "Existing backups are encrypted at rest, so they are decrypted upon arrival."

The decryption happens on the ephemeral VTBackup instance when fetching the previous backup for catchup — the encrypted bytes leave S3/GCS, are decrypted in VTBackup memory, and are written to local disk as decrypted InnoDB files.

Mechanism (typical)

Standard backup-encryption-at-rest composes a symmetric cipher (AES-256-GCM) with a key-management service (KMS):

  1. Backup worker encrypts backup payload with a per-backup data-encryption key (DEK).
  2. DEK is wrapped with a KMS master key.
  3. Wrapped DEK is stored alongside the encrypted backup.
  4. Restore reverses the flow: fetch encrypted backup + wrapped DEK, unwrap DEK via KMS, decrypt backup payload.

The PlanetScale post doesn't disclose the specific mechanism — but the invariant ("decrypted upon arrival") implies a per-backup key that can be used and then discarded without needing to decrypt any other backup.

Caveats

  • Key-rotation blast-radius. If the DEK wrapping key is compromised, every backup encrypted with it is compromised unless re-wrapped.
  • Performance cost. Encryption adds CPU overhead on the backup worker + decryption overhead on the restore worker. At shard-parallel scale this is paid N-way in parallel.
  • Compatibility. Encrypted backups must be restorable by any tool that would consume them; ad-hoc tools reading from S3 directly need the decryption key and capability.

Seen in

Last updated · 347 distilled / 1,201 read