SCDPM Online Protection ve Azure Backup Pratikleri

Geçen hafta Azure Backup servisini ele alan, nedir, nasıl yapılır gibi kavramsal ve operasyonel konularda yardımcı olabilecek birkaç yazı yayımlamıştım. Konu konuyu açtı ve aşağıda listelediğim ufak seriye dönüştü. Şimdi ise sırada en eğlenceli bölüm var: Gerçek hayattan Azure Backup ve DPM Pratikleri!

Pek belli etmiyor olabilirim ama yıllardır DPM ve son birkaç yıldır da Azure Backup ile çalışıyorum. Danışmanlık hizmeti verdiğimiz birçok müşterimizde DPM + Azure Backup entegrasyonu çalıştırıyoruz ve aynı zamanda yönetiyoruz. Özellikle Hyper-V ortamlarını, dosya sunucularını ve SQL Instance/DB’leri yedeklerken başarılı buluyoruz. Geçen sene bu konuda bir sunum yapmıştım. Hatta bu senenin başlarında Microsoft Virtual Academy için hazırladığım eğitim modüllerinden birisi de Azure Backup’la ilgiliydi.

Bu yazıyı blog üzerinde alışık olduğunuz çerçeveden farklı olarak ve birbirleriyle doğrudan ilişkili olmayan ufak kesitler (maddeler de diyebiliriz) şeklinde hazırlamak istedim çünkü notlarımı aktarmanın en kolay yolu buydu. Ve sanırım zamanla yeni maddeler ekleyerek geliştirmek daha kolay olacak. Hadi başlayalım.

DPM Online Protection ve Azure Backup Pratikleri

Azure Backup servisini Windows Client, Windows Server ve System Center Data Protection Manager ürünleriyle entegre ederek kullanabiliyorsunuz. Ayrıca Azure IaaS VM’leri de yedekleyebiliyor. Yapı içerisindeki on-side servis bileşenlerinden olan Azure Backup Agent (Azure Recovery Services Agent), sunucular üzerinden aldığı verileri Azure Storage tabanlı Backup Vault’lara transfer ediyor ve belirlediğiniz sürelerde saklanıyor. Azure Backup şimdilik farklı yedekleme yazılımlarıyla birlikte çalışamıyor ama yakın zamanda böyle şeyler de göreceksiniz. Azure Backup ekosisteminin genişletilmesiyle ilgili çalışmalar yürüdüğünü biliyorum.

*

Azure Backup’ın service-side bileşenlerinden olan Backup Vault’lar yine service-side’da Azure Storage tabanlı olarak çalışıyor. Bu yüzden hizmet ücretlendirilirken, servisten faydalanma bedeline ek olarak depolama maliyetleri Azure Storage rakamları üzerinden yansıtılıyor. Azure Storage tarafında LRS veya GRS türde depolama alanlarını Azure Backup Vault’lar için kullanabiliyorsunuz.

*

Azure Backup servisi sistem/uygulama yedeklemek için değil “veri” yedeklemek içindir. Azure Backup Agent’ın şu haliyle yaptığı iş sadece sunucu disklerinden dosyaları okumak ve transfer etmek. Herhangi bir uygulamayla doğrudan entegre olamıyor.

*

Azure Backup’ı ana yedekleme sisteminizin yerine değil yanına konumlandırmalısınız. Gün içerisinde yaşanabilecek veri kayıplarını hızlıca kurtarmak için yerel bir yedekleme çözümüne sahip olmak her zaman iyidir. Azure Backup’ı mevcut yedekleme çözümüne entegre bir tesis dışı yedekleme ortamı olarak konumlandırmalısınız; Gerçek bir felaket durumuna karşı tüm kritik verilerin depolandığı güvenli bir lokasyon.

*

Azure Backup servisine dahil olan tüm sistemler üzerine Azure Backup Agent (Azure Recovery Services Agent) isimli bir aracı uygulama yüklenir. Bu uygulama aslında bir Windows Server Backup (cbengine.exe) varyasyonudur. Ancak çalışabilmesi için sunucu üzerinde Windows Server Backup feature’un yüklü olması gerekmez veya aynı anda hem Windows Server Backup hem de Azure Backup Agent yüklü olabilir.

