All Products
Search
Document Center

Elasticsearch:Pemulihan bencana data

Last Updated:Apr 01, 2026

Opsi solusi

Elasticsearch (ES) menyediakan solusi pemulihan bencana jarak jauh berikut ini:

  • OSS snapshot backup and restoration: Cadangkan data indeks ke Object Storage Service (OSS) untuk penyimpanan persisten. Snapshot pertama merupakan cadangan penuh, sedangkan snapshot berikutnya merupakan cadangan inkremental. Anda dapat menggunakan repositori OSS lintas kluster untuk memulihkan data snapshot ke instans ES target. Untuk informasi selengkapnya, lihat Mencadangkan dan memulihkan data dengan menggunakan repositori OSS lintas kluster.

  • Logstash: Anda dapat mengonfigurasi pipeline untuk membaca data dari kluster sumber, memprosesnya, lalu menuliskannya ke kluster target. Pendekatan ini ideal untuk migrasi data antar versi utama atau ketika diperlukan penyaringan dan transformasi data. Untuk informasi selengkapnya, lihat Mulai cepat.

  • Reindex: API Reindex bawaan ES memungkinkan Anda menyalin seluruh atau sebagian data dari satu indeks ke indeks lain, termasuk lintas kluster. Solusi ini ideal untuk migrasi satu kali untuk set data kecil. Untuk informasi selengkapnya, lihat Migrasi data dengan menggunakan API Reindex.

  • Cross-Cluster Replication (CCR): CCR mereplikasi indeks yang dapat ditulis dari kluster leader ke satu atau beberapa kluster follower secara asinkron dan inkremental. Fitur ini mendukung sinkronisasi hampir real-time, sehingga cocok untuk skenario pemulihan bencana dengan persyaratan RPO dan RTO yang ketat. Untuk informasi selengkapnya, lihat Replikasi data lintas kluster dengan menggunakan CCR.

Perbandingan solusi

Solusi

Kasus Penggunaan

RPO

RTO

Batasan

OSS snapshot

Pencadangan dan pemulihan data skala besar secara berkala (dari gigabyte hingga petabyte).

Jam hingga hari (tergantung interval snapshot).

Beberapa jam (tergantung volume data dan waktu pemulihan shard).

Tidak mendukung sinkronisasi berkelanjutan. Layanan mungkin perlu dihentikan selama pemulihan.

Logstash

Migrasi data dengan kebutuhan real-time rendah, untuk data yang memerlukan penyaringan dan transformasi, atau untuk migrasi antar versi utama.

Detik hingga menit (tergantung frekuensi sinkronisasi).

Beberapa jam (tergantung volume data dan kinerja instans).

Hanya mendukung sinkronisasi batch; tidak real-time. Tidak mendukung operasi penghapusan.

Reindex

Migrasi indeks satu kali untuk set data kecil.

Tidak berlaku (operasi satu kali).

Menit hingga jam (tergantung volume data).

Tidak mendukung sinkronisasi berkelanjutan. Tidak efisien untuk migrasi data skala besar.

CCR

Pemulihan bencana jarak jauh, pemisahan baca/tulis, dan akses berbasis kedekatan geografis.

Hampir nol (detik).

Detik hingga menit.

Indeks follower bersifat read-only. Memerlukan pemetaan dan jumlah shard yang identik.

Untuk skenario pemulihan bencana jarak jauh dengan persyaratan RPO dan real-time yang ketat, CCR merupakan pilihan terbaik karena alasan berikut:

  • CCR menyinkronkan data dalam hitungan detik, sehingga meminimalkan kehilangan data.

  • Jika kluster leader mengalami kegagalan, Anda dapat melakukan failover ke kluster follower untuk memulihkan layanan tanpa penundaan seperti pada pemulihan snapshot.

  • Meskipun biaya penerapan awal lebih tinggi, CCR lebih hemat biaya dalam jangka panjang karena mencegah kerugian bisnis akibat kehilangan data.