Memulihkan dan memperbaiki pengontrol domain lokal yang rusak.

Ketika pengendali domain mengalami kerusakan atau dipulihkan secara tidak benar, dampaknya sangat besar: Upaya login gagal, GPO berhenti diterapkan, dan replikasi terhenti tanpa petunjuk yang jelas.Kabar baiknya adalah terdapat prosedur yang jelas untuk memulihkan DC fisik atau virtual, asalkan metode pencadangan dan pemulihan yang diterima dipatuhi.

Dalam lingkungan Windows Server modern, memulihkan pengendali domain memerlukan pemahaman yang baik tentang konsep-konsep seperti: status sistem, pemulihan otoritatif/non-otoritatif, SYSVOL, DFSR/FRS dan rollback USNJika masalah-masalah ini ditangani secara tergesa-gesa atau dengan alat pencitraan yang tidak kompatibel, hasilnya bisa berupa hutan penuh inkonsistensi tersembunyi yang sangat sulit didiagnosis.

Mengapa sangat penting untuk melindungi dan memulihkan pengendali domain dengan benar

Active Directory adalah inti dari otentikasi dan otorisasi dalam domain Windows.Sistem ini menyimpan pengguna, komputer, grup, hubungan kepercayaan, kebijakan grup, sertifikat, dan elemen penting lainnya. Informasi ini sebagian besar berada di dalam basis data. Ntds.dit, file log dan folder terkait SYSVOL, di antara komponen-komponen lain yang membentuk apa yang disebut "kondisi sistem".

Status sistem mencakup, antara lain, Berkas log dan data Active Directory, Registri Windows, volume sistem, SYSVOL, basis data sertifikat (jika CA ada), metabase IIS, berkas boot, dan komponen sistem operasi yang dilindungi.Oleh karena itu, strategi kesinambungan bisnis yang serius harus mencakup pencadangan rutin terhadap status sistem setiap pusat data.

Ketika terjadi kerusakan sebenarnya pada basis data Active Directory, kegagalan replikasi yang serius, atau masalah dengan izin pada SYSVOLPengontrol domain mungkin berhenti memproses kueri, gagal memulai layanan Active Directory, atau memicu kesalahan berantai di seluruh forest. Dalam kasus ini, Pemulihan yang cepat dan tepat akan membedakan antara insiden serius dan bencana yang berkepanjangan..

Sebelum mencoba melakukan pemulihan, sangat penting untuk membedakan antara masalah basis data yang sebenarnya dan kegagalan yang lebih umum. Seringkali, Penyebabnya terletak pada DNS, perubahan jaringan, firewall, atau rute yang dimodifikasi dengan alat seperti... perintah netshOleh karena itu, disarankan untuk mengesampingkan faktor-faktor ini terlebih dahulu sebelum menyentuh basis data AD.

Alat diagnostik dan kontrol replikasi dasar

Jika muncul gejala korupsi atau kegagalan replikasi, langkah pertama yang bijaksana adalah memeriksa kondisi lingkungan menggunakan alat bawaan. DCDiag, Repadmin, ReplMon (pada versi lama) dan Event Viewer Mereka adalah sekutu terbaik Anda sebelum mempertimbangkan restorasi yang agresif.

dengan DCDiag Pemeriksaan umum dilakukan pada semua pengendali domain, untuk mengidentifikasi masalah pada replikasi, DNS, layanan AD DS, dan lain-lain. Repadmin Ini memungkinkan Anda untuk melihat status replikasi, mitra replikasi, tanda air USN, dan mendeteksi objek persisten. Pada versi Windows yang lebih lama, ReplMon Sistem ini menawarkan tampilan grafis dari kesalahan replikasi di dalam domain tersebut.

Selain alat-alat tersebut, penting untuk meninjau Event Viewer untuk “Directory Services” dan “DFS Replication”. Kejadian seperti 467 dan 1018 menunjukkan adanya kerusakan nyata pada basis data.Sedangkan peristiwa 1113/1115/1114/1116 berkaitan dengan mengaktifkan atau menonaktifkan replikasi input/output.