*

DPM Server üzerine Azure Backup Agent yüklendiğinde, Azure Backup Agent’ın MMC tabanlı kullanıcı ara yüzü çalışmaz. Bu durumda Backup Vault’a kayıt veya diğer yapılandırma işlemlerinin tamamı DPM Administrator Console > Management > Online bölümünden gerçekleştirilir.

azure-backup-dpm-pratikleri-1

*

DPM ortamında Azure Backup servisiyle ilişkilendirilen yedekleme yöntemi Online Protection olarak anılır.

*

Online Protection ile Azure Backup’a transfer edilecek DPM data source’ların (VM gibi, SQL DB gibi) boyutu 1.65TB’tan büyük olamaz. Ayrıca Online Protection için desteklenen ve desteklenmeyen dosya türleri ve davranış şöyle:

Desteklenenler

  • Encrypted (sadece Full yedekleme)
  • Compressed (Incremental yedekleme desteklenir)
  • Sparse (Incremental yedekleme desteklenir)
  • Compressed and sparse (Sparse olarak Treated)

Desteklenmeyenler

  • Servers on case-sensitive file systems aren’t supported.
  • Hard links (Skipped)
  • Reparse points (Skipped)
  • Encrypted and compressed (Skipped)
  • Encrypted and sparse (Skipped)
  • Compressed stream
  • Sparse stream

*

Azure Backup Agent’ın DPM Server ile entegre olduğu senaryolarda yedekleme davranışı şöyledir: DPM Server kendi agent’ları üzerinden ulaştığı sunucuları (protected servers) belirlediğiniz Protection Group kurallarına göre disk tabanlı olarak yedekler. Azure Backup Agent ise zaten DPM Server tarafından alınmış olan yedekleri doğrudan DPM Server’ın disklerinden okur ve Azure Backup Vault üzerine transfer eder. Azure Backup Agent, DPM tarafından korunan sunucular üzerinde herhangi bir operasyon yürütmez; yedekleme kaynağı doğrudan DPM Server’ın yerel diskleridir.

*

DPM Online Protection görevlerini disk tabanlı yedeklemenin arkasından çalışacak şekilde zamanlamaya dikkat edin. Aksi durumda Azure Backup Agent transfer edilecek değişiklik bulamayabilir, 1 saat sonra tekrar dener ve yine uygun veri yoksa bir sonraki çalışma zamanına kadar bekler. Mesela bir dosya sunucunuz olduğunu ve DPM Server tarafından her gün saat 20:00’da disk tabanlı olarak yedeklendiğini düşünün. Eğer bu dosya sunucusu için Online Protection’ı saat 18:00’a koyarsanız, DPM disk’lerine alınan günlük yedek en erken bir gün sonra Azure Backup Vault’a ulaşır. Çünkü Azure Backup Agent çalışma anında dosya sunucusu üzerinden yeni bir yedek almaz, transfer etmek için DPM’in almış olduğu yedek içeriğine bakar.

*

Bir Online Protection görevinin çalışma zamanı geldiğinde ilgili Job tetiklenir ama mesela DPM Server diskleri üzerinde transfer edilecek değişen veri tespit edilemezse Job fail eder. Ardından o Protection Group için aşağıdaki critical hata oluşur. Sonra her seferinde gidip Inactivate Allert falan demeniz gerekir.

DPM skipped cloud backup for Volume D:\ on fs-05.inprowise.com because the latest disk backup is already backed up to cloud. (ID 33344)

