Belajar Authelia - Backup & Disaster Recovery
Data MFA yang hilang artinya pengguna harus daftar ulang seluruh perangkat. Episode ini menyusun strategi backup Authelia: apa yang wajib di-backup, jadwal dan enkripsi, prosedur restore langkah demi langkah, rotasi secret, skenario bencana, serta pengujian backup agar tidak menipu diri sendiri.
#Pendahuluan
Episode 26 mengajarkan cara mengamati Authelia: log, metrik, dan alerting memberitahu kapan ada masalah. Tapi observability tidak menyelamatkan data. Kalau database Authelia rusak tanpa cadangan, setiap pengguna harus mendaftarkan ulang seluruh perangkat MFA — TOTP, WebAuthn, semuanya — sekaligus. Itu bukan sekadar malam yang melelahkan; itu kehilangan kepercayaan.
Episode 27 menyusun strategi backup dan disaster recovery: apa yang wajib disimpan, bagaimana menjadwalkan dan mengamankannya, cara mengembalikan saat bencana, hingga rotasi secret. Backup adalah asuransi — membosankan saat semuanya baik, tak ternilai saat segalanya berantakan.
#Apa yang Wajib di-Backup
Authelia menyimpan data penting di beberapa tempat. Daftar lengkapnya:
| Data | Lokasi | Konsekuensi jika hilang |
|---|---|---|
| File konfigurasi | configuration.yml | Seluruh konfigurasi harus disusun ulang dari nol |
| Database user | users_database.yml | Semua user dan hash password hilang |
| Storage database | PostgreSQL / MySQL / SQLite | TOTP, WebAuthn, token OIDC hilang — MFA harus daftar ulang |
| Sesi | Redis | Pengguna login ulang (paling ringan dampaknya) |
| Secret | Session secret, JWT, storage encryption key | Sesi tidak terbaca, data MFA tidak bisa didekripsi |
| Sertifikat TLS | Let's Encrypt / CA internal | HTTPS putus |
Perhatikan hierarki dampaknya. Kehilangan sesi di Redis hanya memaksa login ulang. Kehilangan storage database adalah bencana menengah: pengguna masih bisa login dengan password, tapi semua faktor kedua hilang. Kehilangan secret berarti data MFA yang ter-enkripsi di database menjadi tidak terbaca — backup yang ada pun percuma jika tidak menyertakan kunci.
#Strategi Backup
Terapkan aturan 3-2-1: tiga salinan data, di dua media berbeda, satu di lokasi terpisah. Untuk komponen Authelia:
- PostgreSQL. Backup logis dengan
pg_dumpdalam format custom, dijalankan sebagai scheduled task (cron atau K8s CronJob), lalu kirim salinannya ke object storage:
pg_dump -U authelia -h postgres-primary -d authelia -Fc \
-f /backup/authelia-$(date +%F).dump- Redis. Sesuatu yang bisa di-rebuild tidak perlu di-backup seagresif database. Ambil snapshot RDB berkala untuk memulihkan sesi aktif setelah restart massal:
redis-cli -a '<redis-password>' SAVE
cp /var/lib/redis/dump.rdb /backup/redis-dump.rdb- File.
configuration.ymldanusers_database.ymlcukup di-copy, tapi karena memuat rahasia, enkripsikan dulu. Kalau konfigurasi sudah hidup di Git dengan rahasia yang dipisah ke Vault, file-file ini tinggal di-render ulang dari source of truth.
Warning
Rahasia harus ikut di-backup — enkripsi saat istirahat itu kunci, bukan rintangan. Simpan salinan secret yang sudah di-enkripsi GPG atau di Vault bersama backup. Skenario paling menyakitkan adalah punya backup database yang bagus tapi tidak punya storage encryption key untuk membukanya.
#Prosedur Restore
Restore yang baik berurutan dari bawah ke atas. Urutan untuk bencana penuh:
- Pulihkan storage database terlebih dahulu — semua hal lain bergantung padanya.
pg_restore -U authelia -h postgres-primary -d authelia \
--clean --if-exists /backup/authelia-2026-08-03.dump- Pulihkan file konfigurasi dan users database ke lokasi asli.
- Pulihkan secret yang sama persis dengan saat backup diambil.
- Pulihkan Redis bila ingin sesi ikut kembali; bila tidak, sesi lama dianggap hangus dan pengguna login ulang.
- Validasi sebelum membuka pintu: jalankan
authelia validate-config --config /config/configuration.ymldanauthelia storage schema-infountuk memastikan konfigurasi valid dan schema database cocok, lalu uji satu login.
Restore yang tidak diuji adalah harapan belaka. Kalian tidak ingin menguji prosedur ini pertama kali di tengah insiden nyata.
#Rotasi Secret
Rotasi secret Authelia perlu dipahami efek sampingnya. Session secret digunakan untuk mengenkripsi data sesi — menggantinya mengakibatkan seluruh sesi aktif menjadi tidak valid. Ini bukan bug, tapi fitur: saat ada dugaan kebocoran, mengganti session secret adalah cara instan memutus semua sesi.
Storage encryption key melindungi data MFA di database. Authelia menyediakan perintah khusus untuk menggantinya tanpa kehilangan data:
authelia storage encryption change-key --new-key '<kunci-baru>'Rotasi secret harus menjadi agenda terjadwal, bukan reaksi — misalnya setiap 90 hari untuk session secret dan JWT secret, dan uji rotasi storage key di environment staging sebelum produksi.
#Skenario Bencana dan RTO/RPO
Rencanakan bencana sebelum terjadi dengan menetapkan dua angka:
- RPO (Recovery Point Objective): seberapa jauh mundur data yang bisa kalian terima. Backup harian berarti RPO 24 jam — registrasi MFA yang terjadi sejak backup terakhir akan hilang.
- RTO (Recovery Time Objective): seberapa cepat layanan harus kembali. Ini menentukan seberapa otomatis prosedur restore kalian.
Tiga skenario umum dan cara menanganinya:
| Skenario | Dampak | Respons |
|---|---|---|
| Instance Authelia mati | Semua gerbang tertutup | Ganti instance dari image yang sama; sesi di Redis ikut pulih |
| Database korup | MFA hilang, login password tetap jalan | Restore dump terakhir; pengguna daftar ulang perangkat sejak RPO |
| Satu region hilang | Semua infrastruktur lenyap | Restore dari backup off-site ke region kedua; butuh dokumentasi lengkap |
Catatan penting: dalam arsitektur HA di episode 24 dan 25, instance Authelia bukanlah hal yang "di-restore" — ia di-replace. Yang benar-benar dipulihkan adalah data: database, file, dan secret.
#Menguji Backup
Backup yang tidak pernah diuji adalah tebakan. Jadwalkan restore drill rutin: setidaknya sekali sebulan, restore dump ke environment terpisah, jalankan Authelia di sana, dan uji login + MFA sungguhan. Banyak tim menemukan dump yang korup, kunci yang hilang, atau prosedur yang salah persis saat drill pertama.
Otomasikan sebanyak mungkin. Di Kubernetes, sebuah CronJob yang menjalankan pg_dump, meng-encrypt hasilnya, dan mengunggah ke object storage menghilangkan kesalahan manusia dari persamaan. Dokumentasikan semuanya — skrip, urutan, dan kontak — karena saat insiden, ingatan adalah hal pertama yang hilang.
#Penutup
Episode 27 memberi kalian asuransi digital Authelia: memahami apa yang wajib di-backup beserta dampak kehilangannya, menerapkan strategi 3-2-1 dengan pg_dump, snapshot Redis, dan enkripsi secret, menjalankan restore berurutan dengan validasi di akhir, merotasi secret termasuk authelia storage encryption change-key, serta menetapkan RTO/RPO dan menguji backup dengan restore drill rutin.
Poin kunci:
- Storage database adalah aset terpenting; sesi Redis yang hilang cuma soal login ulang.
- Secret harus ikut di-backup — backup tanpa kunci adalah enkripsi sia-sia.
- Rotasi session secret memutus semua sesi; rotasi storage key butuh perintah khusus.
- Tetapkan RTO/RPO sebelum bencana, bukan saat bencana.
- Uji restore secara rutin; backup yang tidak pernah dipulihkan tidak bisa dipercaya.
Infrastruktur aman dan bisa dipulihkan. Sekarang bagaimana membuatnya cepat? Di episode 28 kita bedah Performance Tuning: benchmark, tuning Redis dan database, optimasi di reverse proxy, hingga capacity planning. Sampai jumpa di episode 28!