Use RESTORE to recreate a key from a payload produced by DUMP.
<ttl> gives the new key a lifetime in milliseconds, where 0 means no expiration; with ABSTTL the same number is read as an absolute Unix timestamp in milliseconds instead. The command fails if the key already exists unless REPLACE is given.
The payload's version stamp and checksum are verified before anything is written, so a truncated, corrupted, or foreign payload is rejected rather than loaded. IDLETIME and FREQ seed the eviction metadata of the new key so that a restored key does not automatically look freshly used.
Syntax#
Arguments#
| Argument | Required | Repeatable | Description |
|---|---|---|---|
<key> | Yes | No | Redis key targeted by the command. |
<ttl> | Yes | No | Lifetime in milliseconds; 0 restores the key without an expiration. |
<serialized-value> | Yes | No | Payload produced by DUMP. |
REPLACE | No | No | Allow replacement of an existing destination. |
ABSTTL | No | No | Treat <ttl> as an absolute Unix timestamp in milliseconds. |
IDLETIME <seconds> | No | No | Set the key's idle time, in seconds. |
FREQ <frequency> | No | No | Set the key's access frequency counter. |
Important points#
- This command can expose administrative information or make a broad destructive change. Restrict it to trusted code paths.
Response#
The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.
| Protocol | Reply |
|---|---|
| RESP2 | Simple string OK |
| RESP3 | Simple string OK |
Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.
Examples#
TCP examples use the TLS REDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.
Redis CLI
@upstash/redis
This command is not supported yet in @upstash/redis.
upstash_redis
This command is not supported yet in upstash_redis.