VMWARE ESX 3.5 ORTAMINDAKİ EXCHANGE 2007 SUNUCUNUN DATA PROTECTOR KULLANILARAK DIAL-TONE YÖNTEMİYLE GERI DÖNÜLMESİ
Bu makalemde Data Protector 6.1 ürünü ile Exchange 2007 sunucu üzerinde dial-tone veri kurtarma yöntemini anlatacağım. Esasen çok çetrefilli bir iş olmamasına rağmen başımıza gelen birkaç aksilikten de bahsediyor olacağım.
ORTAMDA KULLANILAN ÜRÜNLER
1- VMware ESX 3.5 Update 3 (host)
2- Windows 2008 Enterprise 64bit işletim sistemi (guest)
3- Exchange Server 2007 Enterprise SP2 (guest üzerine kurulu)
4- Data Protector 6.1 (yedekleme çözümü)
5- Fiber Channel depolama alanı (SAN)
ORTAMDAKİ YAPI
ESX host makineler fiber kanallarla harici depolama alanına bağlıdırlar. Çift kanaldan bağlı oldukları için yedekli bir yapı mevcut. Birden fazla sayıdaki ESX hostlar arasında “High Availability” (yüksek erişilebilirlik) teknolojisi kullanılmakta. Böylece herhangi bir problem anında kesinti olmadan host ESX’ler üzerinde bulunan sanal sunucular (guest) çalışmaya devam etmekteler (otomatik olarak problemli ESX’ten problem olmayan ESX’e geçiş yaparak).
Sanal sunucularımızdan birisi de Windows 2008 sunucu üzerine kurulu bulunan Exchange 2007 sunucusu. Bu sunucuya, harici fiber depolama alanı üzerinde bulunan LUN’lardan birkaçı “Raw Mapping Device” şeklinde tanıtılmış durumda. Bu sayede sanal sunucumuz direkt depolama alanına bağlanarak üzerindeki bilgileri bu alana yazabilmekte. Exchange 2007 sunucumuzun veri yedeklemesi de HP Data Protector 6.1 ürünü ile yapılmakta.
PROBLEMİN TANIMI:
ESX sunucularının Update 3 verisyonundan Update 5 versiyonuna yükseltilmesi amacıyla Exchange 2007 sunucunun bir başka ESX hostuna transfer edilmesinden sonra diğer ESX host sunucular yükü kaldıramayarak restart ettiler. Bu esnada düzgün kapanmayan ESX hostlar açılamadı ve makineleri düğmelerinden el ile kapatılıp tekrar açtık. ESX hostlar yeniden açıldıktan sonra sanal makineler Vcenter arayüzü kullanılarak eski yerlerine alındılar.
Hiçbir makinede sorun yok iken Exchange 2007 sunucunun tanımlanmış olduğu Raw Mapping Device’lardan bir tanesi (toplam 3 adet mailbox database’leri için, 1 adet de Transaction Loglar için tanımlanmış olan 4 diskin bir tanesi) Windows 2008 içerisinde “Unallocated Space” olarak gözüküyordu. Bu yüzden mailbox database’lerinden birinin bulunduğu bu diske (ve dolayısıyla içindeki veriye) erişmek mümkün olamadı. Bu database içerisinde mailbox’ları tanımlı olan kullanıcılar posta kutularına ulaşamazken, bu posta kutularına atılan e-postalar’da HUB sunucusunda kuyrukta birikmeye başladılar ve ayrıca Transaction Loglar şişmeye başladı.
PROBLEMİN ÇÖZÜMÜ İÇİN YAPILANLAR
Problemin nereden kaynaklandığı konusunda net bir fikir sahibi olamadığımız için öncelikle eski dökümanlarımızı karıştırıp değişen bir konfigürasyon olmuş mu bunların kontrol edilmesiyle işe başladık. Görüünürde pek fazla bir değişiklik görünmese de sadece ESX host üzerinde tanımlanmış olan Raw Mapping Device’ların (RMD) harici diske eriştikleri yolların (path) değişmiş olduğunu farkettik (Şekil 1). Eskiden vmhba0:2:14:0 olan yol, şimdi vmhba0:1:14:0 olarak görünmekteydi.
Şekil 1: Yanlış görünen RMD yolu
Bu esasında çok büyük bir sorun değildi zira ESX’ler disklere iki ayrı path’ten ulaştıkları için, değişmiş gibi görünen disk path’inin sonlandığı disk zaten aynı diskti. Ayrıca dört RMD’inin dördünün de path’i değişmesine rağmen üçünün çalışıp birinin çalışmıyor olması da problemin bu olma ihtimalini çok düşürüyordu. Biz yine de pathleri eski hallerine almayı denedik fakat bu çabamız bir sonuca ulaşmadı (Şekil 2).
Şekil 2: Diskler için tercih edilen yol tanımlama ekranı
Daha sonra ESX üzerinde bulunan sanal sunucumuzun .vmx dosyasına bakalım dedik. Bu dosya, sanal sunucunun konfigürasyonunun tutulduğu dosya. Bir başka sunucunun .vmx dosyasını da referans olması için, bu dosyanın yanında açtık. İki dosya arasında birkaç değişik alan gördük. Bunların en önemlisi eskiden MB01_2.vmdk şeklinde görünen disk dosyamızın, konfigürasyonda MB01_7.vmdk şeklinde görünüyor olmasıydı. Bunu da MB01_2.vmdk şekline getirip sanal sunucumuzu yeniden başlattık (Şekil 3). Bu aksiyonumuz da bir işe yaramadı. Disk hala Windows 2008 içerisinde “Unallocated Space” olarak durmaktaydı.
Şekil 3: Sanal sunucunun .vmx dosyası (ilgisiz alanlar silinmiştir)
Diskin belki başka bir sanal sunucuya tanıtılırsa düzeleceği umuduyla RMD’ı Exchange sanal sunucumuzdan kaldırıp, başka bir sanal Windows sunucuda RMD yaptık. Yeni sanal sunucuda da diske baktığımızda hala karşımızda Unallocated Space duruyordu.
ESX tarafında pek ümidimiz kalmayınca problemin belki Windows içerisinden çözülebileceğini düşünüp Disk Yöneticisi kısmını açtık. Burada Unallocated Space olarak görünen diskin üzerine sağ tıklayarak “Simple Disk…” seçeneğini seçtik. Sihirbazı devam ettirerek format atmadan diske bir harf verdik. Artık diskimiz Unallocated Space yerine RAW disk olarak duruyordu ve biz hala diske ulaşamıyorduk (Şekil 4).
Şekil 4: RAW disk alanı
Bu işlemlerle uğraşmamız 1-1,5 saat kadar sürmüştü ve insanlar hala posta kutularını kullanamıyorlardı. Biz de daha fazla uğraşmanın gereği olmadığına karar verip elimizdeki yedeklerden posta kutularını dönmeye karar verdik. Bunun için yedeklerimizi aldığımız Data Protector 6.1 ürününün Exchange verilerinin geri dönülmesinin anlatıldığı “How to use Data Protector 6.0 or 6.10 with Exchange Recovery Storage Groups to restore a single mailbox” dökümanını açtık ve burada söylenildiği gibi Exchange 2007 sunucumuz üzerinde “Recovery Storage Group” (RSG) oluşturduk. Bunun oluşturulması için öncelikle veritabanını kurtaracağımız Exchange 2007 sunucuda EMC’yi açtık. Toolbox kısmına çift tıklayarak, “Database Recovery Management” kısmına geldik. Yaptığımız iş için tanımlayıcı bir etiket bilgisi girdikten sonra (Şekil 5) Next linkine bastık ve “Create a recovery storage group” linkine tıkladık (Şekil 6). Önümüze o sunucuda tanımlı olan depolama grupları liste halinde geldi ve bunlardan ilgili olanı seçerek Next linkine tıkladık (Şekil 7). Burada seçtiğimiz depolama alanını esasında Exchange sunucu, Recovery Storage Group ile ilişkilendiriyor ve biz geriye dönme işlemini yaptığımızda tüm veri asıl veritabanı yerine, bu Recovery Storage Group içerisine yazılıyor. Son sayfadaki yol tanımlarını kontrol ettikten sonra “Create the recovery storage group” linkine tıklayarak işlemleri bitirdik (Şekil 8).
Şekil 5: Sunucu bilgisinin girildiği ekran
Şekil 6: Görev seçiminin yapıldığı ekran
Şekil 7: Depolama grubunun seçildiği ekran
Şekil 8: Recovery Storage Group’un yaratıldığı son ekran
Artık RSG’imizi oluşturduğumuza göre yedeklerimizden geri dönmeye başlayabilirdik. Bunun için Data Protector 6.1 üzerinde “Restore” kısmını açtık ve burada “MS Exchange Server” kısmını genişlettik. Burada veritabanımızın uçtuğu sunucuyu bulduk ve genişlettik. “MS Exchange Server [Microsoft Exchange Server (Microsoft Information Store)]” kısmına çift tıkladık. Sağ tarafa yedeği alınmış olan veritabanlarının ve Transaction Log’ların listesi geldi. Bu esnada yedekleme stratejimizin haftanın bir günü FULL (Pazar günü), diğer günlerin de Incremental olduğunu belirtmem gerekir (gece saat 11:00’de). Felaket anının da Çarşamba günü sabah olduğunu söylersek bize gerekli olan yedek dosyaları Pazar gününün FULL yedeği ile Pazartesi ve Salı geceleri alınan Incremental yedekler.
Sağ taraftaki listeden veritabanı için alınmış FULL yedeği seçtik ve ayrıca Log dosyaları için olan INCREMENTAL yedeği seçtik. Burada dikkat edilmesi gereken birşey var. O da Log yedeğini seçtiğimizde tarih olarak son alınmış olan Incremental yedeğin gelmesi. Bu şekilde bir geri dönüş yapılırsa Full yedek ile son Incremental arasında yedeği alınmış olan log dosyalarını geri dönememiş olacaktık. O yüzden Log yedeğinin üzerine sağ tıkladık ve özelliklerine girdik (Şekil 9).
Şekil 9: StoareCG/LOGS/Logs yedeği için özellikler ekranı
Burada karşımıza gelen “backup version” listesinden son FULL yedeğimizden sonra gelmesi gereken Incremental yedeği seçmemiz gerekiyordu ama burada da bir ayrıntı mevcuttu. Veritabanının Full yedeği sonrasında alınmış bir Full yedek de bu listede mevcuttu (Şekil 9). Buradaki Full görünen yedekse esasında şu idi: Data protector veritabanının Full yedeğini alırken de posta kutusuna tranaction’lar gelmeye devam ediyor. Bu transactionları da Data Protector “Full” etiketi basarak yedekliyor (1/4/2010 12:11:19 AM full).
Buradaki Full etiketli yedeği seçtik ve OK tuşuna bastık. Options sekmesine geldiğimizde ise nereye yedeği döneceğimizi söylememiz gerekiyordu. Burada “Restore to another client” kutusunu işaretleyerek, listeden sunucumuzun ismini seçtik. “Directory to temporary log files” içerisine de bir yol girdik (c:\tmp – bu yol hedef sistemdeki bir yol olmalı). Aşağıdaki hiçbir kutuyu işaretlemeden Restore düğmesine bastık (Şekil 10).
Şekil 10: Options sekmesi
Data Protector bize başarı ile geri dönüşün sağlandığını ve ayrıca bu geriye dönülen verinin üzerine ekstra yedeklerin de yazılabileceğini söyledi. Bunu söylemesinin sebebi şu: Biz restore dediğimiz ekranda kutuların hiçbirini işaretlememekle, geri dönülen verinin bir bütünün parçası olduğunu ve son geri dönülen veriler olmadığını söylemiş olduk. Bu sayede geriye kalan Incremental yedeklerimizi de bu geriye dönülen verinin üzerine ekleyebileceğiz.
Üst tarafta yaptığımız işlemle son Full yedeğimizi ve Full yedek alındığı esnada oluşan Transaction Log’ların yedeğini geri dönmüş olduk. Sırada Pazartesi Incremental yedeğinin (1/4/2010 11:05:11 PM incr) geri dönülmesi işlemi vardı. Bunun için yine aynı yerden Log yedeğine sağ tıklayarak özelliklerine geldik ve Pazartesi tarihli Incremental yedeği seçip OK tuşuna bastık. Database’in yanındaki kutuyu da temizledik ki Full veritabanı yedeğini bir daha geri dönmeyelim. Options sekmesindeki herşey aynı kalacak şekilde Restore dedik ve Data Protector bir öncekinde olduğu gibi başarı ile geri dönüşün sağlandığını ve ayrıca bu geriye dönülen verinin üzerine ekstra yedeklerin de yazılabileceğini söyledi.
Artık geriye bir tek Salı Incremental yedeği kalmıştı. Bunun için yine aynı yerden Log yedeğine sağ tıklayarak özelliklerine geldik ve Salı tarihli Incremental yedeği seçip (1/5/2010 11:05:07 PM incr) OK tuşuna bastık. Options sekmesinde ise “Last restore set” ile “Last Consistent state” kutularını işaretledik. Bu kutuları işaretlemekle esasen şunu dedik Data Protector yazılımına: Bu döndüklerim artık son yedek dosyaları. Bundan sonra (bu geri dönüş operasyonu için) daha fazla veri geriye dönmeyeceğim. Restore dedik ve Data Protector başarı ile geri dönüşün sağlandığını söyledi. Artık Data Protector ile olan işimiz bitmişti. Tüm konsantrasyonumuzu Exchange RSG veritabanına verebilirdik.
Exchange sunucu üzerinde Exchange Management Console (EMC) arayüzünü açtık ve Toolbox kısmına geldik. Burada “Data Recovery Management” seçeneğine çift tıkladık ve karşımıza gelen ekranda da “Mount/Dismount Database” seçeneğini seçtik. Burada geri dönüşünü yapmış olduğumuz veritabanı karşımıza geldi. Seçerek tamam dediğimizde başarılı bir şekilde veritabanının bağlandığı mesajını verdi ve bir önceki sayfaya Previous linki ile geri döndük.
Artık posta kutularını geri dönebilirdik. Bunun için öncelikle boş bir veritabanı oluşturmamız gerekiyordu (ulaşamadığımız veritabanı için). Uçan diskimizin aynı harfinden olmak üzere yeni bir disk’i sanal makineye bağladık ve daha önceki klasör yapımızın aynısını bu disk üzerinde de oluşturduk. Daha sonra EMC içerisinde veritabanına (Server Configuration -> ilgili Sunucu seçildiğinde sağ alt penceredeki veritabanı ismi) sağ tıklayarak “mount database” dedik fakat bize bir hata verdi. Burası esasında önemli bir kısım zira bu hatayı normal şartlarda vermemesi gerekirdi. Bizdeki durumda veritabanının kendisine ulaşılamazken Transaction Log’lara (kaybolan veritabanının gerçek transaction logları) ulaşılabildiğinden hata almıştık. Bunun için gerçek Transaction Logların bulunduğu klasör altında ne varsa hepsini sildik. Bir daha mount database dediğimizde ise karşımıza “böyle bir veritabanı bulunamadı, yerine yenisi oluşturulacaktır” tarzında bir uyarı mesajı geldi. Bunu Evet butonuna basarak geçtiğimizde ise Exchange yepyeni ve boş bir veritabanı oluşturdu. Bu esnada kazancımız şu oldu: Bu veritabanına bağlı olan kullanıcıların hepsi artık e-posta alıp vermeye başlayabilirlerdi. Kaybımız ise (ilk etapta) kullanıcılar posta kutularını boş göreceklerdi.
“Dial-tone recovery” olarak adlandırılan bu geri kurtarma yönteminde seçebileceğimiz iki adet yol vardı. Birincisi halihazırdaki boş (ama yeni e-postaların gelmiş olduğu) veritabanı ile backup’tan geri döndüğümüz veritabanındaki e-postaları birleştirmek. İkinci yöntem ise boş yaratmış olduğumuz veritabanı dosyasıyla, backup’tan döndüğümüz veritabanı dosyasının yerlerini değiştirmek. Bu diğer yönteme göre daha hızlı bir yöntem. Fakat ikinci bir iş olarak, boş veritabanına gelmiş olan e-posta’ların da (boş veritabanı yaratıldıktan şu ana kadar gelen) geri dönülmesi gerekecek. Biz ikinci yöntemi tercih ettik zira işimiz daha kısa zamanda bitecekti.
“Data Recovery Management” penceresinde “Swap databases for ‘dial-tone’ scenario” linkine tıkladık (Şekil 11). Bu RSG içerisindeki veritabanını seçebileceğimiz başka bir ekranın açılmasını sağladı (Şekil 12). Sadece bir adet geri dönülmüş veritabanımız olduğundan ilgili bilgileri kontrol ediyoruz (sunucu ismi, RSG ismi, bağlı bulunan storage ismi vs) ve “Gather swap information” linkine tıklıyoruz. Bir sonraki ekran son ekran (Şekil 13) ve bütün bilgiler bu ekranda görüntüleniyor. Yapabileceğimiz zaten tek birşey var. “Perform swap action” linkine tıklıyoruz. Bu kadar. Veritabanları saniyeler içinde yer değiştiriyorlar. Esasında veritabanları yer değiştirmiyor, sihirbaz Aktif Dizin tarafında veritabanlarının yol bilgilerini değiştiriyor.
Şekil 11: Görev seçim ekranı
Şekil 12: RSG içerisinden veritabanı seçme ekranı
Şekil 13: Veritabanı değişim seçenekleri seçim ekranı
Bu işlemde bittikten sonra yapılması gerekli tek birşey kaldı. Bu da yeni veritabanı oluşturulup geri dönme işlemi tamamlanana kadar, yeni veritabanına gelen yeni e-postaların kurtarılması işlemi. Bunun için eski veritabanı ile şu an RSG’ye dönüşmüş olan yeni veritabanının birleştirilmesi gerekli.Bu işlem için (merge) “Data Recovery Management” penceresinde “Merge or copy mailbox contents” linkine tıkladık. Bir sonraki ekranda “Gather merge information” linkine tıkladıktan sonra gelen ekranda “Perform pre-merge tasks” dediğimizde, sihirbaz karşımıza yeni e-postaların kaydedildiği veritabanını getirdi. Kurtarmak istediğimiz posta kutularını listeden seçtik (ki biz hepsini seçtik) ve “Perform merge actions” dedik. Artık geriye dönme işlemi başlamıştı. Yeni gelen e-posta sayısı nispeten az olduğu için bu işlemde dakikalar içerisinde sonlandı. İşlem bittiğinde ise “Data Recovery Management” penceresinde herhangi bir hata var mı yok mu bunlar listelendi (ki biz herhangi bir hata almadık). Bu işlem ile yeni gelen e-postaların hepsi eski e-postalara eklendi.
Tüm işlemler sonunda artık kullanıcılar Outlook’larını bir kez kapatıp açtıklarında eski e-postalarına da ulaşmışlardı. Hepsi bu kadar :)
RSS feed for comments on this post.
