Uçtan Uca SCDPM 2012 R2 Vol7 – DPM Yedekleme Stratejileri

Bu bölümde niçin system state, sistem sürücüleri veya farklı verilerin yedeklemesini gerçekleştirdiğimizi daha iyi anlayacaksınız. Ayrıca burada koruma grupları (protection groups), servis seviye antlaşması (Service Level Agreement – SLA), yönergeler (guidelines) ve yardımcı araçları sağlanarak şirkerinizi için gerçekden kritik olan veriler için tanımlanabilecektir.

Şirket verilenizi koruma altına almaya başlamadan önce, mutlaka yedeklemenin önemini anlamalısınız. Bir çok sistem yöneticisi şirketi için hangi verilerin yedeklenmesi gerektiğini veya hangi verilerin kritik bir değere sahip olduğunu bilinmemesinden dolayı sağlıklı bir yedekleme stratejisine sahip değil. Internal ve/veya External SLA tanımlanan bir strateji planlamak yerine işletme, yedeklenen veriyi barındırabilmek için daha fazla depolama donanımına harcama yapıyor.

Lütfen unutmayın ki, planlamaya başalamadan önce bu bölümü okumanız size DPM kurulum oratamınızı iyi anlabilmeniz için faydalı olacaktır.

Bu bölümde değineceğimiz konular aşağıdadır.

  • Veri Tanımı
  • Microsoft’ un yaklaşımı
  • Servis Seviye Antlaşmaları (SLA)
  • Recovery Point Objectives (RPO)
  • Recovery Time Objectives (RTO)
  • Recovery Level Objectives (RLO)
  • Hangi veri yedeklenebilir ?
  • Yedeklerin doğrulanması

Veri Tanımı

Bir şirketin veri tanımını ve amacını anlamak önemlidir. Bir şirket için SQL sunucular, Exchange sunucuları ve tutulan veriler işletme için çok kritik ve önemli verilerdir. Yedek yöneticisi olarak göreviniz şirket için çok önemlidir. Sizin göreviniz şirket verilerini onarmak, veri doğruluğunu sağlamak ve bu hizmetlerin sürekliliğini sağlamaktır.

SQL veritabanı bozuldu (corrupt) veya bir mailbox içerisinde bir öğe kayboldu ve kullandıkları hizmetler bu sebeplerden ötürü yanıt vermiyor, burada son kullanıcı yedekleme yöneticisi olarak sizinle iletişim kuracaktır. Sizin göreviniz sistemi eski haline getirerek işleyişi sağlamaktır. Son kullanıcılar SQL verilerinin nerede tutulduğunu veya son patchleri başarılı bir şekilde geçilip geçilmediğini düşünmezler. Bu gibi durumlarda geri yükleme stratejinizin içerisinde son kullanıcıların online destek alabilir olması iyi bir fikirdir.

Microsoft’ un Yaklaşımı

Hizmetlerinizin ve verilerinizin sınıflandırma işlemi Protection Grouplarınızın tasarımını etkileyecektir. Bu koruma gruplarını bir nevi yedekleme zamanlayıcısı olarak düşünebilirsiniz.

Microsoft’ un DPM’ in dağılım senaryoları için üç farklı yaklaşımı var, tabi ki bu yaklaşım sizin senaryolarınızda koruma gruplarınızın tasarımını etkileyecektir.

  • İlk yaklaşım, bir kaç sunucuya ve windows iş yükü az olan küçük işletmeler için düşünce bütün sunucular için bir koruma grubu oluşturulur ve hepsi için aynı yedekleme zamanı planı gerçekleştirilebilir. Bu yedeklemenin en hızlı yoludur , fakat fikiri kullanmayabilirsiniz. Burada önemli olan yedekleme zamanlarının ayrı olmasıdır, muhtemelen iş yüklerine veya veri tiplerine göre ayırmak sizin için okadar önemli değildir.
  • İkinci yaklaşım daha etkindir, burada sen her bir windows iş yükü ayrı koruma gurupları oluşturursun, ne demek oluyor bu SQL için bir koruma grubu, Domain Controller lar için bir koruma grubu, Exchange için ayrı bir koruma grubu gibi… Bu yaklaşım size iş yüklerine göre yedekleme zamanlayıcısı ve yedekler üzerinde daha çok kontrol edilebilirlik sunacaktır.
  • Üçüncü yaklaşım kurumsal bir yaklaşımdır, ve aslında düşünülmesi gereken yaklaşım budur. Bu yaklaşım, mevcut forest veya domain’ inizde ki hizmetlere ve verilere göre farklı sınıflandırmalar yapılarak RPO, RTO ve RLO değerleri göz önüne alınarak koruma grupları oluşturulur. Bu yaklaşım size veriler, yedekleme zamanlaması ve işlevleri üzerinde tam kontrol edilebilirlik sunacaktır.

