Recovering a Redis Database After FLUSHDB Using AOF – Redis Knowledge Base

This article provides a comprehensive guide for recovering a Redis database after an accidental FLUSHDB command by editing the Append-Only File (AOF). It walks through locating the AOF file, identifying and trimming destructive commands, and safely reloading the modified file to restore the dataset. The article includes Preparation and Prerequisites, a Step-by-Step Recovery Procedure, Troubleshooting, and Additional Resources.

You’ll learn how to:

Locate AOF files per shard
Identify and remove unwanted commands like FLUSHDB
Restore data using a trimmed AOF
Avoid common pitfalls, especially with CRDB setups

Warning: Do not attempt AOF-based recovery on CRDB (Active-Active) databases if any healthy replicas still exist. Allow the cluster to resynchronize instead. Manual AOF manipulation in these environments may cause data inconsistency.

Preparation and Prerequisites

Before starting recovery:

React Immediately
Halt all writes to the affected database to prevent the AOF from being overwritten.
Back Up AOF Files
Immediately copy the AOF files for all impacted shards to a safe location. Example:
```
cp /var/opt/redislabs/persist/redis/<shard-id>/appendonly.aof /tmp/aof_backup_<shard-id>
```
Understand AOF Format
AOF files are plain-text, command-by-command logs. Each database shard has its own AOF file. Commands like FLUSHDB appear in this format:
```
*1
$7
flushdb
```
Make a Full System Backup
Capture current file system state and configuration files before proceeding.

Step-by-Step Recovery Procedure

Locate AOF Files
- Default location per shard:
```
/var/opt/redislabs/persist/redis/appendonly-<shard-id>.aof.dir/appendonly-<shard-id>.aof.*.aof
```
1. Identify FLUSHDB or Other Harmful Commands
  - Search for destructive commands:
```
grep -iahn flushdb appendonly-<shard-id>.aof.*.aof
```
  - Note the line numbers before which the file should be truncated.
Trim the AOF File
- Use head, split, or sed to create a new AOF that ends before the last FLUSHDB:
```
head -n <line_number_before_flushdb> appendonly-<shard-id>.aof.*.aof > trimmed.aof
```

Replace the AOF

Stop the watchdogs for the database:
```
rlutil disable_watchdogs uid=<bdb-id> 
```

Backup the original AOF if this hasn’t been completed yet, then replace it with the trimmed version:

mv trimmed.aof /var/opt/redislabs/persist/redis/appendonly-<shard-id>.aof.dir/appendonly-<shard-id>.aof.1.incr.aof
chown redislabs:redislabs appendonly-<shard-id>.aof.1.incr.aof
chmod 644 appendonly-<shard-id>.aof.1.incr.aof

Configure Redis to Preload the Trimmed AOF

Edit the shard’s configuration file:

/var/opt/redislabs/redis/redis-<uid>.conf

Add:

preload-file /var/opt/redislabs/persist/redis/appendonly-<shard-id>.aof.dir/appendonly-<shard-id>.aof.manifest

Restart the Shard

Restart and monitor:

redis_ctl stop <shard-id>
redis_ctl force-start <shard-id>

Validate Recovery
- Confirm expected data is present.
- If correct, remove the preload-file directive.
- Enable watchdogs once again:
```
rlutil enable_watchdogs uid=<bdb-id>
```

Troubleshooting

Issue	Resolution
No FLUSHDB in AOF	Recovery via AOF is not possible. Fall back to the most recent snapshot or backup.
Redis fails to start	Check AOF file permissions (`redislabs:redislabs`), ensure syntax in `preload-file` is valid.
Missing Data	AOF might have been overwritten. Try restoring from an older copy or backup.
Silent preload failure	Review logs in `/var/opt/redislabs/log/` and confirm preload path accuracy.
Active-Active Recovery Attempted	Revert immediately. Rely on Redis CRDB conflict resolution, not manual AOF recovery.

Additional Resources

Related to

Preparation and Prerequisites

Step-by-Step Recovery Procedure

Troubleshooting

Additional Resources

Related articles