京公网安备11010502063487号真实先在没配置path.repo时注册fs类型snapshot仓库被直接拒绝，加进path.repo白名单重启后注册立刻成功且_verify确认节点能正常访问；用没加进白名单的/tmp/outside-repo路径注册第二个仓库同样被拒绝，证明path.repo是不能靠API调用绕过的硬性限制。
真实往索引灌入27万条文档后做第一次全量快照仓库目录涨到11MB，追加3万条新文档后的第二次快照仓库目录只多涨1MB且几乎瞬间完成，验证了snapshot的真实增量特性；删除第一个快照后仓库大小不变，第二个快照依然完整可用，证明底层段文件被多个快照共享引用。
真实写入2条数据建快照，验证索引存在时直接restore会被拒绝(提示删除索引或改名恢复)；真实删除索引模拟数据丢失并确认404，再执行restore验证恢复出的文档数精确对上2条，且每条文档的_id都跟删除前完全一致，证明restore是原样还原数据而非重新生成。
真实建两个索引一起打进同一份快照后全部删除，验证restore只指定其中一个索引时另一个不受影响依然404；用通配符批量恢复时因一个索引已存在产生冲突导致整批请求全部失败，单独指定索引名才完成完整恢复，揭示批量restore是原子性的整体操作。
真实给rn_test建快照后不删原索引，用rename_pattern/rename_replacement把恢复目标改名成restored_test，验证两个索引真实可以并存；再执行同样的改名恢复真实被拒绝因为新名字本身已存在，证明冲突检查针对的是改名后的最终目标名字而非快照记录的原始索引名。
真实搭建2节点1主1副集群，打快照后删除数据，分别直接查主分片和副本节点发现两边都查不到，证明副本对逻辑错误没有保护；用删除前的快照restore后数据完整找回；对照kill掉主分片所在节点，数据立刻能从副本查到不需要restore，勾勒出snapshot和replica分别解决逻辑回滚和物理高可用这两类互补问题。
真实注册一个指向本地目录的snapshot仓库，验证可写时注册和_verify都顺利通过；chmod成只读后_verify和快照尝试都失败，报错精确暴露具体文件路径；查失败快照状态发现404不存在，证明彻底失败的快照不留残留记录；改回可写后新快照立刻成功。
真实对同一个3条文档的小索引调用_cat/indices和_stats，前者只返回246字节摘要表格而后者返回10258字节完整JSON相差约42倍；_stats真实有19个顶层统计分类，search和segments下各有十几个_cat完全没暴露的细分字段；不加过滤的_cat/indices默认隐藏全部系统索引。
真实批量写入2万条文档算出平均每次写入0.0148毫秒；用轻量查询测query_current发现操作太快抓不到非零瞬间，换成重脚本查询后逮到fetch_current变成10；对比发现52次查询query只花360毫秒而fetch花了14758毫秒，揭示判断读写压力不能只看query阶段。
真实查_nodes/stats/jvm基线heap_used_percent是40%，灌数据跑重聚合后涨到41%、young gc多了1次；对比_cat/thread_pool和_nodes/stats/thread_pool查同一个线程池，stats视图多出completed和largest两个诊断字段。
真实验证index.search.slowlog.level这个早期设置在8.15.0上已经失效；把query和fetch的threshold.warn设成0ms后跑一次查询，验证slowlog把query和fetch两个阶段分别独立记录；把indexing的threshold设成0ms写入文档，验证indexing slowlog记下了被写入文档的完整原始内容和精确耗时。
真实把search slowlog的query阈值同时设成warn/info/debug/trace四档，验证234微秒的查询只在TRACE这一个最宽松级别留下1条记录；同样手法验证indexing slowlog一次592微秒的写入也遵循同一套单一级别判定；对比两边字段发现search slowlog真实只多出search_type/total_hits/total_shards这3个字段，核心结构一致。