Backups you can prove will restore.
TillArk backs up your databases and files to storage on a different vendor than the one they run on, and proves each backup restores by restoring it on a schedule. It runs proven engines (restic, WAL-G, pgBackRest and clickhouse-backup) rather than a new one, and it is part of TillDev: one workspace, one sign-in, one audit trail.
Prove the restore, don't hope
A backup that won’t restore is usually discovered during the incident that needed it. TillArk closes that gap:
- Restore verification. On the cadence you set, your agent restores a backup into a throwaway server on its own host and runs the checks for that source type: the manifest signatures, content hashes, row or key counts, the schema hash. The backup is marked verified only when every check passes, the restore time is recorded, and the server is removed. A failed verification shows on the dashboard and in your notifications.
- A measured recovery point. Each source shows the newest moment a restore could bring back right now, from its newest restorable backup or, for PostgreSQL with WAL-G or pgBackRest, from how far its WAL archive reaches. When it falls behind the objective you set, the source turns red and you are notified.
See Backups & restore-verification for the checks per source type.
A control plane and an agent
The control plane holds policies, the catalog of backups and their signed manifests, and the verification schedule. It is never in the data path. The agent runs on your host, backs up and restores with the engines, encrypts before upload and sends the backup straight to your storage.
┌──────────────────────────────────────┐
dashboard · CLI │ TillArk control plane │
· API tokens ──▶ │ policies · placement · catalog │
│ verification · recovery point │
└───────────────┬──────────────────────┘
│ HTTPS · tark_ token
│ credentials sealed to one approved agent
┌───────────▼────────────┐
│ ark-agent (your host) │
│ claim → run → sign │
└──┬──────────┬───────────┘
│ │
┌─────────▼──┐ ┌────▼───────────────┐
│ Engines │ │ Storage targets │
│ restic │ │ S3 · R2 · B2 · GCS │
│ WAL-G │ │ Azure · MinIO │
│ pgBackRest │ │ Wasabi · SFTP │
│ clickhouse- │ │ │
│ backup │ │ │
└─────────────┘ └────────────────────┘The full picture is in Architecture.
A copy the failure can't reach
A backup on the same vendor as your database can go down with it. A policy can require its copies to sit on a different provider and region than the source, inside the residency zone you name, and on as many distinct failure domains as you ask for.
| Layer | Defends against |
|---|---|
| Copies on another vendor | Losing the database, the cloud account or the vendor |
| Object lock | A stolen storage key deleting your copies; the agent confirms the lock before every write |
| GFS retention | Corruption you only notice days later |
| Continuous WAL archive | Losing the writes since the last backup (PostgreSQL) |
| Restore verification | A backup that exists but would not restore |
For PostgreSQL with replicas, the Failover page also watches three durability tiers for committed writes: a synchronous replica, a replica on another provider that could take over, and the continuous WAL archive. When one lapses, an alarm opens.
Built as if the attacker has the bucket
- Encrypted in the agent. Your storage provider only ever holds ciphertext.
- Post-quantum where it counts. Credentials reach an agent sealed with ML-KEM-768 and X25519, and manifests are signed with ML-DSA-65 and Ed25519.
- Verified before restore. The agent checks a backup’s manifest before it reads a byte of it.
- Two people for a real restore. A restore over a live source needs a second owner or admin to approve it.
The full model is in Security.
What's in the box
- Quickstart: a target, an agent, a source and a policy, then a verified backup.
- Agent: install, run as a service, settings, and the tools each source type needs.
- Backups: schedules, verification, restores, point-in-time recovery, recovery point, retention and limits.
- Policy files: every policy in one file you review like code; plan a change, then apply it whole.
- Architecture: the control plane, the agent, runs, placement and engines.
- Ransomware canary: spotting a source being encrypted from its backups.
- Signals and alerts: every recovery event, and alarms when an objective slips, sent to Slack, Teams, email, PagerDuty or a webhook.
- Masked clones: a copy of production data with personal data scrubbed, for development.
- Security: keys, signatures, object lock and approvals.
- CLI reference: every
tilldev arkcommand. - Failover (preview): fenced promotion of a replica.
Start with the Quickstart.