What is the 3-2-1 backup rule?

Keep at least 3 copies of your data, on 2 different kinds of storage, with 1 copy offsite. The point is that no single failure - a deleted file, a dead disk, a compromised server, a fat-fingered command - can take out every copy at once. The generated script writes a local copy and pushes an offsite copy to object storage, which covers the offsite leg most setups skip.

Why does the restore command matter so much?

Because a backup you have never restored is a guess, not a backup. The single most common backup failure is discovering during a real incident that the dumps are corrupt, incomplete, or impossible to import. The generator gives you the exact restore command alongside the backup, so you can test a restore today - before you need it for real.

Where should the offsite copy go?

Any S3-compatible object store works with the generated script via an endpoint URL: Cloudflare R2 and Backblaze B2 are popular because they charge little or nothing for egress, so getting your data back out in an emergency is not itself a bill. Keep the offsite copy in a different account or provider from your server, so a compromise of one cannot reach both.

Free tool · Runs in your browser · Nothing uploaded

Back it up. Then prove you can restore it.

A backup you've never restored is a guess. Fill in your database and an offsite bucket and get a real backup script — dump, compress, push offsite, prune — the cron to run it, and the restore command most setups never write down.

Database

Database name

App name (for filenames)

Schedule

Offsite bucket

S3-compatible endpoint

Keep local backups for (days)

backup.sh

cron

restore.sh

The backup nobody tested

Everyone means to set up backups. The ones who do usually stop at the dump — a cron job writing a file to the same disk as the database it's protecting, which a single dead drive or a wiped server takes out along with the original. The offsite copy and, above all, the restore are the parts that get skipped, and they're the parts that matter when something actually goes wrong.

This generates all three: a real script that pushes a copy off the box, a schedule, and the restore command so you can test it today instead of discovering at 4am that your dumps don't import. Setting it up is the easy part. Knowing it ran, that the offsite copy landed, and that the restore still works — every day, across every database — is the part you don't want to be doing by hand.

Related free tools

systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS RPO / RTO calculatorData loss + downtime Log rotation estimatorWhen logs fill the disk

All free tools →

A script backs up. A control plane proves it.

Infraveil runs the backups, verifies they landed, keeps a known-good copy ready to fail over to, and gives you a tamper-evident record that recovery actually works — across your whole backend, on infrastructure you own.

See how it works

Get the backup & recovery playbook

3-2-1 done right, restore testing, and recovery for a self-hosted backend. No spam.