Jika seorang tersangka pelaku korupsi perlu diisolasi sementara untuk mencegahnya menyebarkan korupsi, kita bisa Nonaktifkan replikasi masuk dan keluar dengan Repadmin.:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Dan untuk mengembalikan replikasi ke kondisi normal, cukup hapus opsi-opsi tersebut:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Mendukung pencadangan status sistem pada pengendali domain.

Untuk dapat memulihkan DC dengan jaminan, sangat penting untuk memiliki Pencadangan status sistem dilakukan menggunakan alat yang kompatibel dengan Active Directory.Alat-alat ini menggunakan API pencadangan dan pemulihan Microsoft serta Layanan Salinan Bayangan Volume (Volume Shadow Copy Service/VSS) dengan cara yang didukung.

Di antara solusi yang paling umum adalah Windows Server Backup, solusi pihak ketiga yang terintegrasi dengan VSS (seperti NAKIVO, Backup Exec, dan lainnya)atau utilitas yang lebih tua seperti cadangan tidak di Windows 2000/2003. Dalam semua kasus, mereka harus menghormati API AD untuk memastikan konsistensi basis data dan replikanya setelah pemulihan.

Windows Server 2012 dan versi yang lebih baru memiliki fitur tambahan yang penting: ID Generasi Hyper-V (GenID)Pengidentifikasi ini memungkinkan pengendali domain virtual untuk mendeteksi bahwa disk-nya telah dikembalikan ke titik waktu sebelumnya. Ketika ini terjadi, AD DS menghasilkan InvocationID baru dan memperlakukan situasi tersebut seolah-olah telah dipulihkan dari cadangan yang berhasil.memberitahukan kepada mitra replikasinya, sehingga memungkinkan penulisan ulang yang aman tanpa menimbulkan pengembalian USN.

Sangat penting untuk menghormati seumur hidup batu nisanIni menunjukkan berapa lama cadangan status sistem dapat digunakan tanpa risiko munculnya kembali objek yang telah dihapus sejak lama. Biasanya 180 hari pada versi modern, dan disarankan untuk melakukan pencadangan setidaknya setiap 90 hari untuk menjaga margin keamanan yang memadai.

Metode tidak sah yang menyebabkan pembalikan USN.

Salah satu penyebab paling berbahaya dari inkonsistensi diam-diam di Active Directory adalah... Pengurangan anggaran USNSituasi ini terjadi ketika isi basis data AD dikembalikan menggunakan teknik yang tidak didukung, tanpa InvocationID dipulihkan atau mitra replikasi diberitahu.

Skenario tipikalnya adalah melakukan booting DC dari sebuah gambar disk atau cuplikan mesin virtual yang diambil di masa lalutanpa menggunakan pemulihan sistem yang kompatibel. Atau salin file Ntds.dit secara langsung, gunakan program pencitraan seperti Ghost, boot dari mirror disk yang rusak, atau terapkan kembali snapshot penyimpanan pada tingkat array.

Dalam kasus ini, pengendali domain terus menggunakan InvocationID yang sama seperti sebelumnya, tetapi Penghitung USN lokal berjalan mundurDC lainnya ingat menerima perubahan hingga USN tinggi, jadi ketika DC yang dikembalikan mencoba mengirim kembali USN yang sudah dikenali, Pasangan mereka percaya bahwa mereka selalu mengikuti perkembangan zaman dan berhenti menerima perubahan nyata..