Bu durumun nedeni ise DPM Server tarafından alınan son yedeğin zaten Azure Backup Agent tarafından Backup Vault’a gönderilmiş olması ve bu süre zarfında DPM Server tarafından yeni bir yedek alınmamış olmasıdır. Çalışma zamanı gelen Azure Backup Agent da gönderilecek “değişen veri” bulamayınca basıyor hatayı. Yahu madem buraya kadar tespit edebiliyorsun neden bunu Failed ile sonlandırıp gereksiz heyecan yaratıyorsun öyle değil mi? Mesela bir Warning yapsan (ki bence bu olayın hakkı Information’dır o ayrı) fena mı olur?

*

Azure Backup Agent’ın teker teker korunan sunuculara gidip yedek almak yerine zaten DPM Server tarafından yerel disklere alınmış içeriği kullanıyor olması, hem korunan sunucular üzerinde ikinci bir yedekleme operasyonunun yürümesini engelliyor, hem de ağ üzerinde oluşacak gereksiz bir trafiği ortadan kaldırıyor. Bu gibi şeyler geniş ölçekli yapılarda oldukça önemli olabiliyor.

*

Disk tabanlı koruma için ayarladığınız Protection Group’lar içerisinde aynı zamanda Online Protection yani Azure Backup’a gönderim politikalarını da belirleyebilir ve kendi özelinde yapılandırabilirsiniz. Mesela bir PG ile her gün saat 20:00’da 5 adet Hyper-V VM’i disk tabanlı olarak yedeklediğinizi düşünün. Aynı PG içerisinde Online Protection’ı aktif edip aralarından sadece 3 adet VM’i haftanın belirli günleri 22:00’da Azure Backup’a transfer edebilir, retention policy’i disk tabanlı korumadan bağımsız bir şekilde yönetebilirsiniz.

azure-backup-dpm-pratikleri-2

*

Bir Protection Group için Online Protection’ı ilk kez aktifleştirdiğinizde tüm veri bir kez Azure Backup Vault’a transfer edilir. Daha sonra ise sadece değişen veriler gönderilir. Azure Backup Agent, DPM Server disklerindeki değişen verileri takip etmek için kurulum sırasında belirttiğiniz Cache Location dizinini kullanır. Bu yüzden Cache Location dizininin Online Protection ile yedeklenen toplam veri boyutunun en az %5’i kadar boş alana sahip olması gerekir. Mesela senaryo gereği Azure Backup servisine yazan Online Protection görevleri toplamda 1TB kadar veri depoluyor olsun. Bu durumda Cache Location’ın en az 10GB (ki daha fazla gerekecek) boş alana sahip bir volume üzerinde konumlandırılması gerekir. Bu değer, değişiklik sıklığına ve değişen verinin boyutuna göre farklılık gösterdiği için ortama göre bir süre takip etmenizi veya peşin peşin ve geniş geniş boş alan tahsis etmenizi öneririm.

*

DPM tarafından yedeklenen Hyper-V sunucuları, VM’leri, Windows Server tabanlı dosya sunucularını, Disk Volume’ları, SQL Server Instance/DB’leri, Exchange Server DB’leri ve Sharepoint Server sunucularına ait verileri saklanmak ve gerektiğinde geri döndürmek üzere Azure Backup servisine gönderebilirsiniz.

*

Bir Protection Group üzerinde Online Protection için retention range’i değiştirirseniz (modify), o Protection Group ile Azure Backup’a yazılmış ve yeni retention range dışında kalan veriler Backup Vault içerisinden silinir. Artık o tarihleri Recovery Point olarak kullanamazsınız.

*

DPM Server configuration DB’yi de (DPMDB) bir kenara yedeklemeyi unutmayın. Azure Backup’a yedeklemek iyi bir fikirdir ama bence bu ortamlar dışında (ve gerektiğinde erişebileceğiniz) üçüncü bir ortama daha DPM Server SQL DB yedeği çıkartmanızı öneririm. Periyodik ve otomatik olursa güzel olur.

*

