Belajar Elasticsearch - Snapshot & Restore - Backup Strategy

#Pendahuluan

Di episode 19 kita menyepakati performa — tapi performa tidak berarti apa-apa jika data bisa hilang. Operator kehilangan data bukan karena teknologinya buruk, melainkan karena backup yang tidak pernah diuji restore. Snapshot adalah mekanisme backup resmi Elasticsearch, dan episode ini memastikan kalian bisa membuat, mengotomatiskan, dan — yang paling penting — mengembalikan data dengan percaya diri. Kita akan membahas konsep snapshot, jenis repository (filesystem, S3, GCS, Azure), pembuatan repository, snapshot lifecycle management (SLM), snapshot penuh dan incremental, operasi restore, partial dan cross-cluster restore, serta monitoring dan keamanan snapshot.

#Konsep Snapshot

Snapshot adalah salinan index (atau seluruh cluster) yang disimpan di repository terpisah. Karakteristik pentingnya:

• Incremental — snapshot kedua hanya menyimpan data yang berubah sejak snapshot pertama; snapshot pertama menyimpan data penuh. Ini yang membuat backup berulang murah.
• Independen dari cluster — snapshot disimpan di storage eksternal, selamat jika cluster hancur total.
• Backup hanya data yang sudah commit — snapshot tidak menangkap translog yang belum ter-flush; untuk data real-time, kombinasikan dengan replikasi (episode 22).

#Repository Types

Repository menentukan tempat penyimpanan snapshot:

Untuk production, repository cloud (S3/GCS/Azure) adalah standar — off-site, murah, dan otomatis ter-replikasi. Pastikan snapshot berada di lokasi yang berbeda dari cluster — backup di mesin yang sama bukanlah backup.

#Membuat Repository

Contoh repository S3 (butuh plugin repository-s3 dan credentials):

PUT /_snapshot/my-s3-repo

{
  "type": "s3",
  "settings": {
    "bucket": "my-es-backup-bucket",
    "region": "ap-southeast-1",
    "base_path": "elasticsearch/snapshots"
  }
}

Verifikasi repository bisa diakses:

GET /_snapshot/my-s3-repo/_verify

#Membuat dan Mengelola Snapshot

#Snapshot Manual

PUT /_snapshot/my-s3-repo/snapshot-2026.08.03?wait_for_completion=true

{
  "indices": "logs-*,produk",
  "ignore_unavailable": true,
  "include_global_state": false
}

ignore_unavailable melewati index yang tidak ada; include_global_state menyimpan setting cluster, template, dan ILM policy. ?wait_for_completion=true membuat request menunggu — untuk snapshot besar, biarkan false dan pantau via _status.

#Snapshot Lifecycle Management (SLM)

SLM mengotomatiskan snapshot secara terjadwal — inilah jantung strategi backup tanpa campur tangan manual:

PUT /_slm/policy/nightly-backup

{
  "schedule": "0 30 2 * * ?",
  "name": "nightly-{now/d}",
  "repository": "my-s3-repo",
  "config": { "indices": ["logs-*", "produk", "users"] },
  "retention": { "expire_after": "30d", "max_count": 30, "min_count": 7 }
}

Schedule memakai format cron (cron expression di atas: pukul 02.30 setiap hari). Retention otomatis menghapus snapshot tua berdasarkan umur dan jumlah. Untuk compliance (episode 17), sesuaikan expire_after dengan kebijakan retensi organisasi.

#Operasi Restore

Restore tidak terjadi otomatis — snapshot hanyalah cadangan. Untuk mengembalikan index dari snapshot:

POST /_snapshot/my-s3-repo/snapshot-2026.08.03/_restore

{
  "indices": "produk",
  "rename_pattern": "produk",
  "rename_replacement": "produk-restored",
  "include_global_state": false
}

Restore biasanya ke index dengan nama berbeda untuk menghindari menimpa index aktif — pola rename_pattern/rename_replacement ini paling sering dipakai. Setelah data ter-verifikasi, barulah alias dipindahkan (episode 4) untuk mengaktifkan index hasil restore.

#Partial dan Cross-Cluster Restore

#Partial Restore

Snapshot yang sebagian datanya gagal (misalnya satu index korup) tetap bisa di-restore dengan "partial": true — index yang sehat dipulihkan, yang rusak dilewati:

{
  "indices": "logs-*",
  "partial": true
}

#Cross-Cluster Restore

Snapshot bukan milik satu cluster — cluster lain bisa menariknya. Ini dasar dari disaster recovery multi-region: cluster di region A menyimpan snapshot, cluster di region B mengambilnya saat failover (episode 29). Caranya: daftarkan repository yang sama di cluster kedua, lalu restore biasa.

#Monitoring dan Keamanan Snapshot

GET /_snapshot/my-s3-repo/_status

GET /_snapshot/my-s3-repo/_all?verbose=false

Kolom state menampilkan SUCCESS, FAILED, PARTIAL, atau IN_PROGRESS. Buat alert untuk state selain SUCCESS (episode 21 membahas alerting).

Keamanan snapshot: repository cloud memakai credentials yang diatur di keystore Elasticsearch (bin/elasticsearch-keystore add s3.client.default.access_key), bukan plaintext. Enkripsi snapshot di sisi storage (server-side encryption) wajib untuk data sensitif — dan ingat, snapshot berisi salinan data pribadi, jadi perlakuannya harus sama ketatnya dengan data asli (episode 17).

#Kesalahan Umum

1. Repository di lokasi yang sama dengan data. Bencana menghancurkan keduanya — simpan off-site.

2. SLM tanpa retention. Snapshot menumpuk tanpa batas dan membebani biaya storage.

3. Restore ke nama index yang sama. Menimpa index aktif — restore dulu ke nama baru, verifikasi, baru pindah alias.

4. Tidak pernah uji restore. Strategi backup tidak lengkap tanpa drill berkala.

5. Credentials snapshot di plaintext. Gunakan keystore Elasticsearch.

#Penutup

Di episode 20 kalian menguasai strategi backup: konsep snapshot incremental, jenis repository (fs, S3, GCS, Azure), pembuatan repository, otomatisasi dengan SLM plus retention, operasi restore dengan rename, partial restore, cross-cluster restore, serta monitoring dan keamanan snapshot.

Inti yang harus dibawa pulang:

• Snapshot incremental — snapshot pertama penuh, berikutnya hanya delta.
• Repository off-site (S3/GCS/Azure) adalah standar production.
• SLM mengotomatiskan jadwal dan retensi — pantau kegagalannya.
• Restore ke nama index baru, verifikasi, baru pindahkan alias.
• Uji restore berkala adalah satu-satunya bukti backup berfungsi.

Backup melindungi data — tapi bagaimana tahu cluster sedang sehat sebelum terjadi masalah? Di episode 21 kita bahas monitoring dan observability: cluster health API, node stats, index stats, cat APIs; metrik JVM, indexing dan search rates, thread pool rejections, circuit breaker trips; serta tools — Kibana Monitoring, alerting, Metricbeat, APM, dan Prometheus/Grafana. Sampai jumpa!