Key migration or duplication
Move or copy a value between key names after obtaining its serialized representation with DUMP.
Redis · Module
RESTORE
RESTORE creates a key by deserializing a serialized value produced by DUMP. It can apply a relative or absolute expiration and optionally replace an existing key or initialize eviction metadata.
How it works
RESTORE deserializes a value produced by DUMP and creates the specified key. A TTL of zero means no expiration; otherwise Redis interprets the TTL as milliseconds, or as an absolute Unix-millisecond expiration time when ABSTTL is supplied.
Syntax
RESTORE key ttl serialized-value [REPLACE] [ABSTTL] [IDLETIME seconds] [FREQ frequency]Parameters
| Name | Type | Description |
|---|---|---|
key | key | Name of the destination key to create. |
ttl | integer | Expiration in milliseconds; zero means no expiration. With ABSTTL, it is an absolute Unix timestamp in milliseconds. |
serialized-value | binary value | Serialized value produced by DUMP. |
REPLACE | option | Replace the destination if it exists. |
ABSTTL | option | Interpret ttl as an absolute Unix timestamp in milliseconds. |
IDLETIME seconds | option | Set idle time for LRU eviction, in seconds. |
FREQ frequency | option | Set the access-frequency counter for LFU eviction. |
Returns
A simple string status reply, normally OK on success; errors are returned for a busy destination without REPLACE or invalid serialized data.
Key points
- RESTORE reconstructs a Redis key from an opaque serialized representation, typically generated by DUMP.
- A zero TTL creates a persistent key rather than applying an expiration.
- ABSTTL switches the TTL from a relative duration to an absolute expiration timestamp.
- REPLACE allows restoration to overwrite an existing destination key.
- IDLETIME initializes the restored key's idle time in seconds for LRU eviction behavior.
- FREQ initializes the restored key's access-frequency counter for LFU eviction behavior.
Common mistakes
- An existing destination key causes an error unless REPLACE is included.
- Redis rejects payloads when the serialized data's RDB version or checksum validation fails.
Example: Copy a serialized key
const source = await redis.dump("session:source");
await redis.restore("session:copy", 60000, source);
console.log(await redis.exists("session:copy"));Serializes one key with DUMP and recreates it under another name with a 60-second relative expiration.
When to use it
Cache restoration with expiration
Recreate cached data while preserving a relative lifetime or supplying an absolute expiration deadline.
Eviction metadata initialization
Restore data while initializing idle time or access frequency used by an eviction policy.
Interview questions
QWhat does RESTORE do?
RESTORE creates a key by deserializing a serialized value, normally one returned by DUMP. Its TTL argument is expressed in milliseconds, and zero creates the key without expiration.
Follow-up: How would you preserve an absolute expiration timestamp? Use ABSTTL, which makes the TTL argument an absolute Unix timestamp in milliseconds rather than a relative duration.
QHow do you restore over an existing key?
By default, RESTORE fails when the destination key already exists. REPLACE changes that behavior by replacing the existing key.
Follow-up: What happens if the destination does not exist but the payload is invalid? Redis validates the RDB version and checksum and returns an error when they do not match.
QWhat are IDLETIME and FREQ used for?
IDLETIME sets the restored key's idle time in seconds for LRU eviction, while FREQ sets its access-frequency counter for LFU eviction. These options let restoration initialize eviction-related metadata.
Follow-up: When should ABSTTL be used instead of a relative TTL? Use it when the expiration is already represented as an absolute Unix timestamp in milliseconds, such as when preserving a shared deadline.
Related
DUMPRESTORE-ASKINGEXPIREMIGRATE