Every time I set up database backups, I hit the same wall.
Create a cloud account. Generate API keys. Provision a bucket. Install pg_dump / mysqldump / mongodump on the server (or pray the versions match). Write a cron job. Hope the disk has enough space for a temp file. Wire up retention manually.
It works — until you have three databases, two regions, and someone asks "can we see the backup logs in real time?"
That's why I built BackSpace — a centralized backup management platform for containerized and traditional database infrastructure.
Running in production
This isn't a side project sitting idle. BackSpace is handling real backup workloads today:
| Metric | Value |
|---|---|
| Backup configs | 25+ |
| Total runs | 6,500+ |
| Available backups | 400+ |
| Success rate | 99%+ |
| Storage used | 3+ TB |
| Total backup size (stored artifacts, all-time) | 30+ TB |
30+ TB is the cumulative size of everything written to storage across 7,000+ runs — the actual backup artifacts, not the original database volume. Gzip compression is optional per config; some engines (e.g. xtrabackup) compress natively, others store logical dumps as-is. Where compression is in play, the raw data behind those dumps is typically 2.5–4× larger, depending on engine and content.
For remote execution, the platform runs three managed agents — one in each region: Europe (Frankfurt), US East, and Asia-Pacific (Singapore). Select Remote Execution and we handle the rest — the platform automatically assigns the closest available worker based on your database hostname.
For storage, pick BackSpace Storage as your storage profile — S3-compatible under the hood, but managed by us. No AWS account, no API keys, no bucket setup. Every upload is automatically mirrored across multiple independent cloud providers, so you get multi-cloud redundancy without secondary buckets or sync scripts.
What it does
BackSpace gives you one control plane to:
- Schedule and run backups across multiple databases
- Choose where backups land (built-in cloud storage, your own S3/SFTP, or local paths on an agent)
- Watch live logs while a job runs
- Enforce retention policies automatically
- Get alerts when something breaks
Under the hood it's a Go control plane (REST API + WebSocket agent protocol) and lightweight agents that execute backup jobs via Docker.
The core idea: Docker-in-Docker, zero host dependencies
BackSpace agents don't require database client tools on the host. The only hard requirement is Docker.
When a backup starts, the agent:
- Pulls the official database image for your engine and version (
postgres:16,mysql:8, etc.) - Spawns a short-lived container with the right dump tool (
pg_dump,mysqldump,mongodump,redis-cli,clickhouse-backup, …) - Attaches to stdout before the container starts (so fast jobs don't finish before streams are connected)
- Streams the output through memory buffers — gzip, optional Age encryption, SHA256 checksum — directly to storage
No scratch disk on the agent host. Data streams straight from the container to storage — it never touches the agent's disk. No version mismatch between host pg_dump and your production Postgres either.
Isolation is a feature, not an afterthought. Your host stays clean.
Two ways to run backups
BackSpace Agents (Remote Execution)
Pick BackSpace Agents (Remote Execution) when you don't want to install anything on your side.
BackSpace runs managed backup workers on the platform. When a job triggers, we automatically:
- Resolve the region from your database hostname
- Pick the least-busy managed worker in the closest region —
eu-frankfurt,us-east, orap-singapore - Dispatch the job over WebSocket
Your database needs to be reachable from our workers. Remote execution supports logical backups (pg_dump, mysqldump, mongodump, redis-cli). Physical/volume-based tools like pg_basebackup or xtrabackup require a self-hosted agent that can mount your data volumes.
Self-hosted Agent
For private networks, localhost-bound databases, or zero-trust setups — deploy a lightweight agent yourself:
services:
backspace-agent:
image: ghcr.io/backspaceguru/backspace-agent:latest
container_name: backspace-agent
restart: unless-stopped
environment:
- AGENT_ID=your_agent_id
- AGENT_TOKEN=your_agent_token
- AGENT_NAME=production-cluster-1
- BACKEND_URL=https://app.backspace.guru
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- backspace-data:/data
volumes:
backspace-data:
The agent connects outbound to the control plane over WebSocket. No inbound ports need to be opened on your firewall — the agent reaches your databases from inside your network.
If your DB is bound to 127.0.0.1, run the agent in network_mode: host and use 127.0.0.1 as the hostname in the UI.
Storage: built-in or bring your own
BackSpace Storage
Select BackSpace Storage as a storage profile when setting up a backup — it's available out of the box on every workspace. Under the hood it's S3-compatible, but you don't bring your own bucket or credentials. We handle the upload endpoint; behind the scenes every backup is mirrored across multiple independent cloud providers automatically.
This is the same infrastructure backing the 3+ TB of active storage on the platform today — redundancy is built in, not bolted on.
Optional Age encryption runs client-side before upload. Payloads stay encrypted in transit and at rest.
Your own endpoints
Prefer full control? Connect S3-compatible storage (AWS, MinIO, Cloudflare R2, Wasabi), SFTP, or local filesystem paths on the agent host. Same streaming pipeline, your bucket.
Supported databases
| Engine | Tools |
|---|---|
| PostgreSQL |
pg_dump, pg_dumpall, pg_basebackup (agent only) |
| MySQL / MariaDB |
mysqldump, mariadb-dump, xtrabackup (agent only), mariabackup (agent only) |
| MongoDB | mongodump |
| Redis |
redis-cli (RDB snapshots) |
| Valkey |
valkey-cli (RDB snapshots) |
| ClickHouse | clickhouse-backup |
ClickHouse has a dedicated execution path — clickhouse-backup manages its own upload, so the agent streams logs instead of capturing stdout.
What the control plane handles
You configure backups in a React dashboard. The backend takes care of the rest:
- Cron scheduling with retry/backoff
- Retention enforcement — old runs pruned automatically after each successful backup
- Live log streaming to the UI via WebSocket
- Notifications — Telegram, Discord, Slack, encrypted webhooks
- Statistics — success rates, throughput, storage consumption trends
Stuck jobs reconcile themselves. History stays the source of truth for every backup attempt.
Agents are stateless workers — all configuration, schedules, credentials, and run history live in the control plane.
Who is this for?
If you run databases in Docker, on VMs, or across multiple sites — and you're tired of duct-taping cron + shell scripts + cloud SDKs — BackSpace is built for that workflow.
Not a replacement for your DBA's disaster recovery playbook. A way to stop reinventing backup plumbing every time you add a database.
Try it
- App: app.backspace.guru
- Docs: docs.backspace.guru
- Landing: backspace.guru
Dashboard v1.4.1 is live. If you run self-hosted agents, update to v1.4.0+ for full BackSpace Storage compatibility.
I'm the founder — happy to answer questions about the architecture, agent protocol, or anything else in the comments.
Top comments (0)