Bir süre önce Microsoft Türkiye'den Osman Çokakoğlu ile görüştük. Sağolsun benim Bizspark programına dahil olmamı sağladı. Böylece Azure'u rahat rahat kurcalayabilmem için gerekli zemin de hazır olmuş oldu. Eğer 5 yaşını geçmemiş bir Startup'ınız varsa, Azure ile yazılım geliştiriyorsanız ve güzel projeleriniz varsa Osman ile iletişim kurmanızı tavsiye ederim.
Bu kapsamda bir süre önce bazı testlere başladım. SQL Server 2014 test ortamlarımım da Managed Backup'ı test ettim.
Öncelikle belirtmeliyim ki bu yazıdaki maksadım özelliğin baştan sona nasıl kurulacağını ve özelliğin ayrıntılı nasıl çalıştığını anlatmak değil, fakat testler sırasında karşılaştığım bir durumdan bahsetmek.
Efendim Managed Backup özelliği SQL Server 2014 ile birlikte geldi ve SQL Server Management Studio'yu açtıktan sonra ilgili SQL Server Instance'ınıza bağlanıp, Object Explorer'daki Management altında bulabilirsiniz bu özelliği.
Peki bu özellik ne işe yarar? Bu özellik, yedekleme ve stratejileriyle uğraşmak istemeyen ve yedeklerinin buluttaki (Azure) bir alanda barındırılmasını isteyenler için kullanılabilir. Yedekleme için herhangi bir zamanlama vs belirtmiyorsunuz. SQL Server belli kriterlere göre kendi uygun gördüğü zamanlarda Full Database ve Transaction Log yedeklerini kendi alıp Azure'daki belirteceğiniz Storage alanına sıkıştırarak kopyalıyor. Özelliği kullanabilmeniz için ilgili yerel SQL Server Instance'ınızda Azure hesabınıza erişim için bir Credential oluşturuyorsunuz, Storage adresinizi yazıyorsunuz ve tabii ki ilgili Azure hesabınızda, bu yerel ağınız için güven duvarı tanımlarını yapıyorsunuz, sonra özellik kullanıma hazır.
Tüm bu yazıyı yazmamdaki tek neden ise şu. Bu testi yaptığım makine bir sanal makine ve kendi dizüstü bilgisayarımda bulunuyor bu sanal makine. Yani zaman zaman dizüstü bilgisayarımı çat diye kapattığımda, test ortamı olarak kullandığım sanal makine de çat diye dondurulmuş oluyor. İnternet bağlantısı çat diye gidiyor. O sırada örneğin Azure'daki Storage alanıma bir yedek dosyası kopyalıyorsa, o da yarım kalıyor. Peki o zaman ne oluyor? İşte bugün o zaman ne olduğunu öğrendim.
Bugün ilgili test ortamımdaki Azure Storage Explorer'ı bir açtım, bir de ne göreyim!
Sıkıştırılmamış hali 300MB olan veritabanımın yedeği 1TB görünüyor! Bu nasıl olabilir diye düşündüm, taşındım, mantıklı bir neden bulamadım. Acaba bu test veritabanında bir işlem yapmıştım da veritabanının boyu ben farkında olmadan artmış mıydı? Aklıma ilk gelen bu oldu, ama baktım hayır, hala 300MB. Ayrıca 1TB'lık yedeklerden sonra da yine (sıkıştırıldığı için) 48,56MB'lık yedek alındığını ekran görüntüsünden siz de görebilirsiniz.
Bu duruma anlam veremediğim için arkadaşlara danıştım ve sağolsun Denny Cherry gayet akla yatkın bir yanıt verdi. Buraya kadar gelinceye dek test ortamımın özelliklerinden bahsetmemin bir nedeni vardı tabii ki, Denny'nin cevabının altyapısını oluşturmak. Efendim şimdi SQL Server, Azure Storage'a yedek alırken (henüz iç işleyişini bilmiyorum) yedek almaya başlıyor (muhtemelen Streaming şeklinde) ve eğer bu işlemi sağlıklı bir şekilde tamamlayamazsa, o zaman Azure dosyayı varsayılan bir boyut ile kapatmak zorunda kalıyor. Yani bu 1TB'lık dosyalar aslında Corrupt, tamamlanamamış yedekler. Bu 1TB da bu BLOB alanda oluşturulabilecek azami dosya boyutu. Sonuç olarak tüm bunlardan anladığım kadarıyla eğer yedek kopyalanması sırasında bu işlem başarıyla tamamlanamazsa, Azure bu dosyayı 1TB olarak kapatıyor. Haberiniz olsun!
Sevgiler,
Ekrem Önsoy
Hiç yorum yok:
Yorum Gönder