Hasilnya adalah modifikasi tertentu (misalnya, pembuatan pengguna, perubahan kata sandi, pendaftaran perangkat, perubahan keanggotaan grup, catatan DNS baruKesalahan ini tidak pernah direplikasi dari DC yang dipulihkan ke seluruh jaringan, tetapi alat pemantauan mungkin tidak menunjukkan kesalahan yang jelas. Ini adalah kegagalan diam-diam yang sangat berbahaya.

Untuk mendeteksi situasi ini, driver Windows Server 2003 SP1 dan versi yang lebih baru mencatat (log). Acara Layanan Direktori 2095 Ketika DC jarak jauh terdeteksi mengirimkan USN yang sudah diakui tanpa perubahan pada InvocationID, sistem Ini mengkarantina DC yang terpengaruh, menghentikan sementara Netlogon, dan mencegah terjadinya perubahan lebih lanjut. yang tidak dapat direplikasi dengan benar.

Sebagai bukti forensik tambahan, hal ini dapat untuk diperiksa di dalam Registri kunci HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters dan nilai Dsa Tidak Dapat DitulisJika nilai ini diatur (misalnya, 0x4), ini menunjukkan bahwa DC telah dimasukkan ke dalam keadaan tidak dapat menulis karena deteksi pembalikan USN. Mengubah nilai ini secara manual untuk "memperbaikinya" sama sekali tidak didukung. dan menyebabkan basis data berada dalam keadaan tidak konsisten secara permanen.

Strategi umum jika terjadi kerusakan atau pengembalian kendali domain.

Prosedur yang harus diikuti saat menangani DC yang rusak atau dipulihkan secara tidak benar bergantung pada beberapa faktor: Jumlah pengendali domain dalam domain/forest, ketersediaan salinan status sistem yang valid, keberadaan peran lain (FSMO, CA, katalog global), dan cakupan temporal masalah..

Jika terdapat DC sehat lainnya di domain tersebut dan Tidak ada data penting unik pada pengendali domain yang rusak.Opsi tercepat dan terbersih biasanya adalah menghapus pengendali domain tersebut dan membangunnya kembali. Namun, jika itu adalah satu-satunya pengendali domain, atau jika pengendali domain tersebut menampung peran dan data sensitif, pemulihan yang lebih hati-hati (otoritatif atau non-otoritatif) akan diperlukan.

Secara umum, pilihannya adalah:

• Turunkan pangkat DC yang korup secara paksa dan hapus dari domain., diikuti dengan pembersihan metadata dan, jika berlaku, promosi baru.
• Pulihkan dari cadangan status sistem yang valid., baik dalam mode otoritatif maupun non-otoritatif.
• Bangun ulang DC dari DC lain menggunakan IFM (Install From Media)., ketika tidak ada salinan terbaru tetapi ada DC lain yang benar.
• Menggunakan snapshot VHD dari DC virtual., menerapkan langkah-langkah tambahan untuk menandai basis data sebagai telah dipulihkan dari cadangan (Basis data dipulihkan dari cadangan = 1) dan memastikan bahwa InvocationID baru dihasilkan.

Jika rollback USN jelas dicurigai (misalnya, setelah memulihkan VM dari snapshot tanpa mengikuti praktik terbaik) dan event 2095 muncul, tindakan yang paling masuk akal biasanya adalah... Nonaktifkan DC tersebut dari layanan dan jangan mencoba untuk "memperbaikinya" di tempat., kecuali jika memungkinkan untuk mengembalikan ke cadangan status sistem yang didukung yang diambil sebelum rollback.

Penurunan pangkat paksa dan pembersihan metadata

Ketika pengendali domain mengalami kerusakan sedemikian rupa sehingga tidak dapat diturunkan statusnya secara normal, atau telah dipulihkan secara tidak benar dan Anda ingin mencegahnya menyebarkan masalah, Anda dapat menggunakan cara berikut: penurunan pangkat paksa.

Pada versi yang lebih lama, operasi ini dilakukan dengan dcpromo /forceremoval, apa Hapus peran AD DS tanpa mencoba mereplikasi perubahan ke seluruh forest.Dalam lingkungan modern, wizard-nya telah berubah, tetapi konsepnya tetap sama: untuk menghapus DC yang bermasalah dari topologi AD tanpa membuatnya berpartisipasi dalam replikasi lebih lanjut.

Setelah dilakukan penurunan versi secara paksa, wajib untuk menjalankan perintah dari DC yang sehat. pembersihan metadata menggunakan alat tersebut NtdsutilProses ini menghapus semua referensi ke DC yang dihapus (objek Pengaturan NTDS, referensi DNS, dll.) dari basis data AD, sehingga tidak ada sisa-sisa "hantu" yang tertinggal untuk membingungkan replikasi..

Jika pengontrol yang mengalami degradasi memiliki peran FSMO (PDC Emulator, RID Master, Schema Master, dll.), maka perlu dilakukan hal berikut: mentransfer atau merebut peran-peran tersebut ke DC lain sebelum atau setelah penurunan status, tergantung situasinya. Kemudian, sistem operasi dapat diinstal ulang pada server tersebut dan dapat dipromosikan kembali menjadi DC yang bersih.

Pemulihan non-otoritatif vs. otoritatif di Active Directory

Jika salinan status sistem yang valid tersedia, pemulihan AD dapat dilakukan dengan dua cara: tidak berwibawa dan berwibawaMemahami perbedaannya adalah kunci agar tidak ketinggalan perubahan terbaru atau mereplikasi data yang sudah usang.

Dalam satu restorasi non-otoritatifDC dikembalikan ke titik sebelumnya, tetapi begitu dimulai, Pengontrol domain lainnya dianggap sebagai referensi.Dengan kata lain, setelah startup, DC yang dipulihkan meminta replikasi masuk dan memperbarui basis datanya dengan perubahan yang hilang dari DC lain. Opsi ini ideal ketika Ada pengendali lain yang sehat, dan kami ingin pengendali yang telah dipulihkan ini dapat mengejar ketertinggalan dengan mereka..

Dalam satu pemulihan otoriterNamun, secara eksplisit dinyatakan bahwa Data yang dipulihkan adalah data yang seharusnya berlaku. dibandingkan dengan DC lainnya. Ini berarti bahwa, setelah pemulihan, objek yang dipulihkan akan memiliki nomor versi yang lebih tinggi untuk memaksa objek tersebut direplikasi dari DC tersebut ke seluruh domain. Ini adalah pilihan yang tepat ketika Kami secara tidak sengaja menghapus objek atau OU, atau kami ingin mengembalikan isi SYSVOL dan GPO ke keadaan sebelumnya dan mereplikasikannya..

Detail pentingnya adalah bahwa pemulihan otoritatif tidak harus dilakukan untuk seluruh basis data. Dengan utilitas ini Ntdsutil Objek individual, subpohon (misalnya, OU), atau seluruh domain dapat ditandai sebagai otoritatif. Hal ini menawarkan fleksibilitas yang cukup besar untuk, misalnya, hanya mengambil pengguna, grup, OU, atau subpohon dc=mycompany,dc=local.

Prosedur umum untuk memulihkan status sistem di DC.

Skema dasar untuk memulihkan status sistem DC (baik fisik maupun virtual) dengan alat yang kompatibel selalu serupa: Masuk ke Mode Pemulihan Layanan Direktori (DSRM), pulihkan menggunakan alat pencadangan, dan mulai ulang..

Singkatnya, langkah-langkah umum untuk pengendali domain virtual adalah:

1. Mulai mesin virtual di Windows Boot Manager. (biasanya dengan menekan F5/F8 selama proses startup). Jika VM dikelola oleh hypervisor, mungkin perlu untuk menghentikan sementara mesin agar dapat merekam penekanan tombol.
2. Di opsi boot lanjutan, pilih Mode pemulihan layanan direktori (Mode Pemulihan Layanan Direktori). Mode ini memulai server tanpa memasang basis data Active Directory secara fungsional.
3. Masuk menggunakan akun administrator DSRM ditentukan selama promosi awal DC (bukan dengan akun administrator domain standar).
4. Jalankan alat pencadangan Gunakan (Windows Server Backup, NAKIVO, atau yang kompatibel lainnya) dan pilih untuk memulihkan status sistem ke titik pencadangan yang diinginkan.
5. Selesaikan panduan pemulihan dan Mulai ulang DC dalam mode normal.Dalam pemulihan non-otoritatif, server akan memulai replikasi untuk mengejar ketertinggalan dengan DC lainnya.

Ketika kita berbicara tentang produk pencadangan pihak ketiga, seperti Pencadangan & Replikasi NAKIVOMode "sadar aplikasi"-nya mampu mengenali bahwa mesin yang sedang dipulihkan adalah DC dan secara otomatis menyesuaikan proses untuk menjaga konsistensi AD.Dalam sebagian besar skenario dengan beberapa pengontrol, pemulihan penuh dalam mode non-otoritatif sudah cukup.

Restorasi resmi dengan Ntdsutil

Jika Anda ingin perubahan pada pengendali domain yang dipulihkan diutamakan daripada yang lain, Anda perlu menambahkan langkah tambahan setelah pemulihan non-otoritatif: Gunakan Ntdsutil untuk menandai objek sebagai otoritatif..

Alur yang disederhanakan adalah:

1. Pulihkan status sistem dengan cara standar dan biarkan server tetap dalam keadaan tersebut. Mode DSRM (Jangan memulai ulang dalam mode normal dulu).
2. Buka prompt perintah dengan hak akses administrator dan lari ntdsutil.
3. Aktifkan instance AD ​​dengan aktifkan instance ntds.
4. Memasuki konteks restorasi otoritatif dengan pemulihan yang berwibawa.
5. Gunakan perintah seperti restore object <DN_objeto> o restore subtree <DN_subarbol>, di mana DN adalah nama pembeda dari objek atau subpohon yang akan dipulihkan secara otoritatif.
6. Konfirmasikan transaksi dan, setelah selesai, Mulai ulang DC dalam mode normal. sehingga objek yang ditandai direplikasi dengan prioritas lebih tinggi daripada objek lain dalam domain tersebut.

Jenis restorasi ini membutuhkan kehati-hatian yang tinggi. Jika seluruh domain dipulihkan secara otoritatif dan cadangan tersebut sudah lamaTerdapat risiko kehilangan perubahan sah yang dilakukan setelah pencadangan (misalnya, pembuatan pengguna, perubahan kata sandi, atau modifikasi grup). Oleh karena itu, praktik umum yang dilakukan adalah membatasi pemulihan otoritatif hanya pada objek atau struktur data yang benar-benar diperlukan.

Pemulihan dan perbaikan SYSVOL (FRS vs DFSR)

SYSVOL adalah komponen kunci dari pengendali domain: Di dalamnya tersimpan skrip startup, kebijakan grup, templat keamanan, dan sumber daya bersama penting lainnya.Kegagalan pada izin akses, kerusakan file, atau masalah replikasi dapat membuat GPO tidak dapat digunakan atau menyebabkan perilaku yang tidak menentu pada klien.

Tergantung pada versi Windows Server dan status migrasi, SYSVOL dapat direplikasi oleh FRS (Layanan Replikasi File) mengapa DFSR (Replikasi Sistem Berkas Terdistribusi)Prosedur untuk pemulihan SYSVOL yang resmi berbeda-beda tergantung pada mana di antara keduanya yang sedang digunakan.

Untuk menentukan hal ini, Anda dapat memeriksa kunci tersebut di Registry. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateJika subkunci ini ada dan nilainya adalah 3 (DIHAPUS), maka DFSR sedang digunakan. Jika tidak ada atau nilainya berbeda, kita berurusan dengan lingkungan yang masih menggunakan FRS.

Dalam lingkungan dengan FRS, pemulihan SYSVOL yang otoritatif biasanya melibatkan penyesuaian nilai. Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process ke nilai tertentu (misalnya, 212 desimal / 0xD4 heksadesimal) untuk menunjukkan bahwa DC ini adalah sumber yang berwenang.

Jika SYSVOL direplikasi oleh DFSR, prosesnya agak lebih rumit: ini melibatkan penggunaan ADSIEdit untuk memodifikasi objek langganan SYSVOL (atribut) msDFSR-Enabled y Opsi msDFSR) pada DC otoritatif dan pada DC lainnya, paksa replikasi AD, jalankan dfsrdiag pollad dan konfirmasikan di log peristiwa munculnya Peristiwa 4114, 4602, 4614 dan 4604 yang menyatakan bahwa SYSVOL telah diinisialisasi dan direplikasi dengan benar.