Service Level Agreement (SLA)

Service Level Agreement (SLA) şirketin geri yükleme senaryoları için alınan stratejik seçimleri tanımlayan belgedir. Bir SLA tanımla süreci şirket içinde çeşitli strateji toplantıları ile birlikte zaman alıcı planlama, analiz ve çeşitli araştırmalar sonrasında tamamlanır.

SLA hizmet kalitesinin standartlarını oluştururarak ve müşterinin hizmet sağlayıcısın dan beklemesi gereken hizmeti belirler. Bu sayede destek veren kurum çalışanlarının bireysel ve organizasyon hizmet kalitesinin ölçülebilmesi ve yönetilebilmesi mümkün olur.

Satın alınan SLA anlaşması içerisinde hizmeti alacağı firmadan alacağı hizmetin seviyesini, önemi doğrultusunda kendisi belirler.

Aşağıdaki gibi farklı SLA sınıfları buna örnektir;

  • Platinum (Platin)
  • Gold (Altın)
  • Silver (Gümüş)
  • Bronze (Bronz)

Alınancak SLA hizmet seviyesinin önemine göre belirleyeceğiniz sınıflardır.

Recovery Point Objectives, Recovery Time Objectives ve Recovery Level Objectives

İlk planlama aşamasında, geri yükleme stratejisi işletmenin hizmetlerini ne kadar kısa bir sürede ve hızlı şekilde tekrardan çevirim içi olarak kullanınılabilir hale getirilebilirliğini belirler. Bir felaket durumunda veya büyük bir sorun ile karşılaşıldığında, işletmeden işleyişin durabileceği maksimum süre veya bu süre boyunca oluşabilecek veri kayıplarını tanımlayabilecek, bazı araçlar ve teknikler bulunmaktadır.

Bu durumlar için kulllandığınız araçlar Recovery Point Objective (RPO), Recovery Time Objective (RTO) ve Recovery Level Objective (RLO) değerlerinizi belirler.

İşletmeler için ilk geri yükleme stretejileri planlanırken şansa bırakılmaması gereken bazı noktalar bulunur. Başlangıç da iyi bir planlama stretejisi RPO, RTO ve RLO’ ya dayandırılmalıdır.

Recovery Point Objectives (RPO)

RPO felaket senaryolarında kullandığımız bir terimdir. Felaket anında riske edilebilen veri miktarını yansıtan birimdir.

Burada işletmeler için en önemlisi gerek duyulduğunda restorasyon işlemleri için yedekleme zamanlamasının olması önemlidir. DPM ile, bir koruma grubu oluşturma veya değiştirme işlemi sırasında ne sıklıkla kurtarma noktalarının oluşturulacağı belirlenmelidir.

Recovery Time Objectives (RTO)

RTO felaket anında down durumda olan sistemi hangi süre zarfında tekrardan çalışır hale getirileceğini belirten değerdir. RTO değerinde belirtilen bir ortalama değer yoktur. RTO değerinin belirlenmesi Exchange, SharePoint, SQL gibi diğer windows iş yükleri için farklı şekillerde belirtilir.

Burada ana düşünce planlanan RTO değerinin işletmenin gereksinimleri karşılayabiliyor olmasıdır.

Recovery Level Objectives (RLO)

RLO SharePoint, SharePoint Farm, Farmlar veya dosya sunucu verilerinin geri yükleme seviyesini tanımlar. SharePoint iş yükü için RPO ve RTO’ ya bağlı kalarak RLO değeri değişebilir.

Depending on the RPO and RTO for the SharePoint workload, the RLO may vary. You could have a RLO that states that company data must be restored at farm level for one kind of scenario and another RLO for individual items such as sites, lists or documents.

Hangi Veriler Yedeklenmelidir ?

İşletme için kritik değere sahip olan bütün veriler yedeklenmelidir. Yedekleme yönetici olarak göreviniz, şirket hizmetleri için kritik veya önemli olan iş yüklerini belirlemektir.

İlk olarak, şirket verilerini sınıflandırarak başlayabilirsiniz. Doğrusuda budur. Sınıflandırma, sizin restorayon planlamanızın veya SLA anlaşmanızın ilk yapı taşıdır. Gerçekleştirilen sınıflandırma işlemini doğru yapmak, production ortamlarında restorasyon senaryolarınız için daha etkili olacaktır.

