在前幾天，我們讓 Elasticsearch 跑得更快，但沒有任何效能能比「資料救得回來」更重要。

只要資料沒了，一切都白搭。

今天要講的 Snapshot / Restore，就是 Elasticsearch 的「冷備份」機制。

它不是單純的檔案複製，而是透過 ES API 將索引儲存成「可隨時回復」的快照。

今天的目標

• 建立 snapshot repository（備份儲存庫）
• 建立 snapshot（拍下某個時刻的索引狀態）
• 模擬刪除索引 → 從 snapshot 還原

整個過程，可以想成：

「先拍一張 Elasticsearch 的全家福，再用它救回一個誤刪的索引。」

Step 1 — 建立 Repository（備份儲存庫）

Elasticsearch 要先知道「快照要放哪裡」。

在單節點 Docker 環境下，可以直接用本機目錄當儲存路徑。

先在宿主機建立一個目錄（例如 /usr/share/elasticsearch/snapshots），

並確保這個資料夾已經掛載進容器裡（docker-compose.yml 通常是這樣設定的）：

volumes:

- esdata:/usr/share/elasticsearch/data

- ./snapshots:/usr/share/elasticsearch/snapshots

然後在 Elasticsearch 裡註冊它：

curl -X PUT "localhost:9200/_snapshot/jeopardy_backup" \

-H 'Content-Type: application/json' \

-d '{

"type": "fs",

"settings": {

"location": "/usr/share/elasticsearch/snapshots",

"compress": true

}

}'

執行成功會回傳：

{"acknowledged":true}

代表 repository 建立成功。

Step 2 — 建立 Snapshot

假設我們的索引叫做 jeopardy，

可以直接拍一張名為 snap_2025_jeopardy_v1 的快照：

curl -X PUT "localhost:9200/_snapshot/jeopardy_backup/snap_2025_jeopardy_v1?wait_for_completion=true" \

-H 'Content-Type: application/json' \

-d '{

"indices": "jeopardy",

"ignore_unavailable": true,

"include_global_state": false

}'

參數說明：

• indices: 要備份的索引
• ignore_unavailable: 忽略不存在的索引
• include_global_state: 是否包含集群設定（我們不需要）

成功後，你會看到類似：

{

"snapshot": {

"snapshot": "snap_2025_jeopardy_v1",

"indices": ["jeopardy"],

"state": "SUCCESS"

}

}

這就是我們的第一個「ES 快照」。

Step 3 — 模擬誤刪資料

我們來模擬一個慘劇：

某天手滑輸入了：

curl -X DELETE "localhost:9200/jeopardy"

這時所有 Jeopardy 題目都消失了。

系統查不到任何內容。

但是沒關係，我們有 snapshot！

Step 4 — 從 Snapshot 還原

只要執行以下命令，就能「原地重建」同名索引：

curl -X POST "localhost:9200/_snapshot/jeopardy_backup/snap_2025_jeopardy_v1/_restore" \

-H 'Content-Type: application/json' \

-d '{

"indices": "jeopardy",

"include_global_state": false

}'

恢復完成後，可以確認：

curl "localhost:9200/jeopardy/_count"

結果會顯示原本的筆數回來了 ✅

Step 5 — 排程自動備份（選用）

在正式系統裡，你不會手動備份。

建議使用 CronJob 或 Kubernetes CronJob 定期觸發。

例如，每天凌晨 3 點備份：

curl -X PUT "localhost:9200/_snapshot/jeopardy_backup/snap_$(date +%F)?wait_for_completion=true"

也可以搭配雲端儲存，如：

• AWS S3 (type: s3)
• GCS (type: gcs)
• Azure Blob (type: azure)

這樣就能讓快照存放在遠端，防止實體機毀損。

小結：備份不只是保命，更是信心

到這裡，我們完成了整個 Elasticsearch 的「生命循環」：

• 從安裝（Day 17）
• 到查詢（Day 18）
• 分頁（Day 19）
• 匯入資料（Day 20）
• 效能優化（Day 21）
• 最後的備份（Day 22）

這個階段的每一個任務都在回答一個核心問題：

「如果我今天真的上線服務，它能撐得住、救得回來嗎？」

Snapshot & Restore 不只是「防災」，象徵系統生命週期的責任感。

這不只是技術，更是專業工程師的心態。

💡 小結反思

到這裡，Phase 2（Elasticsearch 篇）正式結束。

我們從假資料變成真資料，從單節點變成完整生命循環。

下一階段我們將進入 Kubernetes，把整個服務容器化與自動化部署。