Belajar Authentik - Backup & Disaster Recovery

#Pendahuluan

Episode 25 memberi kalian mata untuk melihat masalah: metrik dan alert yang memberi tahu kapan Authentik mulai menyimpang dari kondisi sehat. Tetapi melihat masalah dan mampu pulih dari masalah adalah dua hal yang berbeda. Server bisa terbakar, disk bisa rusak, database bisa terhapus karena kesalahan manusia, atau seluruh cluster bisa hilang karena kesalahan konfigurasi. Pertanyaannya bukan "apakah ini akan terjadi?", melainkan "ketika ini terjadi, apakah data kalian bisa kembali?".

Itulah topik episode ini: backup dan disaster recovery. Bayangkan backup seperti tabungan darurat — tidak pernah menyenangkan untuk menyiapkannya, tetapi saat krisis datang, ia membedakan antara gangguan kecil dan bencana yang menghancurkan. Bagi identity provider, kehilangan data berarti lebih dari sekadar kehilangan konfigurasi: seluruh user, kebijakan akses, dan alur autentikasi ikut lenyap. Mari kita bongkar apa yang sebenarnya perlu kalian amankan.

#Apa Saja yang Wajib Di-backup

Sumber kebenaran Authentik hampir seluruhnya berada di PostgreSQL. Di dalamnya tersimpan user, grup, aplikasi, provider, flow, stage, policy, event, dan seluruh konfigurasi. Dokumentasi resmi dengan tegas menyatakan: tanpa database, Authentik tidak bisa dikembalikan ke kondisi yang bisa digunakan. Ini prioritas mutlak.

Selain database, ada beberapa lapisan pelengkap:

Blueprint dan template — direktori /blueprints menyimpan blueprint yang kalian tulis, dan /custom-templates berisi modifikasi UI (episode 20). Keduanya direkomendasikan untuk di-backup, karena bisa jadi berisi logika yang tidak tersimpan di database.
Secret dan kunci — AUTHENTIK_SECRET_KEY, kredensial database, token API, serta sertifikat signing untuk JWT dan SAML. Kehilangan ini tidak membuat data lenyap, tetapi membuat token dan sesi tidak bisa diverifikasi, dan penyedia yang bergantung pada sertifikat lama akan menolak.
Konfigurasi deklaratif — values.yaml di Kubernetes atau docker-compose.yml dan .env di Compose. Nilai inilah yang menjelaskan bagaimana Authentik seharusnya berjalan.

Redis tidak perlu di-backup: ia cache dan message queue. Jika Redis hilang, sistem akan mengisi ulang cache dan melanjutkan antrian — kehilangan yang jauh lebih ringan dibandingkan database.

#Backup Database: pg_dump dan Strategi yang Tepat

PostgreSQL menyediakan tooling asli untuk backup: pg_dump untuk satu database, dan pg_dumpall untuk level cluster (role, hak akses global). Format custom (-Fc) direkomendasikan karena terkompresi, bisa di-restore paralel, dan memungkinkan restore selektif. Ingat untuk mengecualikan database sistem template0 dan template1.

Dump database ke format custom

pg_dump -h localhost -U authentik -Fc \
  -f authentik_20260803.dump authentik

Dalam setup Docker Compose, jalankan dump dari dalam container database:

pg_dump dari container Postgres

docker compose exec postgresql pg_dump -U authentik -Fc \
  -f /tmp/authentik.dump authentik
docker compose cp postgresql:/tmp/authentik.dump ./backups/

Kunci berikutnya: jangan menyimpan backup di mesin yang sama dengan datanya. Disk yang rusak biasanya membawa serta backup di dalamnya. Simpan salinan di luar host — object storage seperti S3/R2, NAS lain, atau bucket penyimpanan terpisah — idealnya di lokasi geografis berbeda dari produksi.

#Backup Konfigurasi: Ekspor Blueprint

Konfigurasi Authentik bisa diekspor sebagai blueprint — semacam "kode sumber" dari seluruh objek yang ada di database. Perintah ak export_blueprint dijalankan di dalam container worker:

Ekspor blueprint seluruh konfigurasi

docker compose exec worker ak export_blueprint > config.yaml

Hasilnya adalah satu file YAML berisi daftar semua objek: flow, stage, policy, provider, dan lainnya. Dua catatan penting: field yang bersifat write-only (misalnya client secret provider OAuth) tidak ikut diekspor, dan nilai default dilewati. Artinya, blueprint ini bukan pengganti backup database — ia pelengkap yang berguna untuk migrasi dan reproduksi konfigurasi di environment lain, serta menjadi sumber kebenaran tambahan yang bisa di-review sebagai kode.

Karena berbentuk teks, blueprint ini sangat nyaman disimpan di version control — kalian bisa melihat riwayat perubahan konfigurasi hanya dengan git diff config.yaml sebelum meng-commit versi baru. Ini mengubah "siapa mengubah apa dan kapan" menjadi catatan yang bisa dilacak, persis seperti praktik Infrastructure as Code dari episode 21.

#Jadwalkan dan Otomatiskan Backup

Backup manual hanya berfungsi jika diingat — dan di tengah kesibukan, "ingat nanti" hampir selalu berarti "tidak pernah". Otomasi adalah satu-satunya cara agar backup benar-benar berjalan setiap hari. Di Linux, cron adalah alat yang cukup:

