A backup you've never restored is a hope, not a backup.
Your backups run every night. Restorable proves they'd actually restore. On a schedule, it restores your latest restic snapshot into a disposable sandbox, verifies the data actually works — files present, databases load, the real app boots — then destroys the sandbox and tells you the result.
$ restorable test
restorable: PASS
repo: /srv/backups/restic
snapshot: cd10c302
duration: 5.5s
restore: 4.1s
checks:
✓ nextcloud/files (3922ms): 2 required path(s) present, 5 sampled checksum(s) match repository
✓ nextcloud/sqlite (18ms): "data/owncloud.db" passes integrity_check
Works fully standalone — single binary, no account, cron-friendly exit codes. Because every test is a real restore, you also get your measured recovery time — how long being back online actually takes, not a guess. An optional cloud dashboard adds scheduling history, recovery-time tracking, stale-backup detection, and alerts (Telegram, Discord, ntfy, email).
Everyone runs backups. Almost nobody restore-tests them — so nobody finds the corrupted repository, the config file that fell out of the backup set, or the database dump that stopped being written, until the day they need it back. Restorable turns that catastrophic future discovery into a mundane notification.
Requirements: Linux or macOS, restic, and an existing restic repository.
1. Install:
curl -fsSL https://raw.githubusercontent.com/restorable-dev/restorable/main/install.sh | sh(Or grab a binary from releases — static, no dependencies.)
2. Set it up — restorable init inspects your backup and writes the config for you:
export RESTIC_PASSWORD=… # or point password_env at your own variable
restorable init --repo /srv/backups/resticIt recognizes SQLite databases, SQL dumps, and apps like Nextcloud,
Vaultwarden, and Immich, then writes an agent.yaml and a starter recipe
asserting their critical files — and offers to run the first test on the spot.
Review the recipe (it's yours to edit), and you're done.
Prefer to hand-write it? A recipe is just declarative YAML:
name: my-app
checks:
- type: files
require:
- path: config/config.php # this file must restore
- path: data/
min_files: 100 # this dir must hold ≥100 files
checksum_sample: 5 # verify 5 restored files byte-for-byte3. Test:
restorable testExit codes: 0 verified · 1 verification failed · 2 could not test.
Put restorable test in cron, or run restorable run as a daemon with a
schedule in the config. That's it.
| Check | Proves |
|---|---|
files |
Required paths restored; minimum file counts; sampled files hash identically to repository content |
sqlite |
Database passes PRAGMA integrity_check (in-process, read-only) |
postgres |
A pg_dump in the backup loads into a throwaway postgres container; row-count assertions hold |
mysql |
Same, for mysqldump |
docker-app |
The real app image boots against restored data and answers HTTP health checks |
Ready-made recipes for Nextcloud,
Vaultwarden, and Immich
ship in /recipes. Database and app checks need Docker; files
and sqlite don't.
- Read-only against your repository. The agent shells out to your
restic and can only run
version,snapshots,ls,restore,check,dump— the whitelist is enforced in the type system;forget/pruneare a compile error, not a code-review promise. - Sandboxes are always destroyed — on success, failure, and panic. Disk space is checked before any restore begins.
- Your data never leaves your machine. Standalone mode talks to nobody. Cloud mode reports only pass/fail metadata: a repository fingerprint (SHA-256 of the credential-scrubbed location), snapshot IDs, check results, timings. Never file contents, never passwords. The agent is pull-based over HTTPS and listens on no ports.
The hosted dashboard adds run history across repos, alerting on failure, stale-backup detection (fires when your testing silently dies — the meta-failure). Free tier: 1 repo, monthly tests, 1 alert channel. Pro ($8/mo or $80/yr): unlimited repos, any schedule, all channels, 12-month history (monthly confidence reports coming soon). The agent works forever without it.
Configuration · Commands · files · databases · docker-app · Alerts · Cloud
git clone https://github.com/restorable-dev/restorable && cd restorable/agent
go build -o restorable .Repo layout: /agent Go agent · /web control plane
(Next.js + Supabase) · /recipes shipped recipes ·
/docs documentation.
MIT. The agent is and stays open source — it's the point.