lastsave 返回的是 rdb 文件最后一次成功写入磁盘的 unix 时间戳（秒级整数），即 save 或 bgsave 完成、文件落盘且元数据更新完毕的时刻；若从未成功生成 rdb，则返回 0。
LASTSAVE 返回的是什么时间？
LASTSAVE 命令返回的是一个 Unix 时间戳（秒级整数），代表 RDB 文件最后一次成功写入磁盘的时刻，不是命令执行时间，也不是“上次触发保存”的时间点。
这个时间戳来自 Redis 内部的 dirty 状态清零时刻——即 save 或 bgsave 完成、文件落盘且元数据更新完毕的那一瞬。
- 如果从未成功生成过 RDB，
LASTSAVE返回0 - 若正在执行
bgsave但尚未完成，LASTSAVE仍返回上一次完成的时间，不会变 - 手动执行
SAVE会阻塞，但只要成功，LASTSAVE就会更新
怎么在命令行里快速拿到可读时间？
Redis CLI 不自带时间格式化功能，得靠 Shell 补齐。直接用 date 转换最省事：
redis-cli LASTSAVE | xargs -I{} date -d @{} "+%Y-%m-%d %H:%M:%S"
注意：xargs -I{} 在 macOS 上要换成 xargs -I{}（部分老版本需用 -J），Linux 通用；如果报错，先确认 redis-cli 是否连上了正确实例。
- 别用
redis-cli --raw LASTSAVE，它可能多输出换行，破坏管道 - 脚本中建议加超时：
timeout 2 redis-cli -h 127.0.0.1 -p 6379 LASTSAVE，避免实例假死卡住 - 返回
0时，date -d @0会显示 1970 年，这是正常现象，说明没存过 RDB
为什么 LASTSAVE 和实际文件修改时间对不上？
RDB 文件（如 dump.rdb）的 mtime 可能比 LASTSAVE 时间晚几秒，尤其在 bgsave 场景下——因为 Redis 先写临时文件（如 temp-123.rdb），再原子 rename 成 dump.rdb，而 LASTSAVE 更新发生在 rename 前一刻。
- 检查文件时间用：
stat -c "%y %n" /var/lib/redis/dump.rdb（Linux）或stat -f "%Sm %N" /usr/local/var/db/redis/dump.rdb（macOS） - 如果
LASTSAVE时间远早于文件 mtime，大概率是人工拷贝/覆盖了 RDB 文件，Redis 并不知情 - 启用
appendonly yes后，RDB 不再自动触发，LASTSAVE可能长期不变，别误判为故障
监控脚本里怎么安全判断 RDB 是否“太久没更新”？
别只比对绝对时间戳，要结合配置和运行状态。例如：设置了 save 900 1，但 LASTSAVE 距今已超 1800 秒，就得告警——说明写入不活跃或持久化被禁用了。
- 先查配置：
redis-cli CONFIG GET save，看是否为空或全被注释 - 再查进程：
redis-cli INFO persistence | grep rdb_bgsave_in_progress，确认没卡在后台保存中 - 线上脚本建议用
$(($(date +%s) - $(redis-cli LASTSAVE)))算秒差，避免 date 解析失败 - 注意时区：所有时间戳都是 UTC 秒数，跨时区机器无需转换，直接减法即可
Redis 的 LASTSAVE 是个轻量信号，但它不反映 RDB 是否可用、是否完整、甚至不保证文件还存在——它只说“上次我亲手写完是什么时候”。真正要验证备份有效性，得配合同步检查文件存在性、大小、以及定期 redis-check-rdb 校验。
