Zero-Downtime Database Backups to Cloudflare R2 and AWS S3

A common operational nightmare for database administrators is database locking during scheduled backup windows. Running mysqldump without strict non-blocking flags or taking uncoordinated filesystem copies can lock incoming e-commerce checkouts for several minutes.

In this deep dive, we walk through how Rubuz conducts zero-downtime database snapshots streamed straight to Cloudflare R2, AWS S3, or Wasabi object storage.

The Flaw in Legacy mysqldump

By default, legacy backup scripts execute:

mysqldump --all-databases > dump.sql

On busy databases, this statement acquires a global read lock via FLUSH TABLES WITH READ LOCK, freezing all write transactions (INSERT, UPDATE, DELETE) until table dumping concludes.

The Rubuz Snapshot Architecture

Rubuz uses a multi-tier streaming pipeline:

1. Transactional Snapshotting: For InnoDB and PostgreSQL tables, Rubuz sets up single-transaction MVCC read views (--single-transaction), allowing concurrent write queries to continue uninterrupted.
2. On-the-Fly Compression: Dumps are compressed using multi-threaded zstd streaming directly in memory.
3. AES-256 Client-Side Encryption: Backups are encrypted with private keys before the bytes ever leave your server.
4. Direct S3 Multipart Upload: Chunks are streamed to your S3 bucket without writing massive temporary archive files to server disks.

Database Engine (MariaDB / Postgres)
  └── MVCC Read Stream (Zero Table Locks)
        └── Memory Compression (zstd Level 3)
              └── AES-256-GCM Encryption
                    └── S3 / R2 Direct Multipart Upload

Instant One-Click Restores

Every backup bundle contains point-in-time WAL (Write-Ahead Log) replication markers. With a single click in your Rubuz dashboard, you can roll back a corrupted database or clone it into a separate staging environment in seconds.