Belajar LDAP - Backup & Restore

#Pendahuluan

Di episode 23 kalian membangun proxy dan gateway patterns agar sistem lain bisa mengakses directory secara terpusat dan terkontrol. Semakin banyak sistem yang bergantung pada LDAP, semakin fatal akibatnya kalau directory itu hilang atau rusak. Episode 24 ini membahas pertahanan terakhir: backup dan restore. Kalian akan belajar ekspor data dengan slapcat, pemulihan dengan slapadd, backup file database mdb, perencanaan disaster recovery, dan praktik terbaik yang memastikan data identitas kalian selalu bisa dipulihkan — kapan pun dibutuhkan.

#Strategi Backup

Ada empat pendekatan backup yang saling melengkapi, masing-masing dengan trade-off antara kecepatan, ketepatan, dan kerumitan:

Metode	Sifat	Konten	Kapan digunakan
`slapcat` (online)	Server tetap berjalan	LDIF lengkap satu naming context	Backup terjadwal harian
`slapadd` (restore)	Server berhenti	Membaca LDIF ke database	Pemulihan setelah kegagalan
`syncrepl` (replikasi)	Online terus-menerus	Replica entry identik dengan provider	Replica baca dan DR
Copy file database	Server berhenti	File mentah mdb	Snapshot saat server off

Kombinasi paling umum di production: backup LDIF harian via slapcat untuk memenuhi RPO, ditambah replica syncrepl yang selalu sinkron sebagai lapisan failover, dan file snapshot untuk pemulihan cepat. Strategi point-in-time recovery (PITR) di OpenLDAP tidak sekuat database relasional — tidak ada transaction log yang bisa di-replay. Pendekatan yang realistis adalah mengombinasikan dump LDIF berkala dengan replica yang sengaja di-lag (disinkronkan dengan jeda), sehingga kalian punya titik pemulihan berjarak tidak jauh dari saat ini.

#Ekspor Database dengan slapcat

slapcat adalah alat ekspor utama OpenLDAP. Ia membaca database langsung dari disk (bukan melalui jaringan), sehingga hasilnya konsisten meskipun ada aktivitas penulisan. Tanpa opsi -b, slapcat mengekspor semua naming context; dengan -b kalian bisa memilih satu suffix; -n 0 khusus mengekspor database konfigurasi cn=config.

Backup data dan konfigurasi ke LDIF

slapcat -b "dc=example,dc=com" -l /backup/ldap-data.ldif
slapcat -n 0 -l /backup/ldap-config.ldif

slapcat dengan -n 0 menghasilkan LDIF yang memuat seluruh cn=config — termasuk ACL, schema, dan overlay. Ini penting karena konfigurasi adalah bagian dari aset yang harus dipulihkan, bukan hanya datanya. Hasilnya LDIF teks biasa, sehingga mudah diverifikasi, di-version-control, dan bisa dibaca manusia. Gunakan -o ldif-wrap=no bila ingin menghindari pembungkusan baris yang panjang.

Backup tidak berguna kalau tidak terjadwal. Gunakan cron dengan skrip yang mencatat tanggal dan verifikasi hasil:

#Prosedur Restore dengan slapadd

slapadd adalah kebalikan dari slapcat: ia membaca file LDIF dan menulisnya ke database slapd. Aturannya sederhana namun kaku — slapd harus berhenti saat slapadd berjalan, karena alat ini mengakses file database secara langsung. Untuk restore in-place setelah data rusak:

Restore in-place database data

systemctl stop slapd
sudo -u openldap rm -f /var/lib/ldap/data.mdb /var/lib/ldap/lock.mdb
sudo -u openldap slapadd -l /backup/ldap-data.ldif
sudo -u openldap chown -R openldap:openldap /var/lib/ldap
systemctl start slapd

Jangan lupa hapus file mdb yang lama sebelum slapadd — kalau tidak, entry hasil restore akan menumpuk di atas data yang sudah rusak. Konfigurasi dipulihkan terpisah: ganti seluruh isi /etc/ldap/slapd.d dari backup konfigurasi (atau jalankan slapadd -n 0 -l config.ldif), lalu perbaiki permission menjadi openldap:openldap.

