TILLARK · QUICKSTART

From a source to a proven restore.

Register what you’re protecting, point it at a cross-vendor target, set a policy, take a backup, then prove it restores — the whole loop, from the CLI.

01Install

Install the CLI and log in

TillArk lives inside the one tilldev CLI, alongside pulse, shield, cache, and secrets. The CLI talks to the API over HTTPS only.

bash

# The TillArk commands ship inside the one TillDev CLI.
npm i -g @tillstack/cli        # or: pnpm add -g @tillstack/cli
tilldev login                  # opens the browser; scopes the CLI to your org

02Source

Register a source

A source is what you protect: PostgreSQL (including Neon), MySQL or MariaDB, MongoDB, ClickHouse, Meilisearch, Redis or Valkey, directories on the agent’s host, or an S3-compatible bucket (s3://KEY:SECRET@bucket/prefix; with S3 versioning on, a run restores it as of one moment). Its connection string is encrypted under your org’s key and never returned; reads show has_dsn.

bash

# The connection string is read from a hidden prompt (or --dsn-stdin),
# never from argv, and is never returned by the API.
tilldev ark sources create \
  --name "acme-prod" \
  --type postgres \
  --provider neon \
  --residency eu \
  --with-dsn

03Target

Register a cross-vendor target

A target is where backups land: S3, R2, B2, Wasabi, GCS, Azure, MinIO or SFTP. Put it with a different vendor and region from the source. On S3, B2, Wasabi and MinIO, turn on object lock with --lock-days so a stolen key can’t delete a backup before its retention ends.

bash

# A different vendor and region from the source. --lock-days needs a bucket
# created with object lock; the agent confirms it before every write.
tilldev ark targets create \
  --name "acme-backups" \
  --provider s3 \
  --bucket acme-backups \
  --region eu-central-1 \
  --residency eu \
  --lock-days 30 \
  --with-creds

Secrets never touch argv

Both the source DSN and the target credentials are read from a hidden prompt (or --dsn-stdin / --creds-json-stdin), not passed as a flag value — so they never land in your shell history or the process table. They are stored envelope-encrypted and are never returned by the API.

04Agent

Run and approve an agent

The agent does the work from inside your network: it reads the source and writes the target. The installer checks the release signature first. The agent receives credentials only after you approve its key, so compare the fingerprint on the agent host with the one TillArk shows.

bash

# On a host that can reach the database and the bucket:
curl -fsSLO https://tilldev.dev/downloads/ark-agent/install.sh && sh install.sh

# An operator token, shown once:
tilldev ark tokens create --name edge-1 --scope operator

TILLARK_CP_URL=https://ark.tilldev.dev TILLARK_AGENT_TOKEN=tark_… ark-agent

# It registers and waits. Compare fingerprints, then approve it:
ark-agent fingerprint
tilldev ark agents ls
tilldev ark agents approve <agent-id> --fingerprint <fp>

05Policy

Set a policy

A policy ties a source to a UTC schedule, a GFS retention plan, a recovery point objective, and a verification schedule: how often TillArk proves the backup restores.

bash

# Every 6 hours, verified daily at 03:00 UTC, with GFS retention.
tilldev ark policies create \
  --source <source-id> \
  --cron "0 */6 * * *" \
  --verify-cron "0 3 * * *" \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12
# The RPO objective defaults to what this schedule can meet: 7 h 30 min.

An objective the schedule can’t meet is refused, and so is an all-zero retention: a policy can never mean “keep nothing.”

06Back up

Run a backup

The agent claims the run, encrypts the data before upload, writes it to the target, and reports a signed manifest. TillArk records the manifest, never the bytes.

bash

# Run now instead of waiting for the schedule: one backup per target.
tilldev ark backups run --source <source-id>
tilldev ark backups ls --source <source-id>

07Prove it

Verify and read the proof

ark verify restores the backup into a throwaway server on the agent, checks what came back against the signed manifest, and removes the server. Your systems are never touched.

bash

# Restore the backup into a throwaway server on the agent, then check it.
tilldev ark verify <backup-id>

Then read the result:

bash

# passed: the backup restored and every check held.
tilldev ark restores --backup <backup-id>

# Every step is in the audit log; check its hash chain and signatures here:
tilldev ark audit --limit 5
tilldev ark audit verify

Why this matters

A backup that passes is marked verified. Sources shows each source’s recovery point against its objective, and a failed backup, a failed verification or a missed objective lands in your notifications.

08Next

What's next

Backups and restores: what each check proves, real restores with a second approver, point-in-time recovery and retention.
Failover: promote a replica after fencing the primary (preview).
Architecture: how TillArk, the agent and the manifest fit together.
CLI reference: every command and flag.