RELIABILITY

Restores you don't have to be afraid to run.

BCE runs on a self-hosted server — no managed database service quietly backing things up. If a drive fails or a deploy goes wrong, recovery is entirely on whatever backup system exists. This one is built so that running a restore is never a leap of faith.

PythonDjangoCeleryDocker
BCE / Restore Point — Pending Approval
Database backupbce_db_2026-07-14_0300 · 340 MB · SHA256 verified
✓ Verified
Media backupbce_media_2026-07-14_0300 · 2.1 GB · 4,812 files
✓ Verified
Pre-restore safety backupAuto-created before this restore runs
Enabled
StatusRestore database + media, independently selectable
Awaiting CEO approval
The Result

Every backup is independently restorable and verified, with an automatic safety snapshot and required CEO approval before anything gets overwritten.

The Breakdown

No Formal Backups

Recovery meant hoping, not knowing

Verified & Restorable

Checksummed, independent, approved

A Safety Net That Works

Every restore has a rollback path

The Problem

The original setup had no formal backup process — recovery meant manually dumping the database and hoping nobody needed the media files. Worse, a naive "unified" backup would force restoring the database and media together even when only one had actually gone wrong, and any restore was a one-way door: if it went badly, there was nothing to roll back to.

What I Built

Database and media backups stay as separate models — checksummed, compressed, and independently verified — but a RestorePoint ties them together for a given recovery operation, letting the CEO restore the database, the media, or both, independently. Before any restore runs, the system automatically creates a fresh safety backup of whatever's about to be overwritten, and the whole operation requires explicit CEO approval before it executes.

Process

How it works.

01

Back up independently

Database backups run with SHA256 checksums and compression tracking; media backups copy files with per-file verification and a log of anything that failed. Both run as Celery tasks, on a schedule or on demand.

02

Request a restore

The CEO picks which backup(s) to restore — database, media, or both are independent choices — and whether to clear existing media or merge with it.

03

Safety net first

Before touching anything, the system creates its own pre-restore backup of the current state — enabled by default — so a bad restore has something to roll back to.

04

Approve, then execute

A CEO has to explicitly approve the restore point before it runs. Progress is tracked step by step, and if it fails partway through, the system can roll back using the safety backup it just made.

Outcome
2
INDEPENDENT BACKUPS
DB & MEDIA, VERIFIED
Auto
SAFETY BACKUP
BEFORE EVERY RESTORE
1
APPROVAL GATE
CEO SIGN-OFF REQUIRED
Why it matters

The scary part of any restore isn't the backup — it's the moment you overwrite something you can't get back. Making the safety backup automatic instead of optional, and putting a CEO approval step in front of the button, turns "hope this works" into a recoverable decision either way.