AOF‑based rollback versus RDB snapshot rollback: trade‑off between write availability and data loss after a Redis schema change

The Recommended Approach

For workloads that cannot tolerate prolonged write pauses, restoring from an RDB snapshot is the superior choice. RDB loading is a fast, bounded operation that restores the database to a known state almost atomically upon restart. In contrast, an AOF-based rollback requires surgically truncating the log to a specific offset and replaying commands, a process that scales with the size of the log and can lead to significant write unavailability or performance degradation during the replay phase.

Technical Trade-offs

RDB Snapshot Restore

• Availability: High. The recovery time is limited to the time it takes Redis to load the binary file into memory.
• Data Loss: High. All writes occurring between the snapshot timestamp and the rollback decision are permanently lost.
• Complexity: Low. It is a simple file replacement and restart.

AOF-based Rollback

• Availability: Low. Truncating and replaying a large AOF can block the main thread or cause significant latency spikes during the startup replay.
• Data Loss: Low. You can theoretically restore data up to the exact millisecond before the schema change occurred.
• Complexity: High. Requires identifying the exact byte offset of the offending command and using tools like redis-check-aof to validate the truncated file.

Implementation Steps for RDB Rollback

1. Pre-change Safeguard: Execute BGSAVE immediately before applying the schema change to minimize the data-loss window.
2. Stop Redis: Shut down the instance to prevent further corruption or inconsistent writes.
3. Disable AOF: Ensure appendonly no is set or move the existing AOF file. If AOF remains enabled, Redis may attempt to replay the "bad" schema changes on top of the restored RDB.
4. Restore File: Replace the current dump.rdb with the pre-change backup.
5. Restart and Verify: Start Redis and verify the hash layout using HGETALL or HSCAN on a sample key.

Determining Acceptable Data Loss

The amount of acceptable data loss is an application-level decision, not a technical Redis constraint. RDB rollback is acceptable if:

• Post-change writes can be re-derived from an upstream source (e.g., a Kafka topic, RabbitMQ queue, or application logs).
• The data is transient (e.g., a cache) and can be repopulated from a primary database.
• The business cost of a prolonged outage exceeds the cost of losing the specific window of mutations.

Missing Diagnostic Detail: Are the writes occurring during the schema-change window replayable from an external source? If they are irreplaceable, an RDB restore is likely unacceptable regardless of the write-pause constraints.