Bu makalemde sizlere Windows Server 2012 ortamında authoritative restore işlemlerinden bahsedeceğim. Aslında yedekleme ve geri yükleme konularında çok detaylı bir makale yazmıştım, ancak bu kapsamda makale çok detaylı ve uzun olduğu için, yine büyük ve kompleks yapılara hitap ettiğinden daha çok istek alan ve sadece amacına uygun bir ek makale ile bu bilgileri paylaşmak istedim. Bu nedenle bu makalemde sadece mevcut bir Server 2012 yedeğinden bir objenin nasıl kurtarılacağından bahsedeceğim.
Öncelikle bildiğiniz gibi eğer ortamda birden çok dc yok ise, yani tek bir dc var ise authoritative restore yapmanıza gerek yoktur, çünkü authoritative restore mantığı şu şekilde çalışır.
Birden çok dc olan yerde bir obje düşünün, hakan kullanıcısı için güncel USN numarası 101 olsun, bu bilgi her iki DC de de bulunmaktadır. Bu DC lerden ( DC1 ve DC2 ) DC1 üzerinde hakan kullanıcısı silindi ve bu da bir değişiklik olduğu için USN artı ve 102 oldu. Bu güncelleme DC2 ye ulaşır ulaşmaz DC2 hakan kullanıcısı için USN’ i günceller ve bu objeyi siler. Siz eğer Recycle Bin özelliğine sahip değilseniz veya açık değil ise bu özellik bu durumda bu objeyi kurtarmak için mutlaka system state yedeğini dönmeniz gerekir.
Bu senaryo gereği, içerisinde hakan kullanıcısının bulunduğu yedeği geri dönmek istersiniz, bunun için DC1’ i DSRM üzerinde açar ve yedekten dönersiniz, yedekten döndüğünüzde aslında DC1 için AD veri tabanını eski bir tarihe çekmiş olursunuz. Bu tarihte hakan kullanıcısı vardır ve örneğin USN numarası 97 olsun. DC1 ilk açılışında diğer DC2 ile replike olur, DC2 bakar DC1 den ona hakan isminde kullanıcı bilgisi aktarılmak isteniyor, ancak USN numarası DC2 de olan 102 den küçük, DC2 bunu fark eder ve DC1 e bende daha güncel bir bilgi var ve bu bilgi dahilin de hakan kullanıcısı tekrar DC1 veri tabanından silinir.
İşte bu nedenle system state yedeğinden geri dönerken authoritative restore yapılır. Burada yapılan aslında ek bir komut ile yedekten geri döndürmek istediğiniz objenin USN numarasını 1 milyon arttırırsınız.
Şimdi sürece hızlıca başlayalım.
Öncelikle sistemimizi tanıyalım.
Tek bir forest içerisinde bir domain ve iki domain controller olan bir yapımız vardır. Malum tek bir DC olan ortamlarda Authoritative restore yapmak için özel bir aksiyon almaya gerek yoktur. Mevcut sistem state yedeğini geri dönmeniz yeterlidir. Ancak söz konusu birden çok DC ise yukarıda anlattığım nedenle Authoritative restore yapmak zorundayız.
Yapımızdaki kullanıcı ve gruplar ise aşağıdaki gibidir.
Peki yine her iki DC için güncel USN numaraları neymiş onu öğrenelim
repadmin /showutdvec cozumparkdc1 “dc=cozumparkbp,dc=com” /nocache /latency
Burada gördüğünüz gibi DC isimleri yok, gördüğünüz numaralar Server Object GUID (DSA GUID)’ dir. Bunları DC isimlerine aşağıdaki şekilde çevirebiliriz.
Repadmin /showrepl
Burada aslında iki GUID görüyoruz, birisi merak ettiğimiz Server GUID, diğeri ise Invocation ID’ dir. Yani daha sade bir dille, birisi sunucu TC kimlik numarası iken diğer sunucu üzerindeki veri tabanı TC kimlik numarasıdır.
Hemen diğer DC içinde aynı komutu çalıştırıyorum
Bunun sonucu olarak sonu 257 olan sunucu = DC1, sonu 536 olan sunucu ise DC2’ dir. Bu durumda USN leri bir daha hatırlayalım.
Mesele şu anda DC1, DC2 için güncel USN numarası olarak “12494” olarak biliyor, ancak DC2 nin güncel numarası ise “12768”.
Bu çok normal bir durum çünkü DC ler arka tarafta sürekli olarak açık ve hizmet verdiği için değişiklik oluyor ve bunları yakalamak çok mümkün değil, bakın üst üste repadmin çalıştırmama rağmen hala farklar var.
Bu nedenle biz aslında obje üzerinden ilerleyeceğimiz için bu kısmı atlıyorum. Bana buradaki USN numarası değil objenin sunucular üzerindeki USN numarası lazım. Örnek kullanıcımız Hakan Uzuner olacak.
Repadmin /showmeta “CN=Hakan Uzuner,OU=IT,DC=cozumparkbp,DC=COM”
Gördüğünüz gibi her bir attribute için ayrı USN tutulmaktadır. Bunu DC2 içinde çekelim
Burada dikkat ederseniz her DC objeler için local ve originating USN olmak üzere iki ayrı USN saklamaktadır. Bunun temel sebebi aşağıdaki şekilde özetlenebilir.
Gördüğünüz gibi DC1 de bir kullanıcı açılır ve bu bilgi DC2 ye verildiği zaman, DC2 bu kullanıcıyı ayne şekilde kendi veri tabanında tanımlar, ancak tanımlarken o DC’ nin USN numarası ile tanımlama yapar.
Daha sonrada bu objenin herhangi bir öz niteliğinde ( attribute ) değişiklik olursa ki en güzel örnek şifre değişikliğidir, yukarıda görüldüğü gibi bu öz nitelik değişikliği o anda hangi dc üzerinde yapılır ise artık o öz nitelik için Originating DC tablosuda güncellenir. Örneğin Jeff Smith kullanıcısının tüm öz nitelikleri için Originating DC = DC1 iken, “userPassword” öz niteliği için bu değer DC2 yi gösterir.
Evet özetleyip toparlamak gerekirse malum konumuz olan AR ye gireceğiz daha J ama malum AR anlamak için DC lerin bu replikasyonu nasıl yaptığını iyi bilmek gerekli bu şekilde özetlenebilir.
Peki bizim kullanımız olan Hakan Uzuner için USN değerlerini aldık. Şimdi yedek alma işlemlerine başlayalım.
Öncelikle her iki DC için system state yedeğini alalım. Bunun için Windows server backup aracının kurulumu ve yedek alma komutları sırası ile aşağıdaki gibidir.
add-windowsfeature windows-server-backup –includeallsubfeature
Ardından yedek işlemini başlatıyorum.
Wbadmin start systemstatebackup –backuptarget:e: -quiet
Yedek alma işlemi bittikten sonra Hakan kullanıcısını siliyorum
Hemen ardından bu obje için USN sorguluyorum
Ancak artık böyle bir obje yok. DC2 üzerinde kontrol ediyorum, sonuç aynı. Şimdi bu kullanıcıyı geri getirmemiz gerekiyor. Bu işlemden önce yani yedekten geri dönmeden önce DC’ lerin USN numaralarını bir kontrol edelim
Son durum yukarıdaki gibidir. Şimdi biz eğer normal bir şekilde DC1’ i kapatıp aldığımız yedekten geri dönersek ki onun içerisinde “Hakan Uzuner” kullanıcısı bulunuyor, bu kullanıcı GELMEZ. Evet yanlış yazmadım gelmez, çünkü siz bu yedeğe geri döndükten sonra dc açılırken ilk olarak partner olan diğer dc ler ile replikasyona başlar, diğer dc ler bu dc için daha güncel USN tuttuğu için bu bilgileri alır, örneğin yedek ile gelen Hakan kullanıcısı tekrar güncel bir obje olmadığı için silinir. Biz bu olmasın diye yedekten geri döndükten sonra Authoritative Restore işlemi gerçekleştireceğiz.
Şimdi yedekten geri dönmek için DSRM ile sistemi açıyoruz, bunu yakamak yani F8 ile uğraşmak yerine aşağıdaki komutu kullanabilir veya msconfig ara yüzünden bunu ayarlayabilirsiniz
bcdedit /set safeboot dsrepair
Şimdi yedekten geri dönelim. Logon için DSRM şifrei gerektiğini hatırlatmak isterim, bu Domain Admin şifresi olmayıp Domain kurulurken size sorulan DSRM şifresidir. Eğer hatırlamıyorsanız ntdsutil ile normal modda resetleyenilirsiniz.
Sonra komut seti ile yedek kataloğumuzu bir kontrol edelim
3 Adet farklı yedeğimiz var, ama ben en son aldığım yedeğe geri döneceğim.
Eğer yedek harici bir medyaya alınmış ve bu sunucuya şimdi taşınmış ise bu durumda yukarıdaki komut size yardımcı olmayacaktır. Bu nedenle ilk olarak aşağıdaki komut ile medyanın yolunu gösterip yedeği tanıtmalı sonra bu komut ile kontrol etmelisiniz
Wbadmin restore catalog –backuptarget:e:
Peki ben yedek dosyalarımı buldum ve versiyon numarasını not ettim “11/25/2012-13:58, şimdi bu yedeğe geri dönüyorum
Wbadmin start systemstaterecovery –version:11/25/2012-13:58 –Backuptarget:e:
Evet geri yükleme işlemi bitti ancak ben “Y” demiyorum, ekran bu şekilde iken bekliyorum ve hemen yeni bir konsol açıyorum.
Şimdi bu USN numarası eski olan yedek içerisindeki bir objeyi kurtarmak istediğim için sırası ile aşağıdaki komutları çalıştırıyorum
ntdsutil
activate instance NTDS
authoritative restore
restore object “CN=Hakan Uzuner,OU=IT,DC=cozumparkbp,DC=COM”
Soruya Yes cevabını veriyorum
Başarılı bir şekilde işlem tamamlandı. Hemen log dosyasını da kontrol ediyorum. Bu dosya komutu çalıştırdığınız dizinde yer almaktadır.
Obje doğru, Hakan Uzuner isimli kullanıcıyı kurtarmak istiyorduk.
Buda ldf dosyasının içeriği
Son olarak makine normal modda açılsın diye bu komutu koşturuyorum.
bcdedit /deletevalue safeboot
Artık yedekten geri döndüğümüz ekrandaki soruya “Y” yanıtını verebiliriz J
Makinem açılıyor,
Başarılı bir şekilde yedekten dönme işlemi gerçekleştirdiğine dair bize bir bilgi veriyor ve hemen kullanıcım gelmiş mi onu kontrol ediyorum;
Kullanıcım geri gelmiş J Peki birde USN bilgileri ne durumda onu kontrol edelim.
DC1 üzerindeki durumu
Peki neler değişti? Öncelikle makalenin başlarındaki durum ile karşılaştırmak gerekir ise aşağıdaki resmi inceleyebilirsiniz
3 yeni öz nitelik geldi, 38 olan öz nitelik sayısı 41 oldu. Bunlar yedekten geri dönme öncesinde yoktu. USN’ ler ise 12.000 lerdeyken 24.000 lere yani DC nin şu anki güncel USN numarasına göre yenilendi.
isDeleted
lastKnowParent
msDS-LastKnownRDN
DC2 üzerindeki durumu
Burada da benzer bir durum var. Orijinal kayıt DC1 den geldiği için yine orijinal USN leri 24582 olarak görüyoruz. Benzer şekilde bu objeyi kendi üzerinde 8000 USN lerde tutuyorken şimdi local USN de DC2 nin güncel USN numarası olan 13.000 lere yükselmiş.
Evet sonuç olarak başarılı bir şekilde Hakan Uzuner objesini kurtardık. Bu yöntem ile sadece user değil OU ve benzeri objeleri de kurtarabilirsiniz. Sadece restore komutu sırasında aşağıdaki gibi küçük bir değişiklik yapmanız yeterlidir.
restore subtree ou=IT,DC=cozumparkbp,DC=com
Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere esen kalın.
Bu makalenin hazırlanması için bana DEMO ortamını açan değerli ADEO Bilişim Danışmanlık ve Eğitim Hizmetlerine teşekkür ederim.