Sunucu Teknolojileri

Hizmetleri temsil eden sunucu teknolojileri ile çalışmak oldukça zaman alıcı bir iştir, fakat harcadığınız zamana karşılık çıkan sonuç tatmin edici olacaktır. Bu çalışma size yardımcı olacaktır ;

  • Koruma gruplarının konfigüre edilmesi
  • Koruma gruplarının sayısı
  • Disk Havuzu için gereken boyut
  • Dağıtılması gereken DPM Ajanlarının sayısı
  • Dağıtılması gereken DPM Sunucu sayısı

İlk adım, koruma gruplarının yapılandırılmasıdır. Bir koruma grubunun ismi neyi koruduğuna dair anlaşılabilir bir bilgi vermelidir.Ayrıca yapılandırmanın nasıl yapıldığına dair ipucu sunmalıdır.

Koruma gruplarının nasıl tasarlanması gereketiğine dair iki farklı şekilde yaklaşılmalıdır ;

  • Windows İş yüklerine göre
  • Kurumsal yaklaşım

İş Yüküne Göre Protection Group Tasarlanması

Windows isyükü koruma grubu tasarimi, etki alaniniz ya da güvenilen etki alanlari icersinde varolan, Windows isyükü sunucularini yansitir.

Bu oldukça basittir; SQL, SharePont, domain controller, sistem sürücüler, lojik sürücüler ve buna benzer noktalar için ayrı ayrı birer koruma grubu oluşturun. Bunu yapmanın hiçde zor olmadığını göreceksiniz, Sadece windows iş yükleri için yedekleme zamanlamasını nasıl yapılandırdığınıza dikkat etmelisiniz.

Eğer aynı sunucu üzerinde birden fazla yedekleme işlemi gerçekleşiyorsa, sunucu yeterli performansı veya kaynağı vermeyecektir. Bunun için aynı sunucu üzerinde aynı anda birden fazla yedekle işlemi gerçekleştirmeyi istememelisiniz.

Enterprise Protection Group Tasarlanması

Enterprise koruma grubu tasarımı size korunan veriler üzerinde genel bir bilgi verecektir. Başlangıçta şirketiniz de farklı hizmetleri temsil eden iş yükleri için RPO ve RTO değerlerinin tanımlanması gerekir. SharePoint ortamlarınız için RLO değerini tanımlamayı unutmamalısınız.

Sınıflandırmanızı dört farklı kriter olarak belirlemelisiniz.

  • Platinum (Platin)
  • Gold (Altın)
  • Silver (Gümüş)
  • Bronze (Bronz)

Muhtemelen sonunda oluşturulan koruma gruplarının sayısı dörtten fazla olacaktır. Bu işletmeniz veya organizasyonunuzun verilerini ilk sınıflandırmadır, bu sınıflandırmalar hakkında bilgiye aşağıda daha ayrıntılı olarak görebilirsiniz.

Platin Sınıfı

Platin sınıfı, işletmenin en kritik verilerini veya servislerinin içerir. Bu hizmetlerin veya verilerin herhangi bir sebepten ötürü crash olması işletmenin iflasına bile sebep olabilir, bu gibi durumlara istinaden bir çok örnek bulabilirsiniz.

Bir şirketin Kurumsal Kaynak Planlama (ERP) sistemi genellikle bu sınıf içerisinde bulunur. ERP bir işletmenin kalbi sayılabilir, içerisinde kapsadı hizmetler CRM sistemi, Tedarik Zinciri Yönetimi (SCM), İnsan Kaynakları (İK) ve buna benzer hizmetleri içerir.

Bu sınıfa giren sistemler için RTO genellikle kabul edilebilir kesinti süresi bir saat veya da azdır. RPO değeri değişiklik gösterebilir fakat bu değer çok düşük ve neredeyse sıfır tolerasyon sağlanmalıdır.

Altın Sınıfı

Altın sınıfında, işletme için kritik veriler veya hizmetler bu sınıf içerisinde de bulunur fakat platin gruba dahil olan sistemler kadar çok kritik sayılmazlar.

Altın sınıfında, işletme için kritik veriler veya hizmetler bu sınıf içerisinde de bulunur fakat platin gruba dahil olan sistemler kadar çok kritik sayılmazlar. Bu sınıfta işletmenin sistem kaynakları için dosya paylaşımlarını veya işletme için kritik olan SQL sunucuların veri tabanlarını ve benzeri hizmetleri veya verileri içerir. Tabi ki Exchange iş yükünüzde bu grup içerisinde yer alır.

