PUT _cluster/settings
{"persistent": {"indices.recovery.max_bytes_per_sec": "200mb",
"cluster.routing.allocation.node_concurrent_recoveries": 4}}
GET _recovery?human&detailed=true
从对象存储恢复一个 500GB 索引，六个小时才到 60%，_recovery 里每个分片的速度只有 8MB/s。仓库带宽和本地磁盘都没跑满。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，恢复默认按分片并行，indices.recovery.max_bytes_per_sec 默认 40MB/s 是单节点上限，分片再多也压在一条线上。同时恢复的分片数受 node_concurrent_recoveries 限制，默认 2。两头都卡着，看起来就像没动静。
围绕「快照恢复速度」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。
一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
处理上按这个顺序：临时调高单节点恢复限速 按网卡和磁盘余量给；提高节点并发恢复数 别超过磁盘承受能力；恢复时先只开主分片 完成后再补副本；用 _recovery 逐分片看速度 判断卡在带宽还是磁盘。
改完只确认一件事：_recovery 里分片速度升到 40MB/s 以上，整体恢复时间压到两小时内。