Back up Supabase to Backblaze B2

Backblaze B2 is the price answer: the cheapest storage of the destinations in these guides, with an egress allowance generous enough that restores and restore drills are effectively free at backup scale. The setup has two B2-specific wrinkles — the master key does not work with the S3 API, and the credential names differ from what S3 tools expect. This guide covers both, plus the bucket and key click-paths, working CLI config, a weekly GitHub Actions schedule, and lifecycle housekeeping.

Why B2 — and what it costs

Three numbers, checked against Backblaze’s pricing page (July 2026):

• Storage at $6.95/TB-month — about $0.007/GB-month, less than half of R2 Standard’s $0.015 and less than a third of S3 Standard’s $0.023. A 10 GB project keeping ten snapshots — 100 GB — costs about $0.70/month. And the first 10 GB is always free: several retained snapshots of a free-tier Supabase database (capped at 500 MB) cost nothing at all.
• Egress free up to 3x your average monthly storage, then $0.01/GB — a ninth of S3’s $0.09/GB rate. For backups the ratio works strongly in your favor: the bucket stores your whole snapshot history, while a restore drill reads back only the latest snapshot. Keep ten snapshots and drill weekly, and you use well under half of the free allowance.
• No per-request or duration surprises. Class A, B, and C API calls — uploads, downloads, listing — are free, and there are no minimum storage duration fees, so deleting a week-old snapshot costs nothing extra. (Compare S3’s 30-day minimum on Standard-IA or R2 Infrequent Access’s 30-day minimum plus retrieval fee.)

The honest counterweights. Backblaze raised this price on May 1, 2026 — from $6 to $6.95/TB-month — so treat “cheapest” as a fact with a date on it. R2’s zero egress is unconditional where B2’s is an allowance (generous for backups, but an allowance) — the R2 version of this guide covers that path, and the S3 version the everything-already-on-AWS case. And cheap storage does not touch the other side of the pipe: a backup still pulls data out of Supabase, which counts against your Supabase plan’s egress allowance — the GitHub Actions guide walks through that math.

Step 1 — create the bucket

B2 console → Buckets → Create a Bucket, with files set to private — a backup bucket has no business being public. Bucket names are globally unique across B2, so my-backupswill likely need a suffix of your own. After creation, the bucket’s detail page shows an Endpoint value of the form s3.<region>.backblazeb2.com — note it, both the CLI endpoint and region come from it.

Step 2 — create an application key (not the master key)

Application Keys → Add a New Application Key, with Read and Write access, scoped to your bucket — not all buckets. Scoped credentials are the difference between a leaked key exposing one backup bucket and exposing everything on the account.

The B2-specific catch: the master application key does not work with the S3-compatible API. If you point an S3 tool at B2 with the master key and get authentication errors, this is why — create a standalone application key and use that instead.

Step 3 — map keyID and applicationKey to S3 credentials

B2 keeps its own credential names in the console; every S3-compatible tool asks for the same two values under different labels. The mapping:

keyID          → Access Key ID
applicationKey → Secret Access Key   (shown only once, at creation)

Endpoint:   https://s3.<region>.backblazeb2.com   (from the bucket page)
Region:     the <region> part, e.g. us-west-004

The region is not chosen separately — it is embedded in the endpoint hostname. If your bucket page says s3.us-west-004.backblazeb2.com, the region is us-west-004. The backupdrill CLI defaults to path-style addressing whenever an endpoint is set, which B2 accepts — no extra switch needed.

Step 4 — point the CLI at B2 and run the first backup

The open-source backupdrill CLI (MIT, github.com/backupdrill/cli) dumps the database with pg_dump, optionally copies your Storage files, and writes a checksummed manifest.json next to the dump. Configure it with env vars:

export BACKUPDRILL_DATABASE_URL="postgresql://postgres.<ref>:<pw>@aws-0-<region>.pooler.supabase.com:5432/postgres"
export BACKUPDRILL_PROJECT_NAME="my-app"
export BACKUPDRILL_S3_ENDPOINT="https://s3.<region>.backblazeb2.com"
export BACKUPDRILL_S3_REGION="us-west-004"      # the <region> part of your endpoint
export BACKUPDRILL_S3_BUCKET="my-backups"
export BACKUPDRILL_S3_ACCESS_KEY_ID="…"         # B2 keyID
export BACKUPDRILL_S3_SECRET_ACCESS_KEY="…"     # B2 applicationKey

npx backupdrill backup

The connection string is the Session Pooler URI from the Connect button at the top of the Supabase dashboard — the default postgres user in it works as-is. Or keep the non-secret parts in a config file (backupdrill.config.json, gitignored in the CLI repo’s template) and the secrets in env vars:

{
  "databaseUrl": "postgresql://postgres.<ref>:<password>@aws-0-<region>.pooler.supabase.com:5432/postgres",
  "projectName": "my-app",
  "schemas": ["public"],
  "storage": {
    "endpoint": "https://s3.<region>.backblazeb2.com",
    "region": "us-west-004",
    "bucket": "my-backups",
    "accessKeyId": "PUT-IN-ENV-OR-HERE",
    "secretAccessKey": "PUT-IN-ENV-OR-HERE",
    "prefix": "backupdrill",
    "forcePathStyle": true
  }
}

npx backupdrill backup --config backupdrill.config.json

To capture Supabase Storage files in the same snapshot — which you want, because a database restore alone does not bring files back — also set the four BACKUPDRILL_SUPABASE_STORAGE_* variables with keys from Dashboard → Storage → Settings → S3 Access Keys. When the run finishes, the bucket holds a timestamped snapshot: dump.pgcustom, manifest.json, and a storage/ tree if Storage is configured.

Step 5 — schedule it with GitHub Actions

A backup you run by hand is a backup that stops the week you get busy. The GitHub Actions guide has the complete workflow file and the Supabase egress arithmetic; the B2 specifics are just the repository secrets. Required: BACKUPDRILL_DATABASE_URL, BACKUPDRILL_S3_BUCKET, BACKUPDRILL_S3_ACCESS_KEY_ID (the keyID), BACKUPDRILL_S3_SECRET_ACCESS_KEY (the applicationKey). For B2, also set BACKUPDRILL_S3_ENDPOINT to your https://s3.<region>.backblazeb2.com endpoint and BACKUPDRILL_S3_REGION to the <region> part.

Housekeeping: prune old snapshots with a lifecycle rule

B2 buckets keep every file version by default, so old snapshots accumulate until something deletes them. B2’s lifecycle rules are prefix-scoped and work in two steps — hide, then delete: a rule on the backupdrill/prefix (the CLI’s default key prefix) with daysFromUploadingToHiding set to your retention window and daysFromHidingToDeletingset to 1 hides each snapshot when it ages out and deletes it a day later. Because B2 has no minimum storage duration fees, pruning early costs nothing extra — and one warning from Backblaze’s own docs is worth repeating: a rule with an empty prefix matches the whole bucket, so scope it.

Prove it restores

A snapshot in B2 is a file, not a recovery plan — the only way to know it restores is to restore it. Run backupdrill drill to pull the latest snapshot into a throwaway Docker Postgres and verify it against the manifest, or walk through the full restore-testing guide — on B2, a drill reads back one snapshot against an allowance of 3x everything you store, so drilling weekly costs nothing in egress.

FAQ