Belajar Keycloak - Backup, Disaster Recovery & Upgrades

#Pendahuluan

Di episode 28 kalian membuat cluster cepat dan terukur. Episode 29 ini menjawab pertanyaan yang paling jarang disukai tapi paling penting: bagaimana kalau semuanya hancur? Backup melindungi data; disaster recovery mengembalikan layanan; upgrade menjaga keamanan dan fitur. Tiga kemampuan ini adalah asuransi yang tidak boleh tidak dimiliki deployment production.

#Strategi Backup

Keycloak menyimpan hampir semua hal penting di database. Tapi bukan hanya database yang harus di-backup:

Komponen	Cara Backup	Catatan
Database	`pg_dump` untuk PostgreSQL	Data user, sesi, klien, realm
Konfigurasi realm	`kc.sh export`	Resources, policies, permissions
Themes kustom	version control + artifact	Themes tidak ada di database
Custom extensions	image container + source	Provider JAR harus ikut tersimpan
Secrets dan config	environment / vault	Jangan pernah masuk repo

Backup database dilakukan dengan utilitas database asli:

Backup database Keycloak

pg_dump -h db.example.com -U keycloak -Fc keycloak > keycloak-$(date +%F).dump

pg_dump -Fc menghasilkan archive binary yang mudah dipulihkan dan dikompresi. Simpan backup di lokasi terpisah — idealnya objek storage yang berada di region berbeda — dan otomatisasi dengan cron atau systemd timer. Backup yang hanya diingat oleh manusia pada akhirnya tidak pernah terjadi.

Prinsipnya sederhana: jika data hilang dan tidak bisa dibangun ulang, ia wajib di-backup. Themes dan extensions memang bisa dibangun ulang dari source, tetapi database dan konfigurasi realm tidak. Backup yang baik juga adalah backup yang pernah dipulihkan — jadwalkan uji restore berkala ke database kosong, lalu jalankan health check login agar kalian tahu file backup tidak korup.

Ekspor konfigurasi realm melengkapi backup database:

Ekspor konfigurasi realm

kc.sh export --dir /backup/keycloak-config --realm bank

kc.sh export menggambarkan realm sebagai file — sangat berguna untuk memindahkan konfigurasi antar lingkungan (client policies dari episode 26, policies authorization dari episode 25) tanpa membawa data pengguna.

#Disaster Recovery

Backup tidak bernilai tanpa prosedur pemulihan yang teruji. Rancang disaster recovery plan dengan dua angka kunci:

Target	Arti	Contoh
RTO (Recovery Time Objective)	waktu maksimum layanan pulih	4 jam
RPO (Recovery Point Objective)	seberapa banyak data boleh hilang	15 menit

RPO menentukan frekuensi backup: RPO 15 menit berarti backup atau replikasi harus berjalan tiap 15 menit. RTO menentukan otomatisasi pemulihan: makin ketat RTO, makin banyak proses yang harus otomatis. Untuk multi-region, pertimbangkan replikasi database antar region dan DNS failover; tanpa itu, strategi yang realistis adalah backup dan restore ke region cadangan.

Multi-region menambah biaya dan kompleksitas replikasi. Untuk sebagian besar tim, strategi backup dan restore ke region cadangan sudah cukup — pastikan RTO-nya memenuhi janji SLA sebelum mengejar topologi multi-region penuh. RTO dan RPO juga bukan sekadar angka di dokumen: keduanya harus diuji, mulai dari angka realistis lalu diperketat seiring otomatisasi membaik.

Recovery procedures — tulis langkah pemulihan langkah demi langkah, dari restore database sampai verifikasi login.
Failover strategies — pastikan alternatif yang dipilih memang bisa dieksekusi saat zona utamanya mati.
DR testing — uji prosedur secara berkala di lingkungan terpisah; prosedur yang tidak pernah diuji adalah harapan kosong.

#Upgrade Procedures

Upgrade Keycloak adalah bagian dari siklus hidup, bukan peristiwa langka. Langkah amannya:

Version compatibility — baca migration guide yang dirilis tiap versi; perhatikan perubahan konfigurasi, endpoint, dan fitur yang dihapus.
Pre-upgrade preparation — backup database dan konfigurasi lengkap, lalu catat versi lama dan pengaturan yang diubah.
Database migration — Keycloak memigrasikan skema database secara otomatis saat pertama kali dijalankan dengan versi baru; pastikan backup ada sebelum langkah ini.
Rolling upgrade — naikkan node satu per satu di belakang load balancer, sehingga layanan tidak pernah berhenti total.
Rollback procedures — simpan image versi lama dan backup, sehingga kalian bisa kembali jika upgrade menemukan masalah.

Contoh alur rolling upgrade:

Rolling upgrade node per node

# 1. Keluarkan node pertama dari rotasi load balancer
# 2. Jalankan image versi baru pada node tersebut
# 3. Tunggu /health/ready menandakan sehat
# 4. Masukkan kembali, lalu ulangi untuk node berikutnya

Rolling upgrade menjaga SLA: selama ada satu node sehat, user tidak merasakan apa-apa. Khusus untuk database migration, jalankan satu node terlebih dahulu dan amati log sebelum node lain ikut naik versi.

Pilih jendela upgrade di jam sepi dan uji di tenant staging terlebih dahulu. Upgrade kecil dan rutin lebih aman daripada lonjakan besar yang jarang — semakin dekat versi kalian ke versi terakhir yang didukung, semakin kecil lompatan migrasi yang harus dihadapi.

#Migration

Membawa konfigurasi antar realm atau lingkungan adalah pekerjaan sehari-hari:

Realm export/import — kc.sh export dan kc.sh import memindahkan seluruh definisi realm: klien, users, groups, roles, policies, dan permissions. Impor ke lingkungan baru:

Import konfigurasi realm

kc.sh import --dir /backup/keycloak-config

User migration — data user berpindah lewat database atau import; pastikan hashing password kompatibel antar versi.
Client migration — klien dan redirect URI ikut dalam export/import; verifikasi metadata dan metode autentikasi klien (episode 26).
Testing migration — selalu impor ke lingkungan staging dulu, jalankan alur login lengkap, baru rilis ke production.

Jangan lupa mem-backup konfigurasi deployment itu sendiri: nilai environment, compose file, dan file kustomisasi. Tanpa itu, restore database ke mesin baru tetap sulit karena lapisan luar yang mengelilingi Keycloak tidak lengkap.

Warning

Jangan pernah mengimpor konfigurasi production ke lingkungan yang sedang berjalan tanpa meninjau isinya. Export/import adalah alat transfer, bukan alat merger — konfigurasi yang ditimpa bisa menghapus pengaturan yang sudah di-tune.

#Penutup

Episode 29 melindungi deployment kalian: backup database dengan pg_dump, backup konfigurasi dengan kc.sh export, disaster recovery dengan target RTO dan RPO yang jelas, upgrade versi yang aman dengan backup dan rolling upgrade, serta migrasi realm antar lingkungan yang teruji.

Inti yang harus dibawa pulang:

Backup yang tidak otomatis tidak akan terjadi — jadwalkan, simpan off-site, dan verifikasi.
RTO dan RPO menentukan desain DR — keduanya harus diukur, bukan ditebak.
Upgrade dimulai dari backup — migration guide, backup, dan rolling upgrade adalah urutan wajib.
Uji pemulihan berkala — DR yang tidak pernah diuji adalah DR yang tidak ada.

Di episode 30 — episode terakhir — kalian merangkum semuanya: troubleshooting & best practices untuk menghadapi masalah nyata dan checklist lengkap sebelum meluncurkan Keycloak ke production.