Backups you can prove will restore.

Prove the restore, don't hope

Every backup tool takes backups. Almost none prove the backups restore — the failure mode of a backup system is silent data loss discovered only at restore time, during an incident, when it is far too late. TillArk’s headline feature closes that gap:

• Restore-verification as observability. On a cadence you set, TillArk restores a real backup into an ephemeral, network-isolated, per-tenant sandbox, asserts integrity (row counts, checksums, schema hash, manifest signature), records the real RTO, and emits green / red into TillPulse — then tears the sandbox down.
• Honest RPO / RTO. The recovery-point and recovery-time numbers are measured, live values per database, not a marketing promise. Being honest about the residual number is the feature.

The product’s promise — “your last N restores all passed, here is the proof” — is a monitored board, not a hope. See Backups & restore-verification.

A control plane and an agent

TillArk owns the control plane, not the bytes. A stateless control plane holds policy, the manifest/catalog, and the failover state machine — it is never in the data path and holds no plaintext backup data. A small agent runs in your environment, drives the engines locally, streams ciphertext straight to storage, and reports signed manifests back.

                     ┌──────────────────────────────────────┐
   TillAuth  (authz)  │        TillArk control plane          │
   TillSecrets (keys) │  policy · manifest/catalog · state    │ ──▶ TillPulse
   organizations(org) │  machine · failover · verification    │     (RPO/RTO,
                      └───────────────┬──────────────────────┘      verify green/red)
                                      │ mTLS + hybrid-signed commands
                          ┌───────────▼───────────┐
                          │  ark-agent  (your env) │ ← caches policy; acts if CP down
                          │  drives engines locally │
                          └──┬──────────┬───────────┘
                             │          │
                   ┌─────────▼──┐  ┌────▼─────────────┐
                   │ Engines     │  │ Cross-vendor      │
                   │ restic/WAL-G│  │ storage targets   │
                   │ /ch-backup  │  │ (S3/R2/MinIO,WORM)│
                   └─────────────┘  └──────────────────┘

Two front doors write the same catalog: the machine/agent API (tark_ tokens) and the human dashboard / CLI (session auth). The full picture — front doors, the manifest, three-tier durability, and the engines — is in Architecture.

Cross-vendor by default

A backup on the same vendor as your primary dies with your primary. TillArk enforces anti-affinity — a backup copy must live on a different provider and region than the source, while staying inside the same legal residency zone — and layers durability in three tiers:

Anti-affinity is residency-aware: cross-border replication that would violate a residency rule is refused, not silently done. More in Architecture and Failover.

Security is the spine, not a section

Backups are the single highest-value harvest-now-decrypt-later target that exists — comprehensive, long-retained, and an attacker only needs the ciphertext once. TillArk is designed accordingly:

• Client-side encryption. Data is encrypted inside the agent, in your environment, before it leaves — the storage vendor only ever sees ciphertext.
• Crypto-agility + post-quantum. Every envelope carries an algorithm-suite id, so primitives rotate without breaking old backups; the asymmetric parts move to hybrid classical + NIST-PQC.
• Verify before restore. Manifests are hybrid-signed; a restore verifies the signature before trusting a single byte.
• Whole weakness classes made absent. No shell string is ever built (command injection unreachable); every outbound URL is SSRF-validated and IP-pinned.

The full model — PQC stance, WORM / object-lock, separate credential domain, four-eyes approval, and the CWE coverage map — is in Security.

What's in the box

• Quickstart — register a source and a target, set a policy, run a backup, verify it, read the proof.
• Architecture — control plane vs agent, the two front doors, the manifest/catalog, three-tier durability, engines.
• Backups — backup, restore, restore-verification, RPO/RTO tiers, and GFS retention.
• Failover — the failover / failback state machine, fencing, quorum, and four-eyes approval.
• Security — crypto-agility, PQC, signed manifests, WORM, credential isolation, and the CWE map.
• CLI reference — every tilldev ark command.
• Agent — the self-hostable Go agent and its config.