Belajar RabbitMQ - Backup, Restore & Disaster Recovery

#Pendahuluan

Di episode 30, topologi RabbitMQ menjadi kode yang tersimpan di Git. Itu membuat definisi mudah dipulihkan — tapi bagaimana dengan pesan di dalam queue? Definisi yang hilang bisa dibuat ulang, tetapi pesan yang sudah dikonfirmasi dan belum diproses, jika hilang, mungkin tidak pernah bisa diganti. Inilah inti persoalan backup RabbitMQ.

Penting dipahami sejak awal: RabbitMQ tidak menyediakan snapshot file yang bisa dicopy begitu saja, karena data tersebar di segmen-segmen file internal. Strategi backup yang benar berfokus pada dua hal: definisi topologi (yang kecil dan mudah) dan pesan (yang butuh pendekatan khusus).

Episode ini membahas backup dan restore definisi, opsi untuk pesan, perencanaan RPO dan RTO untuk disaster recovery, penggunaan Federation dan Shovel sebagai strategi DR, serta migrasi antar cluster tanpa downtime.

#Backup Strategies

#Backup Definisi (Configuration)

Definisi mencakup vhost, user, permission, policy, queue, exchange, dan binding — semua yang dibutuhkan untuk membangun ulang topologi. Ekspor lewat Management API:

curl -u arman:pass http://localhost:15672/api/definitions \
  -o rabbit-definitions.json

Sertakan backup definisi di jadwal otomatis, misalnya cron harian. Simpan di lokasi terpisah dari broker — jika node hilang, file backup harus tetap aman.

#Otomasi Backup

Jadwalkan ekspor definisi secara berkala dengan skrip sederhana:

0 2 * * * curl -u arman:pass \
  http://localhost:15672/api/definitions \
  -o /backup/rabbit-$(date +\%F).json

Tambahkan rotasi agar file lama tidak menumpuk, misalnya menyisakan 30 hari terakhir. Versioning file backup di object storage memberi tanggal pemulihan yang jelas: kapan definisi terakhir diekspor, dan pada kondisi topologi apa.

#Backup Pesan

RabbitMQ tidak punya mekanisme snapshot pesan. Opsi yang umum:

• Shovel replikasi — salin pesan ke broker cadangan secara terus-menerus.
• Replay dari consumer — consumer membaca pesan dan menulisnya ke storage eksternal (misalnya object storage).
• Quorum queue — replikasi di dalam cluster melindungi dari kegagalan node, bukan dari bencana skala besar.

Keputusan desain yang jujur: sering kali pesan di queue dianggap transient dan boleh hilang, sedangkan data bisnis sejati disimpan di database lain. Tetapkan kebijakan ini secara eksplisit.

#Restore Procedures

#Import Definisi

Untuk memulihkan topologi, impor definisi yang telah diekspor:

rabbitmqctl import_definitions /path/rabbit-definitions.json

Perintah import_definitions membuat ulang vhost, queue, exchange, user, dan policy. Ingat: import definisi tidak memulihkan pesan yang hilang — hanya struktur.

#Kompatibilitas Versi

Definisi yang diekspor dari versi lama bisa diimpor ke versi baru, tapi bukan sebaliknya. Saat melakukan restore ke broker yang lebih baru, verifikasi argumen queue dan policy yang tidak lagi didukung. Selalu uji prosedur restore di environment staging sebelum bergantung padanya.

#Disaster Recovery

#Multi-Region, RPO, dan RTO

RPO (Recovery Point Objective) adalah seberapa banyak data yang boleh hilang; RTO (Recovery Time Objective) adalah seberapa cepat layanan harus pulih. Contoh: RPO 15 menit berarti backup atau replikasi hanya boleh tertinggal 15 menit; RTO 1 jam berarti tim harus pulih dalam 1 jam.

Desain multi-region: pasang broker di dua region, replikasi topologi dengan Federation, dan alihkan koneksi aplikasi ke region cadangan saat region utama gagal. Uji failover secara berkala — DR yang tidak pernah diuji hanyalah harapan.

#Federation dan Shovel untuk DR

Federation memberi replikasi topologi dan pesan antar cluster — bagus untuk RPO kecil. Shovel bisa menyalin pesan ke queue di region cadangan secara selektif. Kombinasi keduanya membentuk pipeline DR yang berjalan terus-menerus, sehingga saat bencana, region cadangan sudah punya data terbaru.

#Data Migration

#Migrasi Antar Cluster dan Zero-Downtime

Migrasi antar cluster (misalnya pindah versi atau region) memakai pola yang sama dengan episode 20: bangun cluster baru, hubungkan dengan Shovel untuk menyalin pesan, alihkan consumer secara bertahap, lalu matikan yang lama.

shovels.migrate = [
  {source, [{uris, ["amqp://old-cluster"]}, {queue, "orders.q"}]},
  {destination, [{uris, ["amqp://new-cluster"]}, {queue, "orders.q"}]}
]

#Message Replay Strategy

Untuk migrasi yang menuntut akurasi penuh, kombinasikan shovel dengan replay: consumer di cluster lama membaca pesan dan mem-publish ulang ke cluster baru setelah verifikasi. Replay memberi kontrol lebih (bisa di-validasi) dibanding shovel buta, dengan mengorbankan latensi.

#Penutup

Di episode 31 ini kalian sudah mengekspor dan mengimpor definisi, menyusun strategi backup pesan, merencanakan RPO dan RTO, memanfaatkan Federation dan Shovel untuk disaster recovery, serta melakukan migrasi antar cluster tanpa downtime.

Inti yang harus dibawa pulang:

• Definisi topologi adalah backup utama yang mudah dan kecil.
• Pesan tidak punya snapshot; backup lewat shovel, replay, atau external storage.
• Import definisi memulihkan struktur, bukan isi pesan.
• RPO mengukur data yang boleh hilang; RTO mengukur kecepatan pulih.
• Federation dan Shovel adalah tulang punggung strategi DR multi-region.
• Migrasi antar cluster memakai shovel atau replay dengan alih-alih bertahap.
• Latih prosedur restore sebelum bencana benar-benar terjadi.

Di episode 32 selanjutnya — episode terakhir — kita akan merangkum seluruh perjalanan dengan production deployment checklist — capacity planning, security hardening, monitoring, upgrade prosedur, performance baselines, pitfall yang harus dihindari, dan daftar fitur modern 3.11 hingga 3.13 yang harus kalian manfaatkan. Ini gerbang kelulusan menuju RabbitMQ produksi!