mode: restore BGSAVE is fire-and-forget; restored DB may not persist

[gaurav]

This is a translator-devops Helm chart concern, tracked here for visibility.

In mode: restore, run_pipe.sh pipes an RDB backup into Redis with redis-cli --pipe and then issues a single fire-and-forget redis-cli … BGSAVE. The Job exits without confirming the background save finished (and BGSAVE can itself fail under memory pressure on the large databases). If the Redis pod later restarts before that background save completed, it comes back up with a partial or empty dump.rdb — fewer entries than expected — requiring a re-restore.

Fix options in run_pipe.sh: use a blocking SAVE, or issue BGSAVE and then poll INFO persistence (rdb_bgsave_in_progress → 0, rdb_last_bgsave_status == ok) before the Job exits.

This is also why the 2.5 load-faster work disables periodic Redis saves loader-side (CONFIG SET save "" in load_all) rather than via a blanket chart-level --save "": a global disable would strip the periodic-save safety net that currently papers over this unreliable restore BGSAVE. See documentation/Loading.md.

[gaurav]

Addressed in translator-devops PR #1044.

run_pipe.sh (the mode: restore job) no longer fires a fire-and-forget BGSAVE. It now:

1. CONFIG SET save "" (no automatic snapshots during/after the pipe),
2. records LASTSAVE, issues BGSAVE, then waits until LASTSAVE advances,
3. verifies rdb_last_bgsave_status:ok, and fails the Job (non-zero exit) on error or a 30-minute timeout.

So a restored database is guaranteed to have a complete dump.rdb on disk before the Job exits, and a pod restart reloads it rather than coming up empty.

The same PR also sets save "" on the redis-r3-external instances (no automatic RDB snapshots; persistence is explicit in both modes) — see NodeNorm documentation/Loader.md → "Why persistence is explicit, not periodic".

Will close when #1044 merges.