AWS Backup

AWS Backup is Amazon's managed service for backing up AWS resources such as RDS and Aurora databases, file systems and S3 buckets on a schedule, and a driver behind backup. AWS runs and stores the backups; MainSDK reads your backup settings, checks they can meet the RPO and RTO you declare, and runs timed restore drills into a scratch environment as signed evidence for auditors. Pick it when your Postgres and files already live on AWS.

backup:
  driver: aws-backup

Before you start

You need an AWS account with your database (for example Amazon RDS or Aurora for Postgres) in it.

1. Create a backup vault in each region your data lives in. A vault holds recovery points and is encrypted with a KMS key. AWS Backup Vault Lock can make recovery points immutable for the retention period.
2. Create a backup plan with a schedule and retention that fit your targets, and turn on continuous backup for point-in-time restore where your resource supports it.
3. Assign your resources to the plan, by resource or by tag.
4. Copy off-site by adding a copy rule to another region or account, if your policy calls for it.
5. Give MainSDK read access. It needs an IAM role that can read the plan and vault settings, and for drills, restore into a scratch target. How the driver authenticates, locally and in CI, is not specified yet.

Configure

Declare your targets. Your database stays on its own db driver.

db:
  driver: postgres
  regions: { us: secret:DB_US, eu: secret:DB_EU, in: secret:DB_IN }   # suggested names
backup:
  rpo: 15m
  rto: 1h
  keep: 35d
  drill: { every: 30d, to: scratch }

How you select AWS Backup as a separate backup driver, rather than the backup capability of your db driver, is not specified yet.

Use it

import { runDrill } from "mainsdk/backup";

const result = await runDrill({ driver, declared, app: "my-app", at: new Date(), to: "scratch" });   // restores into scratch, never production

mainsdk drill restore --to scratch runs the same drill from the command line and signs the evidence.

Local development and testing

Restores need a real provider, so the drill is your test. Run it on a schedule in your own CI:

npx mainsdk drill restore --at "2027-07-01T10:00:00Z" --to scratch

The drill restores into a new scratch database, times it against rto, verifies row counts or checksums, and tears the scratch environment down. Drills are free locally and in your CI.

What MainSDK adds on top

• mainsdk check reads your plan and vault settings and fails with a MAIN-BACKUP- finding naming the setting to change when they can't meet your RPO or RTO.
• Timed restore drills into scratch, signed as evidence that mainsdk assure includes for SOC 2, ISO 27001 and PCI DSS.
• The trust badge turns amber when no drill passed in 30 days.
• MainSDK never runs or stores backups itself; AWS does.

See Backups and restore drills for the full contract.

Limits and notes

• aws-backup comes with the backup-restore-evidence spec (phase 3, milestone 1.2). The MAIN-BACKUP- code numbers are not assigned yet.
• Keep each region's vault in that region. AWS has regions in the US, the EU and India, which match MainSDK's three.
• Per-tenant restore, not only all or nothing, is part of the interface; how it maps to AWS recovery points is not decided yet.
• Erasing one person from backups works by deleting their key through keys, not by editing recovery points.

Swap to or from it

db:
  driver: neon   # was postgres on RDS; point-in-time recovery comes from Neon

FAQ

Does MainSDK copy my backups anywhere? No. Backups stay in your AWS vaults. MainSDK reads settings, runs drills and keeps the evidence.

Can a drill restore over production? No. Drills restore only into a new scratch database.

Next

• Backups and restore drills and Data and records
• Postgres, Neon and pgBackRest
• AWS KMS

Open questions