A restart empties it
Redis keeps everything in memory, so a restart empties it unless you configure persistence, and the two mechanisms make opposite trades.
Snapshot the whole dataset to a compact file on a schedule, the first of them. Redis forks a child, the child writes the snapshot while the parent keeps serving, and you get one dense file that restores fast.
Count two costs. Everything written since the last snapshot dies with a crash, potentially minutes of data. And that fork briefly needs extra memory in proportion to how much changes during the dump, which has killed instances running close to their limit.
Log every write command to a file instead, the second, and the same idea databases use for recovery. On restart Redis replays the log and rebuilds.
Set the durability from the sync policy. Every command, safe and slow. Every second, the default, losing at most a second. Or leave it to the operating system.
Expect that log to grow without bound, so Redis periodically rewrites it as the smallest set of commands recreating your current data. Recovery is slower than a snapshot, because millions of commands replay one by one.
What to actually run
Run both in production, the common setup: snapshots as a compact backup artifact and the log for freshness, restoring from the log.
Or run neither, deliberately, for a pure cache. If it only holds data you can reload from your database, persistence buys little and costs you fork memory and disk work.
Recognise what you actually need after that restart: warming, because you come back with an empty cache and a zero percent hit rate either way.
Follow the rule that keeps teams out of trouble. Decide whether each dataset here is disposable, and never let data that is not disposable sit in an instance configured as though it is. That mismatch is one of the classic postmortems.
Worked example
Tara's startup uses one Redis for two jobs: caching product data, and holding a list of pending payout instructions a worker drains nightly. It was provisioned as a cache, persistence off, and it runs fine for a year until a host migration restarts the instance at 11 pm, before the drain. The cache half repopulates itself within minutes, as caches do. The payout list is simply gone, 3,100 instructions, and the team spends two days reconstructing them from application logs, apologizing to sellers whose payouts arrived late. The redesign splits the roles: cache Redis stays persistence-free, and payout instructions move to a second Redis with AOF everysec and a replica, until six months later they migrate that queue to Postgres, where it should have lived all along.