Redis

Reads every key with SCAN and DUMP and stores them. Available as both a local and a cloud backup, and it works against managed Redis, which a replication-based snapshot cannot.

What is taken

A pass over one keyspace: every key, its value, and its TTL.

The artifact

JSON Lines, one key per line:

{"key":"user:1","ttl_ms":0,"value":"AAVhbGljZQ0AWLBU0uYB8Kw="}

value is Redis's own DUMP payload, base64 encoded. That is what makes the format lossless: RESTORE puts each value back with its type and internal encoding intact, so a list comes back a list and a hash a hash. ttl_ms is 0 for a key with no expiry, otherwise the remaining life in milliseconds, which is exactly what RESTORE takes.

The format is plain text, so you can read it, grep it, and restore one key by hand if that is all you need.

Fields

Local, in the worker's config.yaml under source::

Cloud, on the backup definition. host is required here, because unlike a database dump there is no local socket fallback worth guessing at. Every field goes to the vault together and none is returned by any endpoint:

backups:
  "<backup-uuid>":
    source_type: redis
    source:
      host: cache.internal
      port: 6379
      password: "<password>"
      tls: true

What the server has to allow

Only ordinary read commands: SCAN, DUMP and PTTL. No SYNC, no BGSAVE, no SAVE.

That is the whole reason for the format. Managed Redis blocks the replication and persistence commands a --rdb snapshot needs:

REPLCONF -> ERR command 'replconf' is not allowed
BGSAVE   -> ERR command 'bgsave' is not allowed

Redis Cloud, Upstash and ElastiCache Serverless all answer that way, and there is no flag on our side that changes it. Reading the keys back is the path they leave open, so that is the path we take.

An ACL user still needs read access to the keys it is meant to back up.

Sizing

Larger on the wire than an RDB, because base64 costs a third, though it compresses well and compression is on by default. The bigger cost is time: one DUMP and one PTTL per key, so a keyspace of millions of keys takes minutes rather than seconds.

Keys are read in batches and nothing is held in memory but the key in hand, so the size of the keyspace does not decide whether the backup fits.

Restoring

sctl restore redis <artifact-id> --host cache.internal --port 6379

Keys are replayed into a running server as RESTORE commands. Nothing has to be stopped, no file has to be placed, and permissions on the data directory do not matter.

Each key keeps the keyspace it was dumped from; pass --db to collapse every key into one. Existing keys of the same name are overwritten and everything else in the target is left alone, so restoring into a live server is additive rather than destructive.