Memulihkan pengendali domain virtual dari VHD

Dalam lingkungan virtualisasi, hal ini sangat umum terjadi. File VHD/VHDX pengendali domainJika Anda tidak memiliki cadangan status sistem tetapi memiliki VHD "lama" yang berfungsi, Anda dapat memasang DC baru dari disk tersebut, meskipun Anda harus melakukannya dengan sangat hati-hati untuk menghindari terjadinya rollback USN.

Rekomendasinya adalah Jangan jalankan VM tersebut secara langsung dalam mode normal.Sebaliknya, Anda harus melakukan booting dari VHD sebelumnya di DSRMBuka Editor Registri dan navigasikan ke HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDi sana, sebaiknya periksa nilainya. Jumlah restorasi DSA sebelumnya (jika ada) dan, yang terpenting, buat nilai DWORD (32-bit) baru yang disebut Basis data dipulihkan dari cadangan. dengan nilai 1

Dengan memilih nilai ini, Active Directory diberi tahu bahwa basis data telah dipulihkan dari cadangan, yang memaksa menghasilkan InvocationID baru saat booting dalam mode normalDengan cara ini, DC lain menginterpretasikannya sebagai instance baru dan menyesuaikan watermark replikasi mereka dengan benar, sehingga mencegah rollback USN.

