A Redis server is configured with both snapshotting and the append-only file enabled, and it restarts. Which of the two files does it use to rebuild the dataset, and what goes wrong if someone enables the append-only file by editing the config file and restarting?

## Two persistence files, one loader Redis can maintain a snapshot file (`dump.rdb`, produced by save points or an explicit `BGSAVE`) and an append-only file at the same time, and running both is the recommended configuration when the data matters. But at startup only one of them is used to rebuild memory. The rule is simple and worth memorizing: **if `appendonly yes`, Redis loads the AOF and ignores the RDB entirely. If `appendonly no`, Redis loads the RDB.** There is no merge, no "replay the AOF on top of the snapshot" step across two files. The reasoning is that the AOF is continuously appended and fsynced (by default every second), so it is always at least as fresh as the newest snapshot; loading the older artifact would silently roll the dataset back. With hybrid persistence enabled (`aof-use-rdb-preamble yes`, the default), the AOF already *contains* a snapshot body internally, so the fast-loading property of RDB is not lost by preferring the AOF. ## Why the config-file route breaks Consider a cache-turned-datastore that has been running with save points only. Someone decides it now needs second-level durability, edits `redis.conf`: ``` appendonly yes ``` and restarts the process. On boot Redis sees `appendonly yes`, looks for the append-only file — and there isn't one, or there is a stale one from months ago. A missing AOF is not an error: Redis treats it as an empty dataset and starts serving with zero keys. The perfectly good `dump.rdb` sitting next to it is never read. The second half of the damage is the overwrite. The server is now live and empty. When a save point fires, or on `SHUTDOWN` with save points configured, Redis writes a new `dump.rdb` reflecting the empty (or newly repopulated) dataset, destroying the last good snapshot. What began as a config change becomes data loss unless you have off-box backups. ## The correct enable procedure Enable it on the **running** server: ``` redis-cli CONFIG SET appendonly yes ``` This is not just a flag flip. Redis reacts by starting an AOF rewrite: a child process serializes the current in-memory dataset as the new AOF base (in RDB format when the preamble is on), while the parent buffers/streams subsequent writes into the incremental part. When it finishes, the AOF on disk represents the live dataset, `INFO persistence` shows `aof_enabled:1` and `aof_rewrite_in_progress:0` with `aof_last_bgrewrite_status:ok`, and only then is the server safe to restart. Finish by persisting the setting so the running state and the config file agree: ``` redis-cli CONFIG REWRITE ``` or edit `redis.conf` by hand *after* the AOF exists. ## Disabling it has the mirror hazard Going the other way — `CONFIG SET appendonly no` — stops appending but does not create a snapshot. If the process then dies before any save point fires, the AOF is stale-but-ignored on the next boot only if the config file still says `no`, and the RDB may be old. Take an explicit `BGSAVE` around any such switch so both artifacts are current. ## What to verify after a restart - `DBSIZE` and a couple of known keys before you let traffic in. - `INFO persistence`: `loading:0`, `rdb_last_bgsave_status:ok`, `aof_last_write_status:ok`. - The AOF directory (`appendonlydir` on Redis 7.0+) actually contains a base file with a recent timestamp. A related safety net worth knowing: `stop-writes-on-bgsave-error yes` makes Redis reject writes with a `MISCONF` error when the last background save failed, which is Redis telling you it can no longer persist. That protects the snapshot path, not the empty-AOF mistake described above — nothing in Redis warns you that you booted from an absent AOF, which is exactly why the procedure matters.