Boom Media
Backblaze B2 — Offsite Backup Setup

Back up the one thing you can't rebuild: your data.

Your code is already safe in GitHub. This guide wires your shared Supabase Postgres — every SaaS, client, and user record — to offsite, encrypted, versioned backups on Backblaze B2.

Account created · Bucket: boom-media-backups · 2026-07-09
The Picture

What's protected, and where

Three layers. GitHub and Bunny already cover two of them. B2 closes the critical gap — the database.

💻
Code
All SaaS + client-site repos, version-controlled & offsite.
✅ Safe in GitHub
🗄️
Database + user data
Shared Supabase Postgres — the only copy of every tenant's data. Cannot be recreated.
⬅️ Backing up to B2 now
🎬
Video / media
Client videos on Bunny Stream; re-uploadable from source.
✅ Covered
🔴 Why this is urgent: a dropped table, a bad migration, or a ransomware hit on the droplet would wipe every tenant's data at once — because it's all in one shared Postgres. GitHub does not protect this. B2 does.
Step 1 · In Backblaze

1Create the bucket

B2 Cloud Storage → Buckets → Create a Bucket.

FieldSet toWhy
Bucket Nameboom-media-backupsGlobally unique; if taken, add a suffix
Files arePrivateNever public for backups
Default EncryptionEnable (SSE-B2)Free at-rest encryption
Object LockOptional — enable for ransomware immunityMakes backups immutable; harder to undo, so optional for v1
📝 After creating, note the Endpoint (e.g. s3.us-west-004.backblazeb2.com) and Region (e.g. us-west-004) — both needed for wiring. Region is irrelevant to backup performance; take the default.
Step 2 · In Backblaze

2Create a scoped Application Key

Application Keys → Add a New Application Key. Scope it to just this bucket — least privilege.

FieldSet to
Key Namecoolify-backup
Allow access to Bucket(s)boom-media-backups only
Type of AccessRead and Write
File prefix / durationLeave blank
⚠️ The applicationKey is shown ONCE. Copy both keyID and applicationKey straight into your password manager. Never paste them into chat, code, or git.
Step 3 · On Coolify

3Wire the backup — pick your path

Which path depends on how your Supabase Postgres runs on boom-hosting (24.199.95.101). If unsure, check whether Postgres appears as a managed Database resource in Coolify or as part of a compose/service stack.

Path A — Coolify-managed DB

Postgres is a Coolify Database resource

Use Coolify's built-in scheduled S3 backup. In the DB resource → Backups → add S3 destination:

# S3 destination fields
Endpoint: https://s3.us-west-004.backblazeb2.com
Region:   us-west-004
Bucket:   boom-media-backups
Access Key: <keyID>
Secret Key: <applicationKey>
Schedule:   0 * * * *   # hourly

Coolify runs the dump and the upload. Done.

Path B — compose / service PG

You keep your own pg_dump cron

Add rclone to ship each dump to B2:

# one-time: configure rclone remote
rclone config   # type: b2 → keyID + appKey

# in your hourly backup script, after pg_dump:
rclone copy /backups/pg-$(date +%F-%H).sql.gz \
   b2:boom-media-backups/postgres/

Keeps your existing dump; rclone handles offsite copy.

Step 4 · Retention

4Auto-prune old backups

Without retention, hourly dumps pile up forever. Set a Lifecycle Rule on the bucket (Backblaze → bucket → Lifecycle Settings) or configure it in Coolify's backup retention.

KeepForPurpose
Hourly dumps48 hoursRecover from a recent mistake
Daily dumps14 daysCatch issues found days later
Weekly dumps8 weeksLonger-horizon safety net
💾 This keeps you comfortably inside the free 10 GB for a while — DB dumps are small and compress well. Matches the retention plan already in SaaS/Coolify/BACKUPS.md.
Step 5 · The step everyone skips

5Test a restore

A backup you've never restored is a hope, not a backup. Do this once now, and once a quarter.

# 1. Pull the latest dump back down
rclone copy b2:boom-media-backups/postgres/<latest>.sql.gz ./restore-test/

# 2. Restore into a throwaway scratch database
gunzip -c restore-test/<latest>.sql.gz | psql "postgres://.../scratch_db"

# 3. Spot-check: row counts, a known record, recent data present
# 4. Drop the scratch db. You now KNOW restores work.
Per-tenant restore works the same way: restore the full dump to a scratch DB, then copy just that org/user's rows back into production. No per-app backup job needed — one shared dump covers every tenant.
Done When

Setup checklist

(Ticks save in your browser.)