TILLARK · CLI

tilldev ark — the full command surface.

PREVIEW

TillArk lives inside the one tilldev CLI. Every group takes --json, secrets are read from a prompt or stdin (never bare on argv), and the dangerous verbs (restore, failover) demand a four-eyes approval.

01Shape

Command groups

text
tilldev ark <group> <verb> [flags]

  sources     register / list the resources you protect
  targets     register / list cross-vendor storage destinations
  policies    schedule + retention + RPO/RTO + verify cadence
  backups     list the catalog · queue a run
  verify      non-destructive restore-verification
  restore     real, four-eyes-gated restore INTO a source
  restores    restore + verification history
  failover    status · promote · failback
  replicas    list replicas across the org
  tokens      tark_ control-plane tokens (hash-only, shown once)
  audit       the append-only compliance trail

  --json everywhere · secrets via prompt / --*-stdin (never on argv)

The CLI talks to the dashboard API (/api/ark/*) over HTTPS only, the same front door the web dashboard uses. Reads work for any org member; writes need owner/admin; dangerous verbs additionally need the approval flags below.

02sources

Sources — what you protect

bash
tilldev ark sources ls
tilldev ark sources create --name <n> --type <postgres|mysql|mongo|clickhouse|meili|redis|object> \
                           --provider <neon|rds|supabase|self|s3|r2|…> \
                           [--region <r>] [--residency <zone>] [--unmanaged] [--with-dsn]
tilldev ark sources get <id>
tilldev ark sources rm <id>
FlagMeaning
--typepostgres · mysql · mongo · clickhouse · meili · redis · object
--providerWhere the source lives (neon, rds, supabase, self, or an object-store provider).
--residencyLegal residency zone (default global) — enforced by anti-affinity.
--unmanagedMark a self-managed source (default is managed).
--with-dsnPrompt for the connection string (hidden); stored envelope-encrypted, never returned.
03targets

Targets — where backups land

bash
tilldev ark targets ls
tilldev ark targets create --name <n> --provider <s3|r2|b2|wasabi|gcs|azure|minio|sftp> \
                           [--bucket <b>] [--endpoint <url>] [--region <r>] [--residency <zone>] \
                           [--lock-days <n>] [--mutable] [--credential-domain <d>] [--with-creds]
tilldev ark targets get <id>
tilldev ark targets rm <id>
FlagMeaning
--providers3 · r2 · b2 · wasabi · gcs · azure · minio · sftp
--lock-daysObject-lock (WORM) window in days — backups can’t be deleted or overwritten within it.
--mutableOpt out of immutability (default is immutable).
--credential-domainThe isolated credential domain that owns delete rights (ransomware resilience).
--with-credsPrompt for the provider credentials JSON (hidden); stored envelope-encrypted, never returned.
04policies

Policies — schedule, retention, SLOs

bash
tilldev ark policies ls [--source <id>]
tilldev ark policies create --source <id> \
    [--name <n>] [--cron "<expr>"] [--rpo <sec>] [--rto <sec>] [--verify-cron "<expr>"] [--byok] \
    [--keep-last <n>] [--keep-hourly <n>] [--keep-daily <n>] \
    [--keep-weekly <n>] [--keep-monthly <n>] [--keep-yearly <n>]

--cron sets the backup schedule and --verify-cron the restore-verification cadence. The --keep-* flags define GFS retention; an all-zero retention is rejected.

05backups

Backups, verify, restore

bash
tilldev ark backups ls [--source <id>]
tilldev ark backups run --source <id> [--policy <id>]

# Restore-verification (non-destructive) + history:
tilldev ark verify <backup-id>
tilldev ark restores [--backup <id>]

# A real, destructive restore is four-eyes gated and destination-allowlisted:
tilldev ark restore <backup-id> --into <source-id> \
    --approved-by <second-approver-uuid> --approval-ref <ticket>
restore is four-eyes gated
ark restore is destructive. It requires --into (an allowlisted registered source in your org), plus --approved-by (a different owner/admin’s user id) and --approval-ref. The server re-verifies the approver. ark verify is non-destructive and needs none of this.
06failover

Failover & replicas

bash
tilldev ark failover status --source <id>
tilldev ark failover promote --source <id> [--to <node>] \
    --approved-by <uuid> --approval-ref <ticket>
tilldev ark failover failback --source <id> [--lag <sec>] \
    --approved-by <uuid> --approval-ref <ticket>
tilldev ark replicas

promote and failback are both four-eyes gated. status shows the current failover state plus the replica set and their lag; the full model is on the Failover page.

07canary · clone

Ransomware canary & PII-scrubbed clones

bash
# Ransomware canary — entropy/dedup anomalies vs. each source's baseline:
tilldev ark canary                       # list open + past canary events
tilldev ark canary ack <event-id>        # triage: acknowledged | confirm | dismiss

# PII-scrubbed instant clones — masked, prod-like, auto-expiring:
tilldev ark clone ls
tilldev ark clone create <backup-id> [--profile standard|strict|none] \
    [--ttl <minutes>] [--name <n>]
tilldev ark clone show <clone-id>        # proof of every column masked
tilldev ark clone expire <clone-id>

# A raw (unmasked, real-PII) clone is four-eyes gated, like a real restore:
tilldev ark clone create <backup-id> --profile none \
    --approved-by <second-approver-uuid> --approval-ref <ticket>

ark canary lists entropy/dedup anomalies the canary raised against each source’s baseline, with the sample-versus-baseline evidence; triage them with ack / confirm / dismiss. ark clone spins up a masked, prod-like clone from a backup; show prints the proof of exactly which columns were neutralised. A --profile none raw clone requires four-eyes approval.

08tokens · audit

Tokens and the audit trail

bash
tilldev ark tokens ls
tilldev ark tokens create [--name <n>] [--scope read|operator|admin] [--can-approve] [--expires <days>]
tilldev ark tokens revoke <token-id>
tilldev ark audit [--limit <n>]

tokens create mints a tark_ control-plane token on a read < operator < admin scope, with an optional --can-approve capability and --expires. The secret is shown once and stored sha256-hash-only. These are the tokens the agent and machine clients authenticate with. ark audit reads the append-only compliance trail.


See the Quickstart for the commands in sequence, the Agent for the self-hosted runner, or the overview.