Mesela 100GB kapasiteli bir Hyper-V VM’i DPM Server üzerinden Online Protection ile koruma altına aldınız. İlk anda Azure Backup Vault’a doğru 100GB boyutlu tam bir transfer gerçekleşir. Sonraki zamanlarda ise sadece değişen veriler transfer edilir; 2GB, 3GB, 5GB, vs.. Ama bir gün VM’in VHD’sini bir miktar genişletmeniz gerekir veya ne bileyim VHD içerisinde blok seviyesinde önemli değişikliğe neden olan bir işlem tetiklenir, işte o gün tüm VM’in (yani en az 100GB’ın) tekrar Azure Backup Vault’a transfer edilmesi gerekebilir. Transfer işlemi otomatik olarak yürür ama ne fayda…

*

Mesela 1TB kapasiteli ve yaklaşık 2.500.000+ adet dosyaya sahip doküman sunucusunu Online Protection ile Azure Backup servisine yedeklemek mi istiyorsunuz? O zaman size kolay gelsin :)

Dosya sayısının fazla olmasından mütevellit Azure Backup Agent’ın DPM Server disklerinden her bir dosyayı teker teker okuması, parça parça sıkıştırarak kendi Cache Location’ı üzerine yazması ve daha sonra Azure Backup Vault’a transfer etmesi günler sürebilir. Bu durum daha çok disk hızına ve dosya sayısına (+boyutuna) bağlıdır ama kısmen bant genişliğinin de olaya olumsuz katkısı olabilir. İlk transfer tamamlandıktan sonraki değişenlerin algılanması ve transfer edilmesi ise ayrı bir hikaye, hiç girmiyorum.

Neyse hadi bir şekilde yaptınız diyelim ve ilk transfer 1-2 gün içerisinde tamamlandı. Ardından değişenler günlük olarak gönderiliyor ve nispeten daha kısa sürüyor. Sonra bir gün ekip arkadaşlarınızdan biri (belki de siz) mesela gidip doküman hiyerarşisinin tepesinde bir ACL değiştirdi ve bu değişiklik aşağıya doğru yayıldı… Oldu o zaman, ben burada ayrılıyorum siz devam edin :)

Bu davranış tüm dosyalarda değişiklik olarak algılanacağından içeriğin tamamı yeniden okunur ve neredeyse en baştan transfer edilir. +2 gün yaz sen ona :)

Bir de ilk transferi takip eden sonraki transferlerin devam edememesi durumu var ki geçen ay bu konuda bir bug keşfettik ve raporladık, sonra kapatıldığını öğrendik.


Özellikle çok sayıda dosyanın yer aldığı sunucuları yedeklemek, yerel disk veya kuruluş içi yedekleme sistemi olsa dahi her zaman problem olmuştur. DPM Online Protection tarafı için ise 2 kez dikkatli olun.

*

Azure Backup servisini Disaster Recovery çözümünün bir parçası olarak konumlandırdık ya, peki gerçek bir Disaster yaşanırsa ve ana lokasyondaki tüm sunucular (yerel DPM Server dahil) kısa sürede ayağa kaldırılamayacak şekilde devre dışı kalırsa? Kurtarma süreci için nasıl bir yol izlemeli? Mesela Azure Backup üzerinde saklanan yedekleri uygun bir lokasyona dönmek ve orada sistemleri yeniden inşa etmek güzel bir fikir olabilir. Ama keşke bu kadar kolay olsa.

Öncelikle şunun altını çizelim: Disaster Recovery planları sadece verileri dış lokasyona çıkartmak suretiyle işletilemez. Gerçek bir Disaster Recovery hazırlığı için sunucu ve uygulama altyapısının belirli parçalarının güvenli lokasyonlarda (ve hızlıca devreye girebilecek şekilde) hazır bekletilmesi, kritik sistemler için native ha servislerinin devreye alınması, storage veya vm seviyesinde gerçekleştirilecek replikasyonlar, gerektiğinde kullanılmak üzere hazır bekletilen donanım yatırımları gibi daha birçok konunun ele alınması gerekir.

