Snapshot 增量备份

做的事：本机真实往一个索引灌入27万条文档，看store真实涨到多大，再对这份数据做第一次全量快照

代码真实灌入27万条文档到snap_test索引 GET /snap_test/_stats/store → 真实11.4MB PUT /_snapshot/my_fs_repo/snap_1?wait_for_completion=true {"indices":"snap_test"}

验证：第一次快照真实落到仓库目录里变成了11MB、21个文件——跟索引本身的数据量基本吻合，因为是全量

快照响应: state="SUCCESS", duration_in_millis:409
真实查仓库目录: du -sh → 11M, 文件数: 21个

这个真实结果符合预期：第一次快照真实没有任何历史数据可以复用，仓库里需要存下这27万条文档对应的全部真实Lucene段文件，大小自然真实跟索引本身的store大小基本一致。

真实再追加3万条新文档到同一个索引（不删除原有数据），做第二次快照，对比仓库目录真实涨了多少

代码真实追加3万条新文档到snap_test GET /snap_test/_stats/store → 真实涨到12.2MB PUT /_snapshot/my_fs_repo/snap_2?wait_for_completion=true {"indices":"snap_test"}

验证：仓库目录真实只多涨了1MB、多了7个文件，不是真实再翻一倍——这就是增量备份最直接的证据

第二次快照前: du -sh → 11M
第二次快照响应: state="SUCCESS", duration_in_millis:0   ← 几乎瞬间完成
第二次快照后: du -sh → 12M, 文件数: 28个(真实只多了7个)

真实把第一个快照删掉，看仓库目录大小是否会跟着掉下来，以及第二个快照是否依然完整可用

代码DELETE /_snapshot/my_fs_repo/snap_1 GET /_snapshot/my_fs_repo/snap_2

验证：仓库目录大小真实没有跟着掉下来，第二个快照真实依然完整可用——证明底层数据是多个快照共享着同一份物理文件

删除snap_1后: {"acknowledged":true}
GET /_snapshot/my_fs_repo/snap_2 → state: "SUCCESS"   ← 真实依然完整有效

删除snap_1之后仓库目录大小: du -sh → 依然是12M，没有跟着减少

如果每个快照真实在仓库里都存着一份完全独立的数据拷贝，删掉snap_1之后，仓库目录大小应该真实会明显往下掉；但本次实测结果真实完全没有变化，同时snap_2也真实没有因为snap_1被删除而受到任何影响。这说明底层那些段文件真实是被多个快照共享引用的同一份物理文件，删除一个快照真实只是解除了它对这些共享文件的引用，只有当某个文件真实不再被任何剩余快照引用时，才会在后续清理过程中真实被物理删除。

收尾：真实删掉剩下的快照和测试索引，确认仓库目录真实清空回到接近空的状态

代码DELETE /_snapshot/my_fs_repo/snap_2 DELETE /snap_test

验证：两个快照都真实删完之后，仓库目录真实缩到了8KB，只剩下仓库自身的元数据结构

du -sh → 8.0K   ← 真实回落到接近空仓库的大小

分步演示：从11MB的全量首次快照，到只多涨1MB的真实增量快照，再到删除旧快照不影响新快照的共享存储证据

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。