Belajar Active Directory - Active Directory Backup & Recovery

#Pendahuluan

Di episode 16 kita melihat bagaimana replikasi menjaga semua DC tetap konsisten — dan kita juga berkenalan dengan tombstone, penanda yang membuat objek yang dihapus "hidup" selama masa tertentu sebelum benar-benar lenyap. Sekarang kita menghadapi pertanyaan yang lebih serius: apa yang terjadi ketika seluruh DC gagal, ketika sebuah objek penting terhapus, atau ketika struktur direktori rusak? Jawabannya ada di backup dan recovery.

Bayangkan replikasi seperti tim pemadam kebakaran: ia mencegah api menyebar. Tapi jika api sudah padam dan gedung hancur, kalian butuh asuransi — itulah backup. Replikasi melindungi dari kegagalan satu DC, tetapi tidak melindungi dari kesalahan manusia: jika seorang admin menghapus OU yang salah, replikasi dengan patuh akan menyebarkan kesalahan itu ke seluruh DC. Satu-satunya penyelamat dalam kasus seperti ini adalah salinan data yang dibuat sebelum kesalahan terjadi.

#Mengapa DC Harus Di-Backup

Sebuah DC menyimpan data yang tidak bisa direkonstruksi begitu saja: SYSVOL, database NTDS.dit yang berisi seluruh objek dan izin, serta state DNS. Dua alasan utama backup DC wajib:

Kesalahan manusia adalah penyebab paling umum. Penghapusan objek, perubahan atribut massal yang salah, atau skrip yang "melenceng" tidak bisa diperbaiki oleh replikasi — karena replikasi justru menyebarkan kesalahan tersebut.
Proteksi dari kegagalan tunggal. Jika seluruh DC di domain hilang (bencana, ransomware, VM yang korup), domain tidak bisa dilayani — dan recovery dari nol memakan waktu berhari-hari.

Prinsip yang berlaku: replikasi menjaga banyak salinan data yang sama; backup menjaga salinan data pada titik waktu yang berbeda. Keduanya saling melengkapi, tidak saling menggantikan.

#System State Backup: Inti dari Backup DC

Backup DC yang benar adalah System State backup — karena ia mencakup komponen kritis yang tidak tercakup backup file biasa: registry, database AD (NTDS.dit), SYSVOL, dan file boot. Mencadangkan "hanya file dokumen" di DC seperti mengasuransikan perabotan kantor sementara kunci serta arsipnya tidak diasuransikan.

Alat bawaan Microsoft yang paling praktis adalah Windows Server Backup (WSB). Pasang fiturnya terlebih dahulu dengan Install-WindowsFeature:

Memasang Windows Server Backup

Install-WindowsFeature -Name Windows-Server-Backup

Lalu jalankan backup System State secara terjadwal. Untuk backup langsung dari baris perintah:

Backup System State ke drive E:

wbadmin start systemstatebackup -backupTarget:E: -quiet

Penjadwalan rutin (idealnya harian, minimal mingguan) lewat WSB, Task Scheduler, atau skrip wbadmin adalah kebiasaan minimum yang layak disebut "mempunyai backup".

#ntdsutil: Alat Bedah Database AD

Untuk kebutuhan yang lebih dalam, ada ntdsutil — alat baris perintah yang bisa memelihara database AD: memeriksa integritas, melakukan defragmentasi offline, membuat snapshot, dan mengetes kemampuan restore. Saat DC rusak dan perlu restore, ntdsutil menjadi salah satu pintu utama.

Contoh alur mengetes snapshot (metadata) database yang sedang tidak aktif:

Mengetes snapshot database (sebelum restore)

ntdsutil
snapshot
list all
quit
quit

Ini hanya sebagian kecil dari kemampuan ntdsutil — yang penting kalian tahu bahwa ia ada dan berfungsi sebagai "alat bedah" ketika WSB tidak cukup.

#DSRM: Mode Darurat untuk Restore

Restore database AD tidak bisa dilakukan saat DC berjalan normal — database sedang dipakai. Karena itu Windows menyediakan DSRM (Directory Services Restore Mode), mode boot khusus yang memuat DC tanpa menjalankan layanan AD secara penuh, sehingga database bisa diganti.

Saat boot, tekan tombol yang sama seperti Safe Mode (F8) dan pilih Directory Services Restore Mode. DC akan meminta password DSRM — password yang kalian set saat mem-promote DC di episode 5, dan yang seharusnya sudah dirotasi secara berkala. Dalam DSRM, AD offline; di sinilah restore database dilakukan.

Urutan umum restore non-authoritative:

Boot DC ke DSRM.

Restore System State dari backup menggunakan wbadmin:

Restore System State dari backup terbaru

wbadmin get versions -backupTarget:E:
wbadmin start sysrecovery -version:08/03/2026-04:00 -backupTarget:E: -quiet

Restart DC normal. Setelah online, DC menyalin perubahan terbaru dari DC lain lewat replikasi.

#Restore Non-Authoritative vs Authoritative

Di sinilah perbedaan yang paling menentukan. Ketika kalian me-restore System State, database yang dipulihkan adalah database lama — yang mungkin sudah ketinggalan dari DC lain. Bagaimana AD memperlakukan data yang dipulihkan?

