On Redis 7.x the append-only file is a directory (default `appendonlydir`) containing a `.manifest` file, a base file, and one or more `.incr.aof` files. As the operator: what is the unit you must copy or restore, how does the server decide what to load at startup, where do you point `redis-check-aof`, and what breaks if a script copies or truncates one file inside that directory on its own?

## What is actually on disk On Redis 7.0 and later the append-only file is a directory placed next to `dir` and named by `appenddirname` (default `appendonlydir`). It holds three kinds of member: - **The manifest** (`appendonly.aof.manifest`) — a small text index. Each line names one member with a sequence number and a type: `b` for base, `i` for incr, `h` for history (superseded members awaiting deletion). - **The base file** — the dataset as of the last rewrite. Its extension is a direct readout of configuration: `*.base.rdb` when `aof-use-rdb-preamble yes` (the default), meaning the body is a binary snapshot; `*.base.aof` when the preamble is disabled, meaning the body is a plain RESP command log that rebuilds the dataset by replay. - **One or more incr files** (`*.incr.aof`) — the RESP command tail written since that base, appended under the configured `appendfsync` policy. Before 7.0 those same two sections lived concatenated inside a single `appendonly.aof` (snapshot head, command tail); the only thing that changed is the packaging and the fact that ordering is now explicit in a manifest rather than implicit in byte offsets. ## The copy/backup unit **The unit is the whole directory as one consistent set: manifest + base + every incr file the manifest names.** There is no valid partial copy. Two rules follow: 1. *Never copy or restore a single member.* Grabbing just the `.base.rdb` looks tempting — it is an RDB image — but it is the dataset as of the last rewrite, missing everything in the incr tail. Grabbing just an incr file gives you a command fragment with no starting state. 2. *The manifest and the members must agree.* If the manifest names a file that is absent from your copy, the server refuses to load. If you copy files but not the manifest, there is nothing to tell the server what the current set is. A subtlety worth stating in an interview: the directory is live. If a `BGREWRITEAOF` (or an auto-rewrite triggered by `auto-aof-rewrite-percentage`) completes while your `cp -r` is in flight, the old base and incr files can be deleted out from under you and the manifest swapped, leaving your copy internally inconsistent. Robust practice is a point-in-time filesystem or volume snapshot of the directory, or copying the manifest first and then each file it names and re-verifying afterwards; incr files only grow, so bytes appended after you read the manifest are harmless, but deletions are not. Many shops sidestep the problem for backup purposes entirely by taking a `BGSAVE` RDB, which is a single self-consistent artifact. ## How startup uses it Redis does **not** scan the directory and guess. It opens the manifest, loads the base with the loader matching its extension (RDB loader for `.base.rdb`, command replay for `.base.aof`), then replays each incr file in manifest order. Members present on disk but absent from the manifest are ignored as garbage; members named but missing are a fatal error. ## Verifying and repairing on 7.x `redis-check-aof` became manifest-aware: you point it at the manifest, not at a member. ``` redis-check-aof appendonlydir/appendonly.aof.manifest redis-check-aof --fix appendonlydir/appendonly.aof.manifest ``` It walks the whole set. `--fix` truncates the trailing partial command of the last incr file — which means it repairs exactly the one damage class Redis considers survivable, and it does so by discarding writes. ## What breaks with partial handling - **Missing member.** Manifest names a file you did not copy → load aborts at startup; the server exits with an AOF error rather than coming up with partial data. - **Truncated base.** A short `.base.rdb` fails its checksum, or a short `.base.aof` ends mid-command → hard failure. `aof-load-truncated` does not rescue the base. - **Truncated middle incr.** A hole in the middle of the sequence is a hard failure too; tolerance applies only to the tail of the final file. - **Truncated tail of the last incr.** With `aof-load-truncated yes` (default) Redis logs a warning, truncates to the last complete command and starts. This is the dangerous one: the server comes up *looking healthy* while the trailing writes are gone. Alert on the log line rather than trusting a clean start. - **Hand-deleting an "old-looking" incr file** to reclaim disk while the manifest still lists it turns a healthy server into one that cannot restart. The supported way to collapse the set is `BGREWRITEAOF`. - **Legacy scripts.** Anything doing `cp appendonly.aof` from the 6.x era silently backs up nothing on 7.x, because that path no longer exists. ## The line to remember The manifest is the authority, the directory is the artifact, and any operation that treats one member as standalone — copy, restore, truncate, delete — is a bug.