Microsoft Exchange için Kesintisiz Veri Koruması ve Kendine Getirme

Microsoft Exchange için Kesintisiz Veri Koruması ve Kendine Getirme

 Microsoft Exchange için Kesintisiz Veri Koruması ve Kendine Getirme Brien M. Posey Yayın Tarihi: Mayıs 2008 Telif Hakları © 2008, Lucid8. Tüm Hakları Saklıdır. Microsoft Exchange için Kesintisiz Veri Koruması ve Kendine Getirme Teknolojideki gelişmelere rağmen birçok kuruluş on yıllar önce kullanılan yedekleme tekniklerinin benzerlerine güvenmektedir. Bu teknikler güvenilir olarak bilinse de, günümüz dünyasında giderek kullanışsız hale gelmektedir. Bu tanıtım yazısında, denenmiş ve doğru yedekleme tekniklerinin artık uygulanabilir olmamasının nedenlerini tartışacağım. Bununla birlikte size, nispeten yeni bir yedekleme biçimi olan Kesintisiz Veri Korumasını (Continuous Data Protection ‐ CDP) tanıtacağım. İçindekiler Kesintisiz Veri Koruması (Continuous Data Protection ‐ CDP) Nedir ? 1 Geleneksel Yedekleme Tekniklerindeki Sorun 2 Microsoft Exchange Server için Kesintisiz Veri Koruması 3 Microsoft Exchange Server Veri Tabanına ve İşlemine Genel Bir Bakış 3 Online Yedekleme Sırasında Neler Olur? 4 Exchange Server’ın Yedekleme Sorunları 4 Exchange Server için Üçüncü Parti Veri Koruması 6 Lucid8’den DigiScope 7 Sonuç 7 Telif Hakları © 2008, Lucid8. Tüm Hakları Saklıdır. 1 Kesintisiz Veri Koruması (Continuous Data Protection ‐ CDP) Nedir ? Kesintisizi Veri Koruması, verilerin günde bir kez yerine neredeyse anında yedeklendiği, yeni bir teknolojidir. Kesintisiz veri koruması genel olarak, bir diskten diğer bir diske ve oradan da manyetik banda aktarılan bir mimariye dayanmaktadır. Bunun anlamı, manyetik banda yedekleme yapan geleneksel yedeklemenin aksine, verilerin gün boyunca sabit diske yedeklenmesidir. Sabit diskler genellikle manyetik bantlara göre daha hızlı ve güvenilirdir. Aynı zamanda yedekler, sabit disklerde saklanmasından dolayı, genellikle tesis dışında saklanan manyetik bant yedeklemelerine göre daha kolay erişilebilir haldedir. Mimarinin manyetik bant kısmı, yedekleri içeren sabit disklerin manyetik bantlara yedeklenmesi sırasında devreye girmektedir. Geleneksel/eskiden kalma manyetik bant yedekleme uygulamanızı ve
EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME Sponsor LUCID8
altyapınızı, yangın, sel, deprem ya da kasırga gibi bir felaket durumunda kullanmak üzere, CDP veri deposunun tesis dışında kopyalanması için kullanırsınız. Geleneksel Yedekleme Tekniklerindeki Sorun Eğer bugünün bilgisayar teknolojisini 10 yıl öncenin teknolojisiyle kıyaslarsanız, son on yılda programlamanın bütün özelliklerinin sanal olarak değiştiğini görürsünüz. Gerçekten önemli oranda değişmemiş olan birkaç alandan biri de manyetik yedeklemedir. 10 yıl önce sahip olduğumuzdan daha yüksek kapasitede manyetik bantlara ve daha hızlı manyetik bant sürücülerine sahip olsak da, gecelik manyetik bant yedeklemesinin arkasındaki genel anlayış, tıpkı 1960’larda olduğu gibi bugünde aynıdır. BT üzerine çalışan herkesin bildiği gibi, gecelik manyetik bant yedeklemesindeki temel mantık, manyetik bant sürücüsüne bir bant takmak ve gece herkes evine gittikten sonra yedekleme işlemini gerçekleştirmesi için sürücüyü programlamaktır. Bu teknik on yıllar boyunca çalışmış olsa da, basit bir şekilde bir takım nedenler yüzünden artık uygulanabilir değildir. Geleneksel yedeklemenin artık uygulanabilir olmadığını anlamak için, patronunuza, “ Kabul edilebilir veri kaybı ne kadardır?” şeklinde bir soru sorduğunuzu hayal edin. Cevabın, hiçbir oranda veri kaybının kabul edilebilir olmadığı, olacağına nerdeyse bahse girebilirim. Bunu aklınızda tutarak, gecelik yedeklemenin 03:00’da başladığı ve sabah 06:00’da bittiği bir kuruluş düşünün. Şimdi de, şirketin yönetim kurulu başkanın ofise 08:00’de geldiğini ve North American Sales yönetim kurulu başkan yardımcısından gelen bir e‐postayı açtığını hayal edin. E‐
posta, şirketin en büyük müşterilerinden birinin, belirli koşulları sağlayarak yüklü miktarda bir satın alma gerçekleştirmek istediği hakkındadır. Şirket aynı zamanda, cevabın 15:00’dan geç gelmemesini talep etmektedir, aksi takdirde iş, şirketin rakibi olan diğer firmaya gidecektir. Şirketin yönetim kurulu başkanı derhal ön anlaşma üzerinde çalışmaya başlar. Anlaşmanın birçok taslağının, finans, mühendislik, satış ve hukuk bölümlerinin üyelerine e‐posta yoluyla gönderilip alınmasından sonra, anlaşmanın son hali yönetim kurulu başkanına, değerlendirmesi ve imzası için saat 12:45’te ulaşır. Tam gelen e‐postayı açmak üzereyken Exchange Server’ın sabit disk dizilimi (array) çöker. Bu aksiliğe gidermek için hemen dizilimi yerine koyarsınız ve geçen gecenin yedeklemesini geriye döndürürsünüz. Bundan kısa bir süre sonra, şirketinizin yönetim kurulu başkanından, kendisinin ve diğer birçok yetkilinin gün boyunca üzerinde çalıştığı, beklemekte olan önemli bir alım hakkındaki e‐postaların nereye gittiğine dair bir telefon alırsınız. Tüm görebildiği dünkü e‐postalardır ve artık sürenin sonunda 20 dakikadan az bir süre kalmıştır. Üzücü bir şekilde şimdi, şirketinizin yönetim kurulu başkanına 03:00’dan sonra şirketin tüm üyeleri tarafından oluşturulan ya da alınan tüm e‐posta ve eklenti yedeklerinin, hatanın bir sonraki yedekleme zamanından önce gerçekleştiği için kaybolduğunu anlatmak zorundasınızdır. Böyle bir durumda, Exchange’e özgü bir CDP ürününün e‐
posta/veri kaybını en düşük seviyeye indirme hatta tamamen önleme konusunda paha biçilemez olduğunu görebilirsiniz. Exchange CDP kullanılan durumlarda bile veri kaybı ihtimali olduğu ancak muhtemel veri kaybı miktarının oldukça az olduğu göz önünde bulundurulması gereken önemli bir unsurdur. Bunun nedeni, Exchange’e atanmış yeni ve değiştirilen e‐posta öğelerinin artan kopyalarının gün boyunca sabit bir şekilde neredeyse anında yedeklenmesidir. Şüphesiz ki piyasada birçok kesintisiz veri koruması ürünü mevcuttur ve hepsinin bir şeyleri gerçekleştirmek için kendi yolu bulunmaktadır. Bazı kesintisiz veri koruması ürünleri, saat başında ya da her on beş dakikada bir gerçekleşen gölge kopya yedeklemesini kullanmaktadırlar. Diğer çözümler işlem tabanlıdır ve bu sayede yedeklemeler daha sık gerçekleşmektedir. Önceki örneğimde size kesintisiz veri korumasının kaybolabilecek verilerin geri getirilmesini sağlayan bir durum sunmuştum. Bu örnek her ne kadar yönetim kurulu başkanın üzerinde çalıştığı hayali bir projeye odaklanmış olsa da, kuruluş içerisindeki tüm çalışanların, bir donanım ya da Exchange veri tabanı aksaklığından etkilenebilme ve bu yüzden geçmişe ait tüm e‐postalara erişimlerinin ve yeni e‐
postalar gönderip alma becerilerinin kısıtlanabileceği ihtimalinin olduğunu hatılamak oldukça önemlidir. Disk hatasının gece geç saatlerde, yedekleme işleminden az önce, gerçekleşmesi durumunda neler olacağını düşünün. Böyle bir durumda, tüm güne ait veriler tamamen kaybolmuş olurdu. Ancak bunun yerine bir Exchange CDP çözümü olsaydı, gölge kopyası yedeklemesi koruması kullanıldığı durumlarda şirket hiç bir koşulda bir saatlik veriden fazlasını kaybetmez, işlem tabanlı bir CDP çözümü kullanıldığı durumlarda ise kayıplar sadede dakikalar ya da saniyelerle sınırlı kalırdı. 2 EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME Sponsor LUCID8 Microsoft Exchange Server için Kesintisiz Veri Koruması Daha önce de belirttiğim gibi, piyasada birçok CDP ürünü bulunmaktadır. Çoğunluğu tamamen dosya sunucularıyla çalışmak için donatılmışsa da, diğerleri Microsoft Exchange Server’ı desteklemektedir. Exchange için kesintisiz bir veri koruması çözümüne yatırım yapmayı değerlendirmeden önce, farklı ürünlerin farklı yöntemlerle çalıştığını anlamanız oldukça önemlidir. Çeşitli ürünlerin yöntemleri arasındaki farklılıkları değerlendirmeden önce de, Exchange Server veri tabanın nasıl çalıştığı hakkında temel bir anlayışa sahip olmanız gerekmektedir. Microsoft Exchange Server Veri Tabanına ve İşlemine Genel Bir Bakış Eğer bir Exchange Server yöneticisiyseniz, bilgi depoları kaldırılmadan (dismount) bir Exchange Server için dosya sistemi düzeyinde bir yedekleme işlemi gerçekleştiremeyeceğinizi bilirsiniz. Kuşkusuz ki, bilgi depolarını kaldırmak, kullanıcıların erişimini engellemektedir. Bunun yerine yöneticiler Exchange sunucuları yedeklemek için genellikle Exchange’e uygun bir yedekleme uygulaması kullanmaktadırlar. Exchange Server verileri jet veri tabanında (uzatılabilir bir bellek motoru veri tabanı denilen) saklamaktadır. Daha önce de belirttiğim gibi, genellikle açık bir dosyayı yedekleyemezsiniz ve Exchange Server bağlı olduğu her zaman açık kalmaktadır. Peki, açık bir Exchange veri tabanını yedeklemek mümkün müdür? Exchange, veri kaybını önlemek için, önceden yazılmış işlem günlüklerini ve kontrol noktası dosyalarını kullanmaktadır. İşlem günlükleri, bellekteki veri tabanına işlenen tüm değişiklikleri kaydederken, kontrol noktası dosyaları, diskteki dosyalara yazılan/işlenen işlem günlüklerini kaydetmektedir. Bu tasarım aynı zamanda Exchange Server veri tabanlarını, sunucuyu kapatmadan, seçtiğiniz yedekleme ortamına yedeklemenize olanak sağlamaktadır. Exchange Server’ın en önemli bileşenlerinden biri işlem günlükleridir. Bir ileti gönderildiğinde, işlem ilk önce işlem günlüklerine kaydedilmektedir. İşlem Exchange veri tabanına (Exchange database ‐ EDB) işlenmeden önce, o veri sadece sistem belleğinde ve işlem günlüklerinde bulunmaktadır. Herhangi bir çöküş durumunda, bellekteki tüm içeriği kaybedersiniz ve elinizde sadece işlem günlüklerindeki kayıtlar kalır. Çöküş, ister sistemin yeniden başlatılmasını gerektiren önemsiz bir sorundan, isterse olağanüstü durum sorun sonrası kendine getirme planlarınızı konuşlandıracak yıkıcı bir hatadan kaynaklansın, işlem günlükleri, çökmüş bir Exchange sunucusunu geri getirmek Sponsor LUCID8 için oldukça önemlidir. Aynı süreç, alınan iletiler, silinen öğeler ve farklı klasörlere aktarılan iletiler için de geçerlidir. Bu nedenle, işlem dosyalarını RAID 1 gibi, artık (redundant) bir depolama sisteminde barındırmanız önerilmektedir, böylelikle bir donanım arızası durumunda, hiçbir veri kaybedilmemiş olacaktır. Bir grup işlem günlüğünü kaybetmek, yedeklerinizden geri yükleme yapmanızı engellemeyecektir ancak, son tam yedeklemeden itibaren olan tüm iletileriniz ve değişikliklerinizi kaybetmiş olacaksınız. Exchange sunucusu, tüm işlemleri bu günlük dosyalarına yazmak ve sistemin izin verdiği durumlarda değişiklikleri veri tabanına işlemek üzere tasarlanmıştır. Tam bir Exchange Information Store, veri tabanında yer alan tüm verilerini ve buna ilave olarak deponun işlem günlüklerindeki işlenmemiş verilerini de içermektedir. İşlemler, e‐posta gönderimi ya da alımı ya da toplantı talebi, dosya oluşturma, bir iletinin silinmesi, kopyalanması ya da taşınması vs. gibi öğelerden oluşmaktadır. Aşağıda, bir işlem sırasında gerçekleşenlerin basit bir açıklaması verilmiştir; 1. Bir ileti, belirli bir Exchange Server / Storage Group / Information Store’da yer alan kullanıcı ya da bir grup kullanıcı için ulaşır. 2. İleti ulaştığında, işlem günlüğü ara bellek (buffer) alanı olarak bilinen, RAM’deki sayfalar içerisine yerleştirilir. 3. İşlem belleğe işlendiği sırada, aynı zamanda işlem günlüklerine de işlenmiş olur. 4. İşlem için tüm operasyonlar tamamlandığında ve işlem günlüklerine işlendiğinde veri bellekten okunur ve sistem izin verdiğinde doğru veri tabanı dosyasına yazılır/işlenir. 5. Veri tabanı motoru, henüz disk üzerindeki veri tabanı dosyasına yazılmamış/işlenmemiş verinin kaydını tutmak adına, her günlük dosyası dizisi (sequence) için Edb.chk denilen bir kontrol noktası sağlar. NOT: Normal bir operasyon sırasında, işlem günlüklerinde, veri tabanı dosyasına işlenmemiş birkaç saniyelik ya da birkaç dakikalık veriler olabilmektedir. Yeni İleti Ulaşır İleti, işlem günlüğü ara bellek RAM’ine yerleştirilir İleti, bir işlem günlüğüne yazılır İleti son olarak bilgi deposuna yazılır Kontrol noktası dosyası, işlem günlüklerinin işlendiğini göstermek için güncellenir Şekil 1 Yeni ileti yerine ulaşmak üzere bu yolu izlemektedir.
EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME 3 Online Yedekleme Sırasında Neler Olur? Online bir yedekleme sırasında süreç bazında fazla bir değişiklik olmamaktadır, ancak Exchange Server’a uygun bir yedekleme uygulaması bir Exchange yedeklemesi başlattığında tüm kontrol noktaları dondurulmaktadır. Kontrol noktalarının arttırılması durmaktadır çünkü yedekleme sürecinin, kontrol noktalarının dondurulmasından sonra hangi günlük dosyalarının yedeklerinin alınacağını bilmesi gerekmektedir. Yedekleme süreci, veri tabanı dosyalarının ve gerekli günlük dosyalarının seçilen yedekleme ortamına kopyalanmasını bitirdikten sonra, kontrol noktası dosyası tekrar başlatılmakta ve yedeklemenin başlangıcı ve sonu arasında oluşturulan tüm günlüklerle birlikte daha önce işlenmemiş olan günlüklerde Exchange Information Store’a (veri tabanı) işlenmektedir. Bu yedekleme metodolojisi, bir Exchange Server’ın, kullanıcıların Exchange Server’ı kullanmaya devam ettiği veri tabanları çalışır durumdayken, yedeklenmesine olanak sağlamaktadır. NOT: Exchange 2000 Server SP 3 aracılığıyla Exchange 2003, kontrol noktası derinliğini 1.000 işlenmemiş günlüğün biraz üzerinde sınırlamak için sabit kodlanmıştır (hard‐coded). • Eğer bir yedekleme işlemi sürüyorsa ve o aralıkta 1.000’in biraz üzerinde günlük dosyası oluşturulduysa, Exchange, bu belirli depolama grubu için veri tabanlarını kaldıracaktır. O Kaldırma işlemi, tamamlanmamış işlemlerin veri tabanına işlenmesini sağlayacaktır. • İPUCU: Bu durumun gerçekleşme olasılığını azaltmak için, ağ trafiğinin ve işlemlerin yoğun olduğu zamanlarda (örneğin kullanıcıların en çok aktif olduğu, e‐posta kutularının taşındığı zamanlar vs.) yedekleme yapmaktan kaçının. NOT: Durum kimliği 1159, Uygulamaya şu tanımlamayla giriş yapacaktır; “Veri tabanı hatası 0xfffffd9a, “<Veri tabanı adı> veri tabanına erişirken, JTAB_BASE::EcUpdate işlevinde gerçekleşti”. Hata kodu 0xfffffd9a, JET_errCheckpointDepthTooDeep anlamına gelmektedir. Var olan kontrol noktası derinliğini, Performans Denetleyicisini (Performance Monitor) açarak ve Sayaçları Ekle (Add Counters) simgesine tıklayarak belirleyebilirsiniz. Sayaçları Ekle diyalog penceresi açıldığında, Performans Nesnesi (Performance Object) açılan listesinden (drop down list) Veri tabanı ==> Örnekler (Database ==> Instances) seçeneğini seçin. Daha sonra, sayaçlar listesinden Günlük Oluşturma Kontrol Noktası Derinliği (Log Generation Checkpoint Depth) seçeneğini seçin. Son olarak, denetlemek istediğiniz depolama grubunu seçin ve OK’yi tıklayın. Sayaç Ekle diyalog kutusunun neye benzediğini şekil 2’de görebilirsiniz. Exchange 2007’de, her depolama grubu sabit kodlu 5.120 işlenmemiş ESE işlem günlüğü dosyası limitine sahiptir. İşlememiş işlem günlükleri 5.000’e ulaştığında, grup içindeki depolar otomatik olarak kaldırılmaktadır. Exchange sisteme şu şekilde giriş yapmaktadır; Durum Kimliği: 1159 Durum Türü: Hata Durum Kaynağı: MSExchangeIS Durum Kategorisi: Genel Durum Kimliği: 1159 Tanımlama: Veri tabanı hatası 0xfffffd9a, JET_errCheckpointDepthTooDeep anlamına gelmektedir. Exchange Server’ın Yedekleme Sorunları Geleneksel Exchange Server yedeklemelerindeki en büyük sorunlardan bazıları, bir yedeklemeyi tamamlamak için geçen toplam süreyi ve tek bir e‐posta kutusunu geri yükleme konusundaki zorlukları içermektedir. Belki de Exchange Server yedeklemelerindeki en büyük sorun, genellikle gecede bir kez gerçekleşmesidir. Bunun anlamı, sistemin çökmesi durumunda bütün bir güne ait verilerin tamamen kaybolması olasılığıdır. Bu nedenlerden dolayı, kesintisiz veri koruması Exchange Server için ideal olarak uygundur. Buna rağmen bugüne kadar, kesintisiz veri koruması Exchange Server için kullanılabilir değildi. Ancak hem Microsoft hem de diğer üçüncü parti yazılım sağlayıcıları kısa bir süre önce Exchange için kesintisiz veri koruması çözümlerini tanıtmışlardır. Şekil 2 Kontrol noktası derinliğini takip etmek için, Performans Denetleyicisini (Performance Monitor) kullanın.
4 EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME Sponsor LUCID8 Microsoft’un şu anda Exchange Server için iki farklı kesintisiz veri koruması çözümü bulunmaktadır. Bu çözümlerden biri Microsoft’un System Center Data Protection Manager 2007’sidir. Bu ürün başta dosya düzeyinde kesintisiz veri koruması sağlamak için düzenlenmiştir ancak Exchange Server için de destek sunmaktadır. System Center Data Protection Manager, daha önce belirttiğime benzer bir şekilde, korunmuş sistemlerin zamanında enstantane (snapshot) noktalarını almak için gölge kopyaları kullanmaktadır. Bu enstantaneler her on beş dakikada bir gerçekleşebilmekte ve disk alanı uygun olduğu takdirde 9.000’e kadar enstantane saklanabilmektedir. Enstantaneler, USB ya da 1394 aracılığıyla bağlanan sürücüler hariç olmak üzere, Direct Attached Storage (DAS) üzerinde depolanabilmektedir. System Center Data Protection Manager 2007 aynı zamanda, enstantane verilerini, Fiber Kanal (Fibre Channel) tabanlı depolama alanı ağlarında ya da ISCSI aracılığıyla bağlanan sürücülerde depolamak için yapılandırılabilmektedir. Süreç, Exchange Server üzerine bir üstlenici (agent) yerleştirmeyi içermektedir. Bu üstlenicinin görevi DPM sunucusuyla iletişim kurmaktır. Üstlenici ilk olarak konuşlandırıldığında, DPM yöneticiye Exchange Server’ın bir VSS enstantanesini alması için seçenek sunmaktadır. Bu enstantane DPM sunucusu üzerinde depolanmakta ve sonraki yedeklemelerinin yapılacağı başlangıç dayanağı olarak hareket etmektedir. Bu noktadan sonra, iki farklı yedekleme mekanizması devreye girmektedir. Bu mekanizmalardan biri İşlem Günlüğü Eş Zamanlamasıdır (Transaction Log Synchronization). Bu süreç her on beş dakikada bir günlük aktarılmasına benzer bir şekilde, bir önceki eş zamanlamadan itibaren kapanmış tüm işlem günlüklerinin DPM sunucusuna kopyalanmasını içermektedir. Devreye giren diğer yedekleme mekanizması bir Hızlı Tam (Express Full) yedeklemedir. Bir Express Full yedekleme genellikle gecede bir gerçekleşmekte ve Exchange veri tabanları içerisindeki blok düzeyindeki değişikliklerin eş zamanlanmasını kapsamaktadır. Microsoft aynı zamanda Exchange Server 2007 içerisine, yerel kesintisiz yineleme (replication) ve kesintisiz grup (cluster) yineleme biçimde, kesintisiz bir veri koruması şekli yerleştirmiştir. Yerel kesintisiz yineleme ve kesintisiz grup yineleme, gölge kopyalar kullanamamakta ancak onun yerine günlük aktarmasına dayanmaktadır. Daha önce açıkladığım gibi, bir Exchange Server ortamında işlemler doğrudan veri tabanı yerine bir işlem günlüğüne yazılmaktadır. Günlük aktarımının arkasındaki düşünce, bir işlem günlüğü doldurulduğunda, koruma altına almak için günlüğün başka bir alana kopyalanmasıdır. Yerel kesintisiz Sponsor LUCID8 yinelemenin kullanımda olduğu durumlarda, işlem günlükleri korunan sistem üzerinde başka bir sabit diske gönderilmektedir. Kesintisiz grup yinelemesinin kullanımda olduğu durumlarda ise, günlük dosyaları tamamen ayrı bir sunucuya aktarılmaktadır. CCR için gereken ilave donanımı satın alırsanız, bir sonraki adım ve tam bir CDP çözümünü uygulamak için kuşkusuz ki daha iyi bir konumda olursunuz. Yerel Kesintisiz Yineleme (Local Continuous Replication ‐ LCR), işlem günlüklerin ikinci bir kopyasını oluşturmak için kullanışlı olsa da, LCR’ın verilerinizi kesintisiz bir şekilde yinelemesine rağmen, gerçek bir CDP çözümü, hatta geleneksel bir yedekleme ile aynı düzeyde koruma sağlamadığı unutulmamalıdır. Şekil 3 Yerel Kesintisiz Yineleme, işlem günlüklerini sunucu üzerindeki başka bir alana kopyalamaktadır. Bunun bir nedeni de, LCR’ın işlem günlüklerini ayrı bir alan üzerinde yinelemesi ancak bu alanın hala aynı fiziksel Exchange Server üzerinde yer almasıdır. Sunucunun yapılandırmasına bağlı olsa da, bir dizilim hatası, yinelenmiş kopyaların, işlem günlüklerinin ilk kopyalarıyla birlikte bozulmasına neden olabilmektedir. EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME 5 LCR aynı zamanda gerçek bir CDP çözümünün öğe boyundan (granularity) da yoksundur. Gerçek bir CDP çözümü ile, verilerin zamanında geri yüklenmesi mümkündür. LCR tarafından yinelenmiş verileri, bir bilgi deposunu bir işlev durumuna geri yüklemek için kullanabilirsiniz ancak, verileri belirli bir zamanda var olan duruma geri yükleme gibi bir seçeneğiniz bulunmamaktadır. Kesintisiz Grup Yinelemesi (Cluster Continuous Replication ‐ CCR) daha iyi bir çözümdür, çünkü iki ayrı sunucu kullanmaktadır. Böylelikle tek bir hata noktası olarak hareket eden tek bir sunucu ile ilişkili sorunlar ortadan kalkmaktadır. Ancak, CCR kullanmak adına ikinci bir sunucu satın almaya para harcayacaksanız, yeni sunucuyu CDP deposu olarak kullanmanız sizin için daha iyi olacaktır. Bununla birlikte, LCR’ a sorun teşkil eden, verilerin öğe boyundan geri yüklenmesi ile ilişkili konular aynı zamanda CCR için de geçerlidir. Günlük dosyalarının kopyalanması süreci, disk, işlemci ve bellek kaynaklarını tüketmektedir. Diğer bir sınırlama da, günlük taşımanın geleneksel bir yedekleme yerine kullanılamamasıdır. Bu, özellikle yerel kesintisiz yineleme kullanan ortamlar için geçerlidir. Eğer Yerel Kesintisiz yineleme tek yedekleme yönteminiz ise ve veri merkeziniz bir felaket sonucu ortadan kalkarsa, tesis dışında bir yedeklemeniz olmadığı için tüm verileriniz kaybolacaktır. Yedeklemeler konusunda olsam da, NTBACKUP, LCR ya da CCR yinelemeleri veri tabanlarınız yedeklenmesine izin vermemektedir. Günlük dosyalarınızın taşındığı veri tabanını değil, sadece özgün verileri yedeklemenize olanak sağlayacaktır. Performans açısından bakıldığında, yedeklemeleri işlemlerin aktif olarak yazıldığı konuma karşı gerçekleştirmeniz yerine, yinelenmiş verilere karşı gerçekleştirmeniz daha mantıklı gözükmektedir. Exchange Server için Üçüncü Parti Veri Koruması Şekil 4 Kesintisiz Grup Yinelemesi, güvenliği sağlamak adına işlem günlüklerini diğer bir sunucuya kopyalamak için işlem taşımasını kullanmaktadır. İşlem taşımasının bir takım faydaları olduğunu düşünebileceğinize eminim. İşlem taşımasının belki de en önemli faydası veri kaybını en düşük seviyeye indirmesidir. Exchange Server’ın önceki sürümlerinde, işlem günlüklerinin boyutu 5 MB idi. Exchange Server 2007’de, Microsoft işlem günlüklerinin boyutunu 1 MB’a düşürmüştür. İşlem günlükleri dolar dolmaz aktarıldığı için, bir hata durumunda teorik olarak 1 MB’tan fazla veri kaybetmeniz mümkün değildir. Günlük taşımasının belki de en büyük ikinci avantajı, aşırı derecede kolay ve uygulanmasının ucuz olmasıdır. Günlük taşımasını yapılandırmak neredeyse bir Aktif‐Pasif grup (cluster) uygulaması ile aynı karmaşıklıktadır. En küçük kuruluşlar bile, sadece Exchange 2007 sunucusuna ilave bir sabit disk ekleyerek ve günlük taşıma özelliğini aktif hale getirerek, günlük taşımanın avantajlarından faydalanabilmektedirler. Bu faydalarına rağmen, günlük taşımanın da kendi sınırları vardır. Göz önüne almanız gereken başlıca konu, günlük taşımasının oldukça yoğun kaynak gerektirebilmesidir. 6 EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME Daha önce de belirttiğim gibi bazı üçüncü parti yazılım sağlayıcıları, Exchange Server için kesintisiz veri koruması çözümleri geliştirmişlerdir. Bu ürünlerin bir tanesi de Lucid8 tarafından sunulan DigiVault’tur (http://www.lucid8.com/). Exchange Server 2007 gibi DigiVault da, İşlem günlüklerinin güvenli bir şekilde muhafaza edileceği farklı bir alana kopyalamak için, günlük taşımasını kullanmaktadır. DigiVault, özellikle Exchange 2007’nin günlük taşıma mekanizmasının çeşitli aksaklıklarını gidermek için tasarlanmıştır. DigiVault’un Exchange Server’ın dahili günlük taşıma mekanizması üzerindeki en belirgin faydası, Exchange Server 2003 ile birlikte çalışabilir olmasıdır. Microsoft’un günlük taşıma mekanizması ilk olarak Exchange 2007’de tanıtılmıştır ve Exchange 2003 ile birlikte çalışmamaktadır. DigiVault’un en az birincisi kadar önemli olan ikinci bir faydası ise, bir LCR/CCR hatası durumunda size Exchange Server’ı belirli bir noktaya geri yükleme seçeneği sunmasıdır. Lucid8, aynı zamanda yazılım lisansını DigiVault’u Exchange Server 2003 ile birlikte uygulayabilmeniz ve Exchange 2007’ye iyileştirmeniz durumunda, lisansı hiçbir ücret ödemeden aktarmanız için yapılandırmıştır. DigiVault kesintisiz veri korumasını gerçekleştirmek için günlük taşıması kullansa da, Exchange Server 2007 konuşlandırmış olan ve LCR ya da CCR kullanan kuruluşlar da DigiVault'u faydalı bulabilmektedir. DigiVault aynı zamanda, LCR ya da CCR hatasın durumunda bir güvenlik ağı olarak hareket edebilmekte ve bir Exchange Server veri tabanını belirli bir zamana geri yüklemek için gereken esnekliği sağlamaktadır.
Sponsor LUCID8 Exchange 2007 ortamında, bir sistem hatası durumunda yinelenmiş günlük dosyalarını, veri tabanını kendine getirmek için kullanabilirsiniz. Ancak, veri tabanını sadece en yakın günlük dosyasının aktarıldığı zamanda (birkaç dakika içerisinde olmalıdır) var olan durumuna döndürebilme şansınız olacaktır. Sorun veri tabanını daha önceki bir duruma geri döndürme şansınızın olmamasıdır. Bir gece önceki yedeklemeyi geri yükleyerek daha önceki bir duruma geri döndürebilirisiniz ancak bu, yedekleme yapıldıktan sonra eklenmiş olan tüm verilerinizin kaybolması anlamına gelecektir. İlk başta, Exchange 2007’deki tek seçeneğinizin, veri tabanını birkaç dakika önce var olan durumuna ya da bir önceki yedeklemeye geri yüklemek çok da önemli bir sorunmuş gibi görünmeyebilir. Ancak, veri tabanınızı belirli bir zamana geri döndürebilme becerisi, oldukça önemli bir özelliktir. Bilgi deponuzu alt üst eden bir virüs düşünün. Bunun gibi bir durumda, bir kaç dakika öncesindeki durumu geri yüklemek fazla bir şey ifade etmeyecektir. Bir gece önceki yedeklemeye geri yüklemek ise önemli miktardaki verilerin kaybolması anlamına gelebilmektedir. Belirli bir zamana geri yüklemek, veri tabanınızı virüs kaynaklı saldırıdan az önceki durumuna döndürmenize olanak sağlayacaktır. Bir Exchange veri tabanını belirli bir zamana geri yüklemek istiyorsanız, DigiVault gibi bir üçüncü parti kesintisiz veri koruması çözümü kullanmak en iyi seçeneğiniz olacaktır. Bazı durumlarda, işlem günlüklerinin bir kopyasını oluşturduğunuz ve daha sonra hatanın oluştuğu zamandan sonra oluşturulan tüm işlem günlüklerini ortadan kaldırdığınız, bir çevir sesi (dial tone) kendine getirmesi gerçekleştirmeniz mümkün olabilmektedir. MSDN üzerinde http:// msdn2.microsoft.com/en‐us/library/aa579091 (EXCHG.80).aspx adresinde açıklandığı gibi, var olan günlüklerin tekrarlanması veri tabanınızı istenilen zamana geri yükleyecektir. Ancak bu süreç, belirli bir zamana geri yükleme yapmak için DigiVault gibi bir ürün kullanmaktan çok daha fazla iş gücü gerektirmekte ve hatalara daha fazla yer bırakmaktadır. Çevir sesi geri yüklemesi yöntemi aynı zamanda, hatanın oluşması ve kullanıcıların verilerini geri alması arasında geçen sürenin oldukça fazla olmasıyla sonuçlanabilmektedir. Exchange 2007’nin günlük taşıma mekanizması, bir ortam hatası ya da diğer bozulma biçimleri durumunda hızlı bir kendine getirme seçeneği sunmaktadır. Ancak, kendine getirme süreci tüm depolama grubunu geri yüklemenizi gerektirmektedir. Buna karşın DigiVault size, manüel bir kendine getirmeden daha az zor olan, işaretle ve tıkla kendi getirme seçeneğini sunmaktadır. Lucid8 aynı zamanda, Yöneticilerin bireysel e‐
posta kutuları ya da bir e‐posta kutusundaki bireysel iletiler üzerinde kendine getirme işlemi gerçekleştirmelerine olanak sağlayan ve DigiVault, Exchange Information Store’un sadece bir kopyası, hatta üçüncü parti bir yedekleme çözümü üzerinde çalışan bir eklenti (add‐on) geliştirmiştir. Sponsor LUCID8 Lucid8’den DigiScope Exchange dünyasında en iyi saklanmış sırlardan biri de offline Exchange veri tabanı dosyalarını açmak için üçüncü parti uygulamalarını kullanma becerisidir. Bu özellik yeni değildir ancak Lucid8 tarafından kısa bir süre önce büyük oranda geliştirilmiştir. Birçok Exchange Yöneticisinin bu özellikten ve bu çözümün hem büyük hem de küçük mağazalar için maliyet etkin olduğundan nasıl haber olmadığı beni her zaman şaşırtmıştır. Lucid8’in sunduğu DigiScope, bir ya da birden fazla offline Exchange Veri Tabanından, PST dosyasından ya da online Exchange sunucuları ürünlerinden, öğeleri doğrudan açmanıza, aramanıza ve çıkarmanıza (extract) olanak sağlamaktadır. DigiScope kullanmanın bir diğer büyük faydası da, offline EDB ve PST dosyalarına erişimi olan bir XP masaüstü kadar küçük bir şekilde kurulup, çalıştırılabilir olmasıdır (örneğin, Exchange sunucu ürünü üzerinde kurulması, çalışması ya da erişimi olması gerekmemektedir). Böylelikle, yöneticiler, uyumluluk görevlileri ve yasal ekipler, Exchange veri tabanının offline bir kopyasından, Exchange sunucu üretimini etkilemeden, arama, çıkarma ve kendine getirme işlemlerini gerçekleştirebilmektedir. Bana göre bu tür araçlar, Exchange kullanan mağazalar için, belirli e‐posta kutusu ve e‐posta öğelerinin aranmasını, çıkarılmasını ve geri yüklenmesini hızlandırması ve RSG’ler kullanılmasından daha etkili olmasından dolayı paha biçilemez bir kazançtır. Bu teknoloji özellikle, anahtar kelime araması ya da eklentiler kullanılarak e‐posta kutularından tek bir öğenin ya da belirli öğelerinin geri yüklenmesini gerektiren durumlarda oldukça kullanışlıdır. DigiScope, basit ama güçlü bir Outlook tabanlı ara yüze sahip olması ve eklentiler, hatta sıkıştırılmış dosyalar arasında arama yapabilmesi nedeniyle, kesinlikle favorilerimden biridir. Gerekli öğelerin yerini belirledikten sonra, üretim e‐posta kutuları içerisine birleştirme gerçekleştirebilir ya da PST, MSG hatta XML olarak aktarabilirsiniz. Beni her zaman hayran bırak kısım ise, verileri almak için hiçbir Exchange sunucusunun gerekli olmamasıdır. Sonuç Görebildiğiniz üzere, Exchange Server 2007'nin yerel kesintisiz yineleme ve kesintisiz grup yineleme özellikleri, kuruluşlara çok düşük bir maliyetle, verilerinin korunması için ek bir koruma seviyesi sunabilmektedir. Böyle olsa bile, bu yeni özelliklerin de eksik yönleri bulunmaktadır. Eğer Exchange organizasyonunuz, bu özelliklerin sağladığından daha dayanıklı bir korumaya ihtiyaç duyuyorsa ya da bir Exchange Server 2003 ortamında kesintisiz veri korumasına ihtiyacınız varsa, bir üçüncü parti çözümü konuşlandırmanız sizin için en iyisi olacaktır. EXCHANGE İÇİN KESİNTİSİZ VERİ KORUMASI VE KENDİNE GETİRME 7