Premier League Predictor: FastAPI & Redis — Chapter 11, Exercise 3
==================================================================

TASK
Write 100 fixtures, run BGSAVE and wait for it, write 50 more, then copy
dump.rdb into a fresh container and start it. Report the live key count
and the restored key count, and explain what a correct backup job does
differently.

SOLUTION

  100 fixture hashes written
  BGSAVE, polled INFO persistence until rdb_bgsave_in_progress = 0
  50 more fixture hashes written
  live DBSIZE     -> 150

  docker cp plredis:/data/dump.rdb ./dump2.rdb
  docker create --name plrestore redis:latest
  docker cp ./dump2.rdb plrestore:/data/dump.rdb
  docker start plrestore

  restored DBSIZE -> 100

The restored database has exactly the 100 fixtures that existed when
BGSAVE ran. The 50 written afterwards are not in the file, so they are
gone from the restore.

A correct backup job takes the snapshot at backup time, not earlier:

  1. run BGSAVE
  2. wait until INFO persistence shows rdb_bgsave_in_progress = 0
     (LASTSAVE alone is not enough: it only has one-second resolution,
     so a save that finishes in the same second as the previous reading
     looks like nothing happened)
  3. copy dump.rdb off the machine
  4. periodically restore a copy into a scratch container and count keys,
     as above, so a backup that can't be restored is found out before it
     is needed

WHY THIS WORKS AS AN ANSWER
----------------------------
It shows the real gap between live and restored counts, and turns it into
the ordered steps of a job that doesn't have the gap, including the
LASTSAVE trap met while writing this exercise.