This text explains how one can carry out Level-in-time-Restoration (PITR) in Valkey/Redis.
Necessities
To carry out PITR, it is advisable have append-only logging enabled.
By default, AOF in Valkey/Redis solely information the operations which have been executed in opposition to the occasion, not after they had been executed. For that, we have to allow the aof-timestamp-enabled parameter.
So your Valkey/Redis occasion must have the next parameters:
|
appendonly sure appendfilename “appendonly.aof” aof–timestamp–enabled sure |
A little bit refresher on append-only logging in Valkey/Redis
AOF persistence logs each write operation acquired by the server. These operations can then be replayed once more at server startup, reconstructing the unique dataset. Instructions are logged utilizing the identical format because the Valkey protocol itself.
Valkey/Redis writes the instructions to AOF information in plaintext, so should you solely have to take away an unintentional command (i.e., FLUSHDB), or there are corrupted instructions within the append-only logs, you possibly can merely open the AOF file and repair/delete it.
A extra complete documentation on Valkey/Redis serialization format could be discovered on the official Valkey documentation.
Decide the timestamps you possibly can restore to
So, as a result of AOF shall be rewritten when its dimension reaches the worth outlined by auto-aof-rewrite-*, should you should not have backups of the append-only logs obtainable, you possibly can solely restore as much as the purpose when AOF rewrite began. Whereas the auto rewrite course of could be disabled (by setting auto-aof-rewrite-percentage to 0), should you decide to take action, you have to to watch the server’s storage intently and take motion to make sure it isn’t fully stuffed.
You may determine the obtainable restore factors by grepping the AOF file for the string #TS:
|
# grep ‘#TS’ appendonly.aof.1.incr.aof #TS:1764918042 #TS:1764918195 #TS:1764918200 #TS:1764918201 #TS:1764918207 #TS:1764918214 #TS:1764918216 #TS:1764918220 #TS:1764918221 #TS:1764918222 #TS:1764918330 |
To rapidly convert the timestamps in AOF information into human-readable dates, we will use the instructions under
- Traces in AOF information are terminated by CRLF, so that you might need problem parsing the timestamps should you write a script for it. To unravel that, we will simply take away the road terminator utilizing tr:
|
# grep ‘#TS’ appendonly.aof.1.incr.aof | sed ‘s|#TS:||g’ |tr -d ‘r’ | whereas learn -r ts do echo “#TS:${ts} = $(date -d “@$ts” +”%Y–%m–%d %H:%M:%S“)” achieved #TS:1764918042 = 2025-12-05 07:00:42 #TS:1764918195 = 2025-12-05 07:03:15 #TS:1764918200 = 2025-12-05 07:03:20 #TS:1764918201 = 2025-12-05 07:03:21 #TS:1764918207 = 2025-12-05 07:03:27 #TS:1764918214 = 2025-12-05 07:03:34 #TS:1764918216 = 2025-12-05 07:03:36 #TS:1764918220 = 2025-12-05 07:03:40 #TS:1764918221 = 2025-12-05 07:03:41 #TS:1764918222 = 2025-12-05 07:03:42 #TS:1764918330 = 2025-12-05 07:05:30 |
Truncate the AOF to your chosen timestamp
After figuring out the timestamp you want to restore to, we will use the command valkey-check-aof to truncate the AOF file to that time. For instance, if I wished to revive to the timestamp 1764918201 (2025-12-05 07:03:21):
|
# valkey-check-aof –truncate-to-timestamp 1764918201 appendonly.aof.1.incr.aof Begin checking Previous–Model AOF Efficiently truncated AOF appendonly.aof.1.incr.aof to timestamp 1764918201 |
We are able to then examine the outcome by grepping the AOF file once more for timestamps
|
grep ‘#TS’ appendonly.aof.1.incr.aof #TS:1764918042 #TS:1764918195 #TS:1764918200 #TS:1764918201 |
Begin the service
After truncating, we will begin the service as regular, and make sure that valkey-server can learn the truncated AOF file by viewing its log:
|
93048:M 05 Dec 2025 07:38:35.798 * Server initialized 93048:M 05 Dec 2025 07:38:35.798 * Studying RDB base file on AOF loading... 93048:M 05 Dec 2025 07:38:35.798 * Loading RDB produced by Valkey model 8.1.4 93048:M 05 Dec 2025 07:38:35.798 * RDB age 2292 seconds 93048:M 05 Dec 2025 07:38:35.798 * RDB reminiscence utilization when created 0.87 Mb 93048:M 05 Dec 2025 07:38:35.798 * RDB is base AOF 93048:M 05 Dec 2025 07:38:35.798 * Finished loading RDB, keys loaded: 0, keys expired: 0. 93048:M 05 Dec 2025 07:38:35.798 * DB loaded from base file appendonly.aof.1.base.rdb: 0.000 seconds 93048:M 05 Dec 2025 07:38:35.800 * DB loaded from incr file appendonly.aof.1.incr.aof: 0.002 seconds 93048:M 05 Dec 2025 07:38:35.800 * DB loaded from append solely file: 0.002 seconds 93048:M 05 Dec 2025 07:38:35.800 * Opening AOF incr file appendonly.aof.1.incr.aof on server begin 93048:M 05 Dec 2025 07:38:35.800 * Prepared to settle for connections tcp |
Conclusion
Valkey/Redis Level-in-Time Restoration (PITR) is achieved completely via the Append Solely File (AOF) mechanism with timestamping enabled.
The ultimate course of is:
- Choose a timestamp embedded inside the AOF utilizing valkey-check-aof to truncate the AOF file exactly to the chosen time
- Then, restart the service to load the truncated AOF, which restores the database state to the required time limit.