Ama senaryo gereği küçük veya orta ölçekli bir işletme olarak tek güvencemiz Azure Backup, eğer buradaki verileri uygun bir lokasyona (kurtarma lokasyonu diyelim) dönebilirsek orada hazır beklettiğimiz birkaç sanal makine var (kurtarma sunucuları diyelim) ve verilerin güncel halini üzerine alarak servislerimizi başlatacağız. Gayet yaygın bir senaryo öyle değil mi?

Bu durumda iki seçeneğiniz var.

1) Kurtarma lokasyonunda yeni bir DPM Server kurup Azure Backup üzerindeki yedeklere (Online Recovery Point’ler) ulaşmayı deneyebilirsiniz.

DPM Server’ın başına bir şey gelme ihtimaline karşı (ve tabi Azure Backup servisindeki yedekleri kurtarmak için) mevcut DPM DB yedeğini kullanarak farklı bir ortamda yeni bir DPM Server inşa edip Azure Backup’a entegre etme denemelerimin tamamında başarısız oldum. Ha böyle bir yöntem var mıydı ondan da emin değilim. Çünkü Online Recovery Point’leri farklı bir ortamdaki yeni bir DPM Server üzerinde dönebilmek için;

  • DPM Server, Active Directory bağımlıdır ve yeni bir ortamda öncelikle aynı (veya en azından aynı isimli) Forest/Domian’i ayağa kaldırmanız gerekir.
  • Arkasından aynı hostname’e ve System Center sürümüne sahip (ki UR sürümüne kadar aynı olmalı) bir DPM Server ve SQL Server kurmanız ve ayağa kaldırmanız gerekir. Mesela Disaster yaşandığında DPM’in hangi sürümde ve hangi Update Rollup seviyesinde çalıştığını hatırlayabilecek misiniz? Veya bu gibi bilgileri dokümante edip kritik zamanlarda doğru kişiler tarafından ulaşılabilecek noktalarda bulunduruyor musunuz?
  • Daha sonra DPM DB’yi belirli prosedürler çerçevesinde restore etmeniz gerekir. Umarım DPM DB yedeğini de Azure Backup içerisine koymadınız? Çünkü henüz oraya ulaşamıyorsunuz :)
  • Eğer bu adıma kadar gelebilirseniz şimdi Azure Backup Vault’a register etmeniz gerekir.
  • Eğer işler yolunda gitmişse Online Recovery Point’leri konsolda görebilir(miş)siniz.

Dedim ya ben bu adımları birçok kez tamamladım, ama hiçbir zaman mutlu sona ulaşamadım. Bence o Online Recovery Point’ler sadece geceleri görünüyor :)

2) Ben size daha kolay ve çalışan bir yöntem göstereceğim: Kurtarma lokasyonunda yeni bir Windows Server kurup Azure Backup üzerindeki yedeklere ulaşmayı deneyebilirsiniz. Şanslısınız çünkü Azure Backup’a kayıt edilen bir Windows Server, o Backup Vault içerisine eski DPM tarafından yazılmış verileri görebilir ve gerektiğinde geri dönebilir. Her ne kadar DPM aksini iddia etse de:

azure-backup-scdpm

Siz ona bakmayın ve beni takip edin…

Alternatif sunucuya kurtarma yöntemini daha önce yazmıştım. Çalışıyor ancak önemli problemleri var ve DPM yedeklerini geri dönmek üzere optimize edilmediği çok açık. Ama sonuç olarak Azure Backup Vault’a bağlanabiliyor ve içeriği browse edip recover edebiliyor; Bu açıdan baktığımızda “desteklemiyor” da diyemiyoruz. Arada kalmış.

Bu yöntemde, Azure Backup Agent tarafından sağlan MMC UI’ı kullanmak veya yine aynı yolla sağlanan Azure Recovery Services Shell’i kullanmak gibi iki alt seçeneğiniz var.

MMC UI’ı kullanarak ilerlediğinizde aşağıdaki gibi bir pencerede kurtarılacak yedek kaynağını seçmeniz isteniyor. Sizce hangi satır DPM Server tarafından alınmış hangi yedeğe denk geliyor? Bulmaca gibi.

