Belajar Active Directory - Active Directory Disaster Recovery

#Pendahuluan

Di episode 25 kita memindahkan identitas organisasi ke struktur baru. Setelah migrasi selesai dan semuanya berjalan, muncul pertanyaan yang paling tidak nyaman untuk ditanyakan: apa yang terjadi jika DC kalian mati — atau lebih buruk, jika seluruh forest runtuh?

Disaster recovery (DR) bukan tentang alat backup yang hebat. DR adalah jawaban jujur atas dua angka: berapa cepat kalian bisa kembali beroperasi, dan berapa banyak data yang rela kalian korbankan. Episode ini membedah cara menjawab keduanya, lalu membangun prosedur yang bisa dijalankan di bawah tekanan.

#Perencanaan DR: RTO dan RPO

Sebelum memikirkan alat, tetapkan target. Dua metrik ini menjadi kompas seluruh desain DR:

• RTO (Recovery Time Objective) — berapa lama layanan boleh mati sebelum dikembalikan.
• RPO (Recovery Point Objective) — seberapa jauh data yang hilang masih bisa diterima.

Angka RTO dan RPO bukan keputusan teknis murni — mereka ditentukan oleh kebutuhan bisnis. Helpdesk yang mati 8 jam mungkin menimbulkan keluhan; sistem produksi yang mati 8 jam bisa berarti kerugian besar.

#Backup System State

System state pada DC berisi semua yang dibutuhkan untuk mengembalikan perannya: registry, SYSVOL, database AD (ntds.dit) beserta log-nya, file boot, dan data AD CS bila terpasang di DC yang sama. Ini bukan full backup server — ini backup "jiwa" DC.

Pasang Windows Server Backup lalu jadwalkan backup system state harian:

Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools

wbadmin start systemstatebackup -backupTarget:E: -quiet

Terapkan aturan 3-2-1: tiga salinan data, di dua media berbeda, satu disimpan di luar lokasi utama. Backup DC yang disimpan di disk yang sama dengan DC-nya sendiri bukan backup — ia musnah bersamaan saat disk mati.

#Memulihkan DC Tunggal

Prioritas pertama setiap DC yang bermasalah: apakah DC lain di domain masih sehat? Jika ya, pendekatan terbaik adalah rebuild dan promote ulang — buang DC yang rusak, jalankan metadata cleanup, lalu promosi DC baru. Ini lebih cepat dan lebih aman daripada restore.

Restore baru diperlukan saat semua DC down atau DC yang rusak adalah yang terakhir. Prosesnya:

bcdedit /set safeboot dsrepair
restart
wbadmin start systemstaterecovery -version:07/20/2026-08:00 -quiet
bcdedit /deletevalue safeboot
restart

Ambil string -version dari wbadmin get versions. Setelah restore, DC kembali online dan menyerap perubahan dari DC lain — ini disebut restore non-authoritative.

#Non-Authoritative vs Authoritative

• Non-authoritative (normal): DC menerima data hasil restore lalu diperbarui oleh DC lain yang lebih baru. Cocok untuk memulihkan satu DC yang hilang.
• Authoritative: objek yang di-restore menang atas DC lain — dipakai saat objek terhapus dan ingin dikembalikan. Dijalankan lewat ntdsutil setelah restore non-authoritative:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Karyawan,DC=corp,DC=local"
quit
quit

Untuk objek yang terhapus, Active Directory Recycle Bin (episode 17) adalah alternatif modern yang jauh lebih sederhana — asalkan fitur ini sudah diaktifkan sebelum bencana.

#Bahaya USN Rollback

Ini kesalahan DR paling berbahaya. Bayangkan: sebuah DC terus berjalan dan menerima replikasi, lalu seseorang me-restore backup lama di DC tersebut. Backup itu membawa Update Sequence Number (USN) yang sudah lama tertinggal. Ketika DC kembali online, ia menawarkan perubahan "baru" kepada DC lain — padahal itu data lama yang sudah dihapus. DC lain menerimanya dan data mutakhir pun hilang dari forest.

Pencegahannya sederhana: jangan pernah me-restore backup DC yang baru saja online dan bereplikasi. Jika DC sudah terhubung dan bereplikasi, lebih aman buang dan promosi DC baru. Setelah restore apa pun, verifikasi dengan repadmin /showrepl dan dcdiag sebelum memercayai DC tersebut.

#Forest Recovery: Ketika Semuanya Jatuh

Forest recovery menangani skenario terburuk: banyak DC mati bersamaan, atau backup yang tersedia tidak sinkron. Prosedur resmi Microsoft mengikuti pola berikut:

1. Identifikasi cakupan. Berapa DC yang jatuh, berapa data yang hilang, apakah ada DC yang selamat dan bisa diandalkan.
2. Isolasi. Jangan biarkan DC lain ikut online dan mulai bereplikasi dengan data basi.
3. Pilih DC pemulihan. Pilih satu DC dengan backup terbaru dan paling lengkap, restore non-authoritatively, lalu nyalakan sebagai "benih" forest.
4. Bersihkan metadata. Hapus metadata DC lain yang tidak akan dikembalikan dengan ntdsutil metadata cleanup.
5. Bangun ulang. Promosi DC baru lainnya dan biarkan mereka bereplikasi dari DC pemulihan.
6. Verifikasi. Pastikan SYSVOL (DFSR), FSMO roles, DNS, dan replikasi kembali normal.

Seluruh prosedur ini harus tertulis dan sudah pernah dijalankan di lab — bukan dibaca dari artikel saat kebakaran sedang terjadi.

#Membangun Situs DR dan Menguji Rencana

#Situs DR

Lokasi kedua dengan DC sendiri adalah cara terbaik menangani skenario "satu situs hilang". Beberapa pertimbangan:

• Letakkan DC writable di situs DR, bukan hanya RODC — RODC tidak bisa menulis jika WAN putus.
• Desain site link dan cost agar autentikasi tetap cepat saat lalu lintas dialihkan (episode 3 dan 27).
• Pertimbangkan DC virtual di cloud (Azure, AWS) sebagai opsi DR dengan TCO lebih rendah.

#Restore Test

Aturan emas DR: jika backup belum pernah di-restore, ia tidak bisa dianggap berfungsi. Jadwalkan restore test berkala — misalnya setiap kuartal — di lingkungan lab terisolasi: restore system state, nyalakan, jalankan dcdiag, dan catat hasilnya. Ukur durasi terhadap RTO dan volume data yang dipulihkan terhadap RPO. Kegagalan di lab jauh lebih murah daripada kegagalan di produksi.

#Keamanan Data Backup

Backup AD adalah sumber kebenaran identitas — dan karena itu juga target penyerang. Penyerang yang menguasai backup DC bisa mengekstrak hash semua akun tanpa pernah menyentuh jaringan. Karena itu:

• Enkripsi media backup dan batasi akses ke sistem backup.
• Simpan salinan offsite yang tidak terhubung ke jaringan utama.
• Lindungi password DSRM dengan proses manajemen secret yang ketat (episode seri secret management).
• Dokumentasikan runbook DR: langkah restore yang sudah diuji, daftar kontak, dan lokasi semua sandi pemulihan.

#Penutup

Di episode 26 ini kalian membangun fondasi DR yang jujur: menetapkan RTO dan RPO dari kebutuhan bisnis, backup system state harian dengan aturan 3-2-1, pemulihan DC tunggal via rebuild atau restore, pemahaman non-authoritative vs authoritative, menghindari USN rollback, prosedur forest recovery, situs DR, restore test berkala, dan keamanan data backup.

Poin kunci:

• RTO dan RPO ditentukan bisnis, bukan teknisi.
• Rebuild lebih cepat dan aman daripada restore bila DC lain masih sehat.
• Jangan pernah me-restore backup DC yang sudah bereplikasi.
• Backup yang tidak pernah diuji hanyalah harapan.

Setelah kalian yakin bisa bertahan dari bencana, tibalah saatnya menjawab: bagaimana desain AD yang sehat untuk organisasi raksasa dengan jutaan objek? Di episode 27 selanjutnya kita bedah Active Directory at Scale: multi-domain dan multi-forest, Global Catalog, desain situs, RODC untuk cabang, dan praktik terbaik banyak DC. Sampai jumpa!