Perhatikan opsi -T pada docker compose exec: ia menonaktifkan alokasi TTY, yang diperlukan agar perintah bisa berjalan dari cron tanpa terminal interaktif. Tandai hasilnya dengan tanggal pada nama file sehingga riwayat backup bisa diatur kebijakan retensinya (misalnya simpan 7 hari harian, 4 minggu mingguan, 12 bulan bulanan).

Tip

Jangan lupa memberi tahu siapa pun yang berwenang jika backup gagal. Sebuah script cron yang gagal diam-diam di tengah malam baru terasa saat dibutuhkan — dan saat itu sudah terlambat. Kirim notifikasi kegagalan lewat output cron, atau hubungkan script backup ke sistem alerting dari episode 25.

#Secret dan Signing Key: Aman dan Tersedia Saat Dibutuhkan

Ini bagian yang sering membuat orang terjebak. AUTHENTIK_SECRET_KEY dipakai untuk menandatangani sesi dan berbagai operasi kriptografis. Jika kunci ini dirotasi, seluruh sesi yang ada di-invalidasi. Untuk pemulihan bencana, aturannya simpel: simpan kunci yang sama di tempat yang aman — password manager, secret manager seperti Vault, atau lemari arsip yang terkunci — dan pastikan orang yang berwenang tahu cara mengaksesnya.

Hal yang sama berlaku untuk sertifikat signing JWT dan SAML. Sertifikat JWT bisa dibuat ulang, tetapi mengubahnya akan menolak token yang sudah beredar. Sertifikat SAML harus didaftarkan ulang di service provider jika berubah. Backup sertifikat bersama kunci privatnya (dalam format yang bisa di-import) menyelamatkan kalian dari pekerjaan mendaftarkan ulang di banyak aplikasi.

#Prosedur Disaster Recovery

Disaster recovery bukanlah satu perintah, melainkan prosedur yang terdokumentasi. Mulailah dengan menetapkan dua angka:

RPO (Recovery Point Objective) — berapa banyak data maksimal yang boleh hilang. Backup harian berarti RPO sekitar 24 jam; backup setiap 6 jam berarti RPO 6 jam.
RTO (Recovery Time Objective) — berapa cepat layanan harus pulih. Ini menentukan seberapa otomatis dan siap pakai prosedurnya.

Prosedur pemulihan secara umum:

Siapkan infrastruktur kosong (Compose stack atau cluster baru) dengan versi yang sama.
Pulihkan database sebelum menyalakan Authentik — inilah urutan yang benar menurut dokumentasi resmi.
Pulihkan volume /blueprints dan /custom-templates jika ada.
Set AUTHENTIK_SECRET_KEY dan kredensial database dengan nilai yang sama dengan produksi.
Nyalakan service dan verifikasi.

Restore database dari dump format custom memakai pg_restore:

Restore database dari dump

pg_restore -h localhost -U authentik -d authentik \
  --clean --if-exists authentik.dump

Opsi --clean --if-exists memastikan objek lama dihapus sebelum dibuat ulang, sehingga restore bisa dijalankan ke database yang sudah terisi tanpa error duplikasi.

#Uji Restore: Satu-Satunya Cara Memastikan

Inilah aturan emas backup yang paling sering dilanggar: backup yang tidak pernah diuji hanyalah ilusi keamanan. File backup yang korup, skrip yang salah target, atau dependensi yang berubah bisa membuat pemulihan gagal justru saat paling dibutuhkan.

Important

Jadwalkan uji restore secara berkala — misalnya sebulan sekali — ke environment terpisah (staging). Bukan sekadar memastikan file bisa dibaca, tetapi sampai tahap Authentik benar-benar berjalan dan bisa login. Hitung jumlah user dan aplikasi sebelum dan sesudah restore sebagai tanda verifikasi; angka yang tidak sama adalah alarm pertama.

Otomasi juga membantu: skrip backup yang berjalan otomatis harus menghasilkan laporan keberhasilan yang bisa dimonitor. Backup yang gagal diam-diam setiap malam adalah bom waktu — alerting dari episode 25 bisa didayagunakan untuk memantau status job backup itu sendiri.

#Penutup

Pada episode 26 ini kalian telah belajar bahwa backup Authentik berpusat pada PostgreSQL sebagai sumber kebenaran, dilengkapi blueprint dan custom templates, serta secret dan signing key yang harus tersimpan aman namun dapat diakses saat dibutuhkan. Kalian juga memahami pola pg_dump dan pg_restore dengan format custom, prosedur disaster recovery yang berbasis RPO dan RTO, serta alasan mengapa uji restore berkala adalah satu-satunya cara memastikan backup benar-benar berfungsi.

Inti yang harus kalian bawa:

Database adalah segalanya; backup yang menyimpan datanya di mesin yang sama tidak layak disebut backup.
Format custom pg_dump adalah pilihan yang tepat: terkompresi dan bisa di-restore selektif.
Blueprint hasil ak export_blueprint melengkapi, bukan menggantikan, backup database.
AUTHENTIK_SECRET_KEY dan sertifikat signing harus dicadangkan dan dijaga kerahasiaannya.
Restore yang belum pernah diuji sama dengan tidak punya backup.

Sistem yang bisa dipulihkan adalah sistem yang berani dioperasikan. Setelah data kalian aman, waktunya mempersempit celah keamanan. Di episode 27 berikutnya kita akan membahas Security Hardening: mengganti secret default, memperkuat AUTHENTIK_SECRET_KEY, terminasi TLS, rate limiting, penonaktifan registrasi, kebijakan password, penegakan 2FA, least privilege untuk admin, security headers, hingga cadence update yang disiplin. Sampai jumpa di episode 27!