Setelah memulai ulang DC dalam mode normal, disarankan untuk memeriksa Event Viewer, khususnya log dari Layanan direktori, mencari acara 1109Peristiwa ini mengkonfirmasi bahwa atribut InvocationID server telah berubah dan menampilkan nilai lama dan baru, serta USN tertinggi pada saat pencadangan. Selain itu, nilai dari Jumlah restorasi DSA sebelumnya Seharusnya jumlahnya ditambah satu.

Jika kejadian-kejadian ini tidak muncul, atau jumlahnya tidak bertambah, Anda harus memeriksa versi sistem operasi dan Service Pack, karena Perilaku pemulihan tertentu bergantung pada area spesifik.Bagaimanapun juga, selalu disarankan untuk mengerjakan salinan VHD asli, menyimpan versi yang utuh jika proses perlu diulang.

Skenario praktis dan rekomendasi tambahan

Dalam praktiknya, masalah korupsi atau restorasi yang tidak tepat sering muncul dalam skenario sehari-hari: Modifikasi manual izin di SYSVOL, upaya untuk memperbarui templat ADMX/ADML, perubahan GPO yang tidak direplikasi.dll. Relatif mudah untuk menyebabkan inkonsistensi jika folder bersama dimodifikasi secara manual, seperti SYSVOL\Policies tanpa menghormati replikasi.