Bu sınıfa giren sistemler için kabul edilebilir RTO değeri iki saat olarak belirlenebilir.

Gümüş Sınıfı

Gümüş sınıfına giren sistemler Platin ve Altın grubuna giren sistemler kadar önemli olmasa da işletme hizmetleri için önemlidir.

Bu sınıf içerisine File Serverlarınız, sabit verileriniz veya veri tabanlarınız bulundurulur. Bu sınıf’ a üye olan sistemlerin herhangi bir sebepten ötürü kesintiye uğraması RTO değeri olarak kabul edilebilen kesinti dört saat olarak belirlenir.

Bronz Sınıfı

Bronz sınıfı, işletme için kritik olmayan hizmetleri temsil eder. Bu sınıfta bulunan hizmetler bizlerin tabiri ile işletme üzerinde kaybedilen hizmetin yöneticiler tarafından yeni bir sunucu üzerinde tekrardan hizmeti kurarak çalıştırabileceği sistemleri barındırdığımız sınıftır.

İlk Yaklaşım

Ortamınızı yedekleme sırasına gelindiğinde, sizin için kritik değere sahip olan mevcut sunucu platformlarınızı ve üzerindeki hizmetleri iyi anlamanız işletmeniz veya organizasyonunuz için önemlidir.

Windows Olmayan Uygulama Sunucuları

Bir çok ortamda, farklı sunucu teknolojileri çalışabilir tabi ki herzaman sunucularınızı yedeklemeyi gerçekleştirmek için bir yol olduğuna emin olabilirsiniz. Ama en önemlisi tam olarak desteklenen bir geri yükleme gerçekleştirebilmenin mümkün olmasıdır.

Genel Veri Kaynağı Koruma

Veri Kaynağı Koruma DPM 2012 ile birlikte gelen yeni bir özelliktir. Bu özellik windows uygulamalarını yedeklemede VSS teknolojisi ile güçlendirilmiştir. Bu, korumalı iş yüklerinin DPM tanımı içinde henüz tanımlanmamış Windows iş yükleri için farklı yedeklemeler oluşturabileceğin ve geri yükleme senaryolarını destekleyebileceğin anlamına gelir.

Yerel Hizmetler

Genel veri kaynağı koruma özelliği çalışmayabilir, her zaman yerel servislerinize güvenebilirsiniz. İlk tercihleri olarak SQL veya Exchange kullanmayan şirketler için diğer hizmetlerini DPM ile koruma altına alma imkânları vardır.

Örneğin Oracle’ ı ele alalım, Yöntemimiz Oracle veritabanları için DPM ajanı kurulu olan bir işletim sistemi tarafından yönetilen, NTFS sürücüsünü oracle veri tabanlarının yerel döküm alanı olarak uygulanır. DPM bu dökümleri toplar ve DPM sunucu üzerinde koruma altına almanıza olanak sağlar.

Windows İş Yükleri

Windows iş yükleri söz konusu olunca DPM ile her zaman tam olarak optimize edilmiş yedeklemeler, restorasyonlar ve desteklenen felaket kurtarma senaryolarına sahipsinizdir.

Windows iş yüklerinin yönetimi ve korunması söz konusu olduğunda ilk göreviniz Bare Metal Restore (BMR) yedeğinin alınarak veri doğruluğunun sağlanmasıdır. BMR fiziksel sunucular üzerindeki System State ve Sistem Sürücülerini yedekleyerek sonra farklı bir fiziksel sunucuya restore edebilmenizi sağlar. BMR bir felaket kurtarma (disaster recovery) fonksiyonudur.

BMR ayrıca Hyper-V ortamları üzerinde de uygulanabilmektedir. Buradaki fark BMR ile belirtilen Hyper-V sunucu üzerinde bulunan bütün sanal sunucularınızın koruma altına alınmasıdır, Buna Host seviyesinde yedekleme denir. Bu size ana host’ unuz veya kümeniz (cluster) herhangi bir durumdan dolayı çökerse (crash), size sanal sunucularınızı farklı bir Hyper-V host üzerine restore edebilme yeteneğini sunar.