Untuk fresh installation restore (server baru menggantikan yang mati), langkahnya sama: pasang paket slapd, hentikan service, hapus database default hasil instalasi, lalu slapadd. Yang paling sering dilupakan adalah menguji restore — backup yang tidak pernah di-restore adalah harapan semu. Jadwalkan uji restore di lingkungan staging setiap periode tertentu, bukan menunggu bencana terjadi.

#Backup File Database MDB

Backend mdb menyimpan semua data dalam satu file data.mdb plus lock.mdb. Meng-copy kedua file ini saat slapd berjalan sangat berisiko — hasil copy bisa korup karena slapd sedang menulis. Copy file yang aman hanya dilakukan saat server berhenti:

Backup offline file database

systemctl stop slapd
tar czf /backup/ldap-mdb-$(date +%Y%m%d).tar.gz /var/lib/ldap /etc/ldap/slapd.d
systemctl start slapd

Alternatifnya, gunakan snapshot filesystem (misalnya LVM lvcreate -s atau snapshot ZFS) — ini menyediakan titik pemulihan yang konsisten tanpa downtime panjang. Tentang incremental backup: mdb tidak memiliki mekanisme incremental built-in seperti database relasional. Pendekatan yang lazim adalah backup penuh berkala dari replica (agar beban ekspor tidak mengganggu master), ditambah lag replica sebagai jendela pemulihan yang sempit.

#Disaster Recovery

Disaster recovery (DR) adalah rencana pemulihan menyeluruh, bukan sekadar copy data. Dua metrik yang wajib kalian tetapkan sejak awal:

Metrik	Makna	Contoh strategi
RPO	Seberapa banyak data yang boleh hilang	Backup harian memberi RPO maksimal 24 jam
RTO	Seberapa lama layanan boleh mati	Playbook restore yang teruji menekan RTO ke jam, bukan hari

Susun prosedur pemulihan langkah demi langkah: siapa yang menjalankan, server pengganti apa yang dipakai, dari mana backup diambil, dan bagaimana memverifikasi hasilnya. Dokumentasikan semuanya di repo atau wiki, lalu uji skenario DR secara berkala — matikan master di staging dan praktikkan promosi replica serta restore dari backup. DR yang tidak pernah diuji adalah dokumen yang menyesatkan.

#Best Practices Backup

Jadwal tetap — backup otomatis harian, jangan andalkan ingatan manusia.
Offsite — simpan salinan di lokasi berbeda dari server (object storage atau host lain).
Enkripsi — backup identitas berisi data sensitif; enkripsi sebelum dipindahkan:

Enkripsi file backup

openssl enc -aes-256-cbc -pbkdf2 \
  -in /backup/ldap-data.ldif \
  -out /backup/ldap-data.ldif.enc

Retention — tetapkan berapa lama backup disimpan (misalnya harian 7 hari, mingguan 4 minggu, bulanan 12 bulan) dan otomatiskan penghapusan.
Uji otomatis — skrip verifikasi yang memastikan file backup tidak kosong dan slapadd berhasil menyerapnya.

Warning

Permission file backup sama pentingnya dengan isinya. File LDIF berisi userPassword (walau di-hash) dan data pribadi pengguna. Pastikan hanya user openldap dan root yang bisa membaca: chmod 600 dan simpan kunci enkripsi terpisah dari backup itu sendiri.

Tip

Sebagai latihan cepat, coba skenario "hapus satu entry lalu pulihkan dari backup kemarin" di mesin uji. Kalau kalian bisa melakukannya tanpa membaca dokumentasi, berarti prosedur restore kalian benar-benar siap.

#Penutup

Pada episode 24 ini, kalian mempelajari empat strategi backup, ekspor database dan konfigurasi dengan slapcat, pemulihan dengan slapadd, backup file database mdb, perencanaan RPO dan RTO, serta praktik terbaik seperti enkripsi, offsite, dan pengujian otomatis.

Inti yang harus dibawa pulang:

Backup yang tidak pernah di-restore bukanlah backup — uji pemulihan secara rutin.
slapcat untuk online backup, slapadd untuk restore offline — dua alat ini adalah pasangan wajib.
Backup konfigurasi cn=config sama pentingnya dengan backup data.
RPO dan RTO menentukan seberapa sering backup dan seberapa cepat kalian pulih.

Di episode 25 berikutnya, kita membahas performance tuning — bagaimana mengindeks dengan benar, menyetel ukuran cache dan limit koneksi, serta membuat directory kalian tetap responsif saat beban pengguna meningkat.