Jika DC utama mengalami kerusakan replikasi (baik data AD maupun SYSVOL) dan muncul pesan pemantauan dengan tipe “Basis data dipulihkan menggunakan prosedur yang tidak didukung. Kemungkinan penyebab: Rollback USN.”, hal yang bijaksana untuk dilakukan adalah:

• Periksa dengan dcdiag y admin ulang sejauh mana kesalahan tersebut dan apakah ada "objek persisten".
• Periksa kejadian 2095 dan nilainya Dsa Tidak Dapat Ditulis di Registri.
• Nilai apakah hal itu memungkinkan hapus DC itu dan bangun ulang (Jika terdapat tiga atau lebih DC sehat lainnya, ini biasanya merupakan pilihan terbaik).
• Jika itu satu-satunya DC atau kritikus, angkat tangan. pemulihan keadaan sistem dari cadangan yang kompatibel, idealnya yang terbaru dan dalam periode tombstone.

Pada domain dengan beberapa pengendali (DC), sangat disarankan agar DC tersebut sebisa mungkin "murni": tanpa peran tambahan atau data pengguna lokalDengan cara ini, jika salah satu gagal atau rusak, yang baru dapat diformat dan dipromosikan berdasarkan DC lain atau melalui IFM, sehingga sangat mengurangi kompleksitas pemulihan.

Selain itu, perlu diingat juga keterbatasan seperti itu. Salinan status sistem hanya berlaku selama periode tombstone. (60, 90, 180 hari tergantung konfigurasi) untuk menghindari pengaktifan kembali objek yang dihapus, dan kunci mesin NTLM berubah setiap 7 hari. Pada pemulihan yang sangat lama, mungkin perlu untuk Atur ulang akun tim. masalah yang berasal dari “Active Directory Users and Computers” atau bahkan menghapus dan menggabungkannya kembali ke domain.

Dengan adanya prosedur untuk secara rutin mencadangkan status sistem, Dokumentasikan dengan jelas peran FSMO, katalog global, dan topologi replikasi.Dan menguji langkah-langkah pemulihan di lingkungan laboratorium adalah investasi waktu yang menghemat banyak masalah ketika suatu saat pengendali domain rusak atau seseorang menerapkan snapshot tanpa berpikir panjang.