ikincisi, Sanal sunucularınız üzerinde BMR yedeklemeye ek olarak yedeklemeler gerçekleştirecekseniz, DPM ajanını bu sanal sunuculara kurmanız gerekmektedir. Bu guest seviyesinde yedeklemedir. Bu sanal sunucular üzerine kurulan SQL veya SharePoint gibi hizmetlerin yedeklenebilir olduğu anlamına gelir.

Protection Group Adları

Dikkat etmeniz gereken ilk nokta oluşturduğunuz koruma gruplarının (protection groups) isimlerinin bir standartının olmasıdır. İşletme içerisinde gerçekleştirilen sınıflandırma RTO, RPO ve RLO değerlerini de yansıtmalıdır.

Eğer sahip olduğunuz bir koruma grubunun RTO değeri 4 saat, RPO değeri 1 saat ve senkronizasyon sıklığı 15 dakika gibi bir sınıflandırma bünyesinde ise bu koruma grubunun ismi “Kritik Veritabanları / RTO 4 saat / RPO 1 saat / Senk 15 dakika” gibi bilgileri içeren bir standartda hazırlanmalıdır.

Bu demek oluyor ki, bu grup’ un üyeleri için çalışır oldukları süre boyunca her saat başı bir kurtarma noktası (recovery point) oluşturulacak ve bu noktalar arasında değişenler blok seviyesinde (block-level) 15 dakikada bir senkronize edileceği anlamına gelir.

Farklı türde bulunan veri kaynaklarını bir koruma grubu üzerinde toplaya bilirsiniz, bunun bir önemi yok… Ama unutmayın ki bir veri kaynağı sadece bir koruma grubu içerisinde olabilir. İşte sınıflandırma çalışmalarımızdaki asıl fikir belirli gruplara üye olması gereken hizmetlere karar verebilmemizdir.

Protection Group Üyesi

Unutmamalısınız ki, organizasyonunuzdaki hizmetleri ve verilerin yedeklenmesi söz konusu olduğun da DPM işletim sistemi üzerindeki teknolojileri kullanır. Hizmetlerin bulunduğu disk veya lojik sürücüler mutlaka aktif olmalıdır.

SQL veritabanı yedeklemesini, farklı VSS yazıcılar sayesinde SQL veritabanının tutulduğu volume’u aynı anda yedekleyebilirsin. Gel gelelim, SQL veritabanın tutulacağı volume’ların asıl SQL verinle aynı RTO ve RPO değerlerini almayacağı için bu iyi bir yaklaşım değildir. Bilinmelidir ki SQL veritabanları fiziksel volume’ lerden daha yüksek bir önceliğe sahiptir.

Yedeklemelerinizin Doğrulanması

İşletmenizin verilerini ve servislerini sınıflandırdınız, koruma gruplarınızı tasarladınız ve çalışıyorsa artık son adıma geldiniz demektir. Şimdi servislerinizi ve verilerinizi artık restore edebilirsiniz…

DPM yöneticisi olarak gözardı etmemeniz gereken şey, yedeklenmiş olan veri veya servislerin veri bütünlüğünü doğrulamış olmanızdır. Bu Active Directory, Exchange veya buna benzer ortamlarınızı yaşayabileceğiniz olumsuz bir durumda artık rahatlıkla geri yükleyebilirsiniz demektir.

Geri Yükleme Eğitimi

İşletmenin servislerini veya verilerini restore etmeye sıra geldiğinde bu işleri yönetebileceğinize dair kendinize güvenmelisiniz. Farklı yükleme seçenekleri ile farklı windows uygulamalarının gerçekte geri yükleme işlemleri sırasında harcanacak sürenin nekadar olduğunu bilmeniz gerekmektedir.

Bunu bilmenizin en iyi yolu, laboratuvar ortamlarında farklı geri yükleme senaryolarını gerçekleştirmenizdir.

Doğrulama İşlemi

Deneyiminizi arttırmak için farklı Windows uygulamalarını restore ederek kendinizi geliştirmelisiniz. Veri bütünlüğün doğrulanması bu işin en önemli aşamasıdır. DPM yöneticisi olarak yedeklediğiniz SharePoint veya SQL veri tabanlarını, SharePoint veya Database yöneticileri ile alınan yedeklerin geri yüklenebilir (restorable) olduğunu kontrol edin.

Diğer yöneticiler size DPM ile yedeklenen verilere ihtiyaçları olduğunu belirtebilirler, siz diğer yöneticilere bu yedeklerin alternatif lokasyonlara restore edebilmeleri için yetki verebilirsiniz. Böylelikle alınana yedeklerinde veri bütünlüğünü doğrulanmasını sağlayabilirsiniz.