azure-backup-alternatif-sunucuya-kuratma-4

Rasgele bir tane seçip birkaç adım ilerledikten sonra içeriği browse ederek dizinleri görüp hangi sisteme ait olduğunu anlamak mümkün olabilir belki ama bu sadece Dosya/Klasör yedekleri için geçerli. Çünkü VM, SQL, Exchange gibi yedeklerin içeriğini bu yöntemle browse edemiyorsunuz. Dahası gerçek hayat senaryosunda bu listede 10’larca kayıt olacak, uğraşılacak iş değil.

Bu şekilde olmasının nedeni ise özetle şöyle: Azure Backup Agent ile sağlanan MMC UI’in Windows Server Backup tabanlı olması ve Windows Server Backup’ın da DPM Server’ın anladığı Data Source’ları ve MountPointPath’leri anlayamaması, daha doğrusu anlamak üzere uyarlanmamış olması. Zaten dikkat ederseniz “Select the volume” diyor yani orada D:\ E:\ gibi bir takım sürücü harflerini görmek istiyor.

İkinci seçenek Azure Recovery Shell kullanarak ilerlediğinizde ise ayrı bir karmaşa söz konusu. Array içinde array, MountPointPath’ler, Friendly denenen ama hiçte öyle olmayan isimlendirmeler… Mesela bağlandın ve geri dönülebilecek kaynakları listeledin, sence bunlardan hangisi KurtarBeni isimli DB’e ait? :)

azure-backup-recovery-1

Bunlar aslında DPM’in anlayabildiği MountPointPath’lerdir ve DPM üzerindeki Data Source’lar ile eşleşirler. Ama şu an ortada bir DPM olmadığı için ve elinizde önceden hazırlanmış bir eşleşme listesi de yoksa yandınız, sihirli küreyi ovuşturmaktan veya hislerinize güvenmekten başka seçeneğiniz yok. Bu yüzden hazırlıklı olmanız lazım. Ancak bu seçeneğin çalıştığından emin olabilir ve hazırlıklarınızı baştan yaptığınız taktirde güvenle kullanabilirsiniz. Tecrübeyle sabit.

*

Azure Backup Agent kurulumu sırasında belirlenen Passphrase’i sakın kaybetmeyin ve gerektiğinde ulaşabileceğiniz güvenli bir yerde saklayın. Genelde lazım olduğu an en stresli andır. Aynı şekilde Azure aboneliğinizi yönet hesap bilgileri de gerektiğinde ulaşılabilir olsun.

*

DPM’in kendi disk yapısı üzerinde yer alan yedek dizinleri (MountPointPath) çok derin olabiliyor. Mesela bir VM yedeği için şunun gibi:

C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\Volumes\Replica\Microsoft Hyper-V VSS Writer\vol_a1248dd2-4048-4797-957f-4b8792e5216c\001eef2e-0923-4423-84a4-e643a70ca184\Full\C-Vol\ClusterStorage\Volume2\VMs\PROXY1\…

Azure Backup Agent bu veriyi DPM disklerinden okurken sanki bir folder’ı yedekliyormuş gibi davranıyor ve Online Protection sırasında tüm hiyerarşik yapı koruyarak Azure Backup’a taşıyor. Sonra ne mi oluyor? Yedeği bir Windows Server üzerine dönüyorsunuz, haliyle oluşan dizin yapısı yine aynı derinlikte oluyor (hatta daha bile derin) ve en alttaki veri dosyalarına ulaştığınızda işletim sistemi dosyaların bozuk olduğunu söylüyor… Baksana Properties falan bile ortada yok.

azure-backup-recovery-2

Çünkü recover edilen path Windows Server için fazla uzun… Belirli yerlerden cut/copy/paste falan yapıp hiyerarşiyi kısalttıktan sonra veriye ulaşabiliyorsunuz. Mükemmel teknoloji.

*

I love DPM, ama daha iyi olabilir.

Yazı Etiketleri: , , , , ,

Sayfa Başı ▲

Yorum Ekle