Non-authoritative restore — data yang dipulihkan dianggap basi (usang) dibanding DC lain, sehingga DC mengejar ketinggalan lewat replikasi. Ini pilihan tepat saat hanya satu DC yang rusak: cukup pulihkan DC itu, lalu biarkan replikasi menyamakan dengan DC lain yang sehat.
Authoritative restore — data yang dipulihkan dianggap sumber kebenaran (authoritative) dan akan menimpa DC lain lewat replikasi. Ini dipakai saat data yang dipulihkan justru harus menang — misalnya objek yang salah terhapus dan sudah menyebar. Tanpa perlakuan authoritative, tombstone (episode 16) akan "menyerap" objek yang kalian pulihkan.

Cara menandai objek sebagai authoritative adalah dengan ntdsutil, dalam mode restore:

Menandai objek agar restore bersifat authoritative

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

Warning

Authoritative restore adalah senjata yang berbahaya. Jika salah menandai — misalnya memulihkan subtree yang lebih besar dari yang diperlukan — kalian bisa memundurkan data yang sehat di seluruh domain. Sebelum mengeksekusi, tulis dengan jelas objek apa yang akan ditandai, dan pastikan tidak ada DC lain yang menulis perubahan pada subtree itu pada waktu yang bersamaan.

#Active Directory Recycle Bin: Cara Modern Mengembalikan Objek

Restore dari backup itu mahal dan berisiko. Sejak Windows Server 2008 R2, AD menawarkan jalan yang jauh lebih sederhana: Active Directory Recycle Bin — analogi dengan Recycle Bin di desktop kalian, tapi untuk objek direktori.

Cara kerjanya terkait erat dengan tombstone dari episode 16. Objek yang dihapus tidak langsung menjadi tombstone — ia memasuki fase deleted dan bisa dikembalikan dalam keadaan utuh (semua atribut dan keanggotaan group-nya), lalu berakhir sebagai recycled setelah masa tertentu. Selama objek masih deleted (belum recycled), ia bisa dipulihkan tanpa backup sama sekali.

Persyaratan penting: forest functional level Windows Server 2008 R2 atau lebih tinggi, dan mengaktifkannya tidak bisa dibatalkan:

Mengaktifkan Recycle Bin (tidak bisa dibatalkan)

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
    -Scope ForestOrConfigurationSet -Target "corp.local"

Setelah aktif, pemulihan objek dilakukan dengan dua cmdlet sederhana — Get-ADObject untuk mencari dan Restore-ADObject untuk mengembalikan:

Mencari objek yang terhapus

Get-ADObject -Filter {Deleted -eq $true -and Name -like "*Joko*"} `
    -IncludeDeletedObjects -Properties whenChanged, name, lastKnownParent

Mengembalikan objek yang terhapus

Restore-ADObject -Identity "e8f9a5c2-..."

Tip

Kebiasaan terbaik: aktifkan Recycle Bin segera setelah forest dinaikkan ke level fungsional yang mendukungnya, sebelum kebutuhan darurat muncul. Sebagian besar "objek terhapus" di dunia nyata tidak perlu backup — cukup Recycle Bin — selama fitur ini sudah menyala.

#Forest Recovery: Skenario Terburuk

Ketika seluruh DC di forest hilang atau korup (bencana besar, ransomware yang menghapus semuanya), replikasi tidak ada gunanya — tidak ada DC lain untuk disamakan. Inilah forest recovery: prosedur membangun kembali forest dari satu DC yang dipulihkan dari backup, lalu mem-promote DC lain satu per satu.

Langkah utamanya adalah kebalikan dari instalasi normal:

Pulihkan satu DC dari backup System State, jadikan ia sebagai "benih" forest.
Bersihkan metadata DC-DC yang sudah mati agar tidak mengganggu topologi.
Promote DC baru untuk menggantikan yang hilang, biarkan replikasi membangun kembali.
Pulihkan FSMO roles (episode 3) yang mungkin ikut hilang.
Verifikasi — dcdiag, repadmin, dan autentikasi user.

Kunci sukses forest recovery ada dua hal yang sering dilupakan: prosedur terdokumentasi dan latihan rutin. Forest yang tidak pernah diuji recovery-nya seperti tali parasut yang belum pernah dibuka — kalian berharap ia bekerja, tapi tidak yakin.

Important

Recovery Time Objective (RTO) dan Recovery Point Objective (RPO) bukan jargon akademik — mereka adalah angka yang harus kalian tetapkan dan ukur. RTO: berapa lama maksimal domain boleh mati sebelum bisnis terganggu? RPO: seberapa jauh ke belakang data boleh hilang? Backup harian dengan RPO satu hari dan RTO beberapa jam adalah titik awal yang masuk akal untuk sebagian besar organisasi.

#Penutup

Pada episode ini kita telah membedah backup dan recovery Active Directory: System State backup dengan Windows Server Backup dan wbadmin, ntdsutil sebagai alat bedah database, DSRM sebagai mode darurat untuk restore, perbedaan krusial restore non-authoritative (mengejar DC lain) dan authoritative (menimpa DC lain), Active Directory Recycle Bin sebagai cara modern mengembalikan objek terhapus, serta forest recovery untuk skenario terburuk.

Inti dari episode ini: backup AD adalah asuransi yang harus dibayar sebelum bencana, bukan setelahnya. Replikasi melindungi dari kegagalan DC; backup melindungi dari kesalahan manusia; dan kombinasi keduanya — plus prosedur yang diuji berkala — menentukan seberapa cepat organisasi bangkit ketika hal terburuk terjadi.

Di episode 18 selanjutnya, kita membuka babak baru: Active Directory Certificate Services (AD CS) — fondasi PKI yang memungkinkan sertifikat, smart card, dan enkripsi di lingkungan enterprise. Pastikan tetap semangat!