Verilerin başına bir şeylerin gelmeye başladığı anı felaket (Disaster) anı olarak
isimlendiriyoruz. Bu anı yaşama ihtimalini en aza indirmek için alınacak önlemlere ise yüksek erişilebilirlik (High
Availability) çözümleri denmekte. Bu kapsamdaki çözümler AlwaysOn (Failover
Cluster - Availability Group), Mirroring, Log Shipping ve belki Replicationdır.
Eğer felaket anı yaşanmışsa yapılacak çok fazla şey yok demektir. Bu durumda
işimize yarayacak şeyler; yedeklerimiz (backup),
veritabanının anlık görüntüleri (snapshop)
ve/veya veritabanın önceden bir yere ayrılmış data ve log dosyalarıdır.
Felaket sonrasına hazır olmak her veritabanı yöneticisinin
boynunun borcudur. Yedekleme planı
hassasiyetle belirlenmeli ve belli aralıklarla gözden geçirilmelidir. Yedekler lokal olmayan birkaç farklı noktaya
dağıtılmalı ve güvenliği
sağlanmalıdır. Bu güvenlik hem veriye istenmeyen kişilerin erişimi ile ilgili
hem de fiziksel anlamda verilerin sağlığı ile ilgilidir. Ayrıca yedeklerin daha az yer kaplaması için veri
sıkıştırma çözümleri göz ardı edilmemelidir. Neyse ki SQL Server 2008’den beri backup
compression, SQL Server 2005’den
beri encryption direk
desteklenmektedir.
Birçok veritabanı yöneticisi bu yedekleme mevzusuna oldukça
dikkat etmekte, hatta bu dikkatleri yüzünden yedekten dönme (restore) senaryolarını göz ardı edebilmektedir. Yedekleme
ne kadar önemliyse bu yedeklerin kullanılabiliyor olması da o bir kadar önemli.
Bu kapsamda belirli aralıklarla felaket
tatbikatları yapılmalı ve bu esnası karşılaşılan problemler not
edilmelidir. Ancak bu şekilde ortaya çıkarılan aksiyon planları sayesinde gerçek felaket anında soğukkanlılıkla
gerekenler yapılabilir.
Yedekleme üzerine söylenebilecek bir çok söz var. Biz bu yazımızda lokal olmayan farklı ortamlara yedek alma konusunu
gündemimize alarak yedeklerin Windows
Azure Storagelerine nasıl gönderilebileceğini inceleyeceğiz.
SQL Server 2012 SP1
CU2 ve SQL Server 2014 ile
birlikte URL backup özelliği
sayesinde Azure disklerine yani buluta yedekler alınabilmektedir. Ayrıca yeni gelen
Backup Encryption özelliği ile tek
başına yedekler şifrelenebilmektedir. Bu sayede yedekleri korumak için TDE yöntemi ile şifreleme yapmayarak SQL
Serverı gereksiz CPU yükünden kurtarmış oluruz.
SQL Server 2014 ile buluta nasıl yedek alınabileceğini şu
yazımızda açıklamıştık:
Yeni versiyonlarda bu özellikler mevcut ve kullanılabilir
durumda. Peki ya önceki versiyonlar?
Microsoft SQL Server
Backup to Windows Azure Tool (bundan sonra Backup to Azure diyelim) sayesinde SQL 2005, 2008, 2008 R2 ve 2012 versiyonlarında aldığınız yedekleri
buluta otomatik olarak gönderebilir, bu yedekleri bulutta sıkıştırıp şifreli
olarak tutabilirsiniz. Ya da bu özellikleri sadece lokalinizde
kullanabilirsiniz.
Backup to Azure aracı SQL
Server 2005 ve sonraki yedekleriniz için çalışır. Windows Server 2008 ve sonraki server
işletim sistemlerinde, Windows 7 ve
sonraki client işletim sistemlerinde kullanılabilir.
Backup to Azure aracını “Microsoft Download Center” dan ücretsiz
olarak indirebilirsiniz.
Birkaç adımda kurulum tamamlandıktan sonra bilgisayarımızda
şu bileşenler kurulmuş olur:
- Microsoft SQL Server Backup to Windows Azure Tool servisi.-
- BackupToAzure grubu ve SQLBackup2Azure kullanıcısı
Nasıl yapılıyor?
Eğer buluta yedek alacaksak öncelikle Windows Azure üzerinde
bir storage oluşturmalıyız. Storage /
Create Storage Account seçenekleri ile aşağıdaki şekilde disyedek isimli bir account
oluşturabiliriz. Burada iş yükünün konumlanacağı bölgeyi ve storagein nasıl
yedekleneceğini de belirtiyoruz.
Yedeklerimizi Storage içerisindeki Containerlarda (disk sisteminde klasöre tekabül eder) tutabiliriz.
Bu sebeple yeni bir container oluşturmamız ve erişim seviyesini belirtmemiz
gerekir. Biz de yedekler-2005-2012
adındaki containerı aşağıdaki şekilde oluşturuyoruz.
disyedekler isimli
Stroge account ve yedekler-2005-2012
isimli container hazır. Şimdi sıra geldi Backup to Azure aracımızda gereken
ayarları yapmaya.
Aracı açtıktan sonra Add
butonunu kullanarak yedekleme kuralları
(Rule) tanımlamamız gerekiyor. İlk adımda yedek alacağımız klasörü ve işleyeceğimiz yedek dosyalarının isim paternini belirtiyoruz.
İkinci adımda yedeği buluta
mı göndereceğimizi yoksa tercih edeceğimiz şifreleme ve sıkıştırma özelliğini sadece
lokalde mi yapacağımızı belirtiyoruz.
İlk seçenek seçilirse istenen özellikler
yedeklere olduğu yerde uygulanır. İkinci seçenek seçilirse istenen özellikler uygulanır ve yedekler
buluta taşınır. Yedek aldığımız klasörde ise içerisinde sadece metadata bilgisi bulunan yedekle aynı isimde bir dosya bırakılır.
Biz azure storage seçeneği ile ilerliyoruz ve yukarıdaki
gereken bilgileri aşağıdaki azure ekranından temin ediyoruz. Bu ekrana
oluşturduğumuz azure diski seçiliyken aşağıdaki şeritte bulunan MANAGE ACCESS KEYS butonu ile ulaşıyoruz.
Stroage Account
ve Containerı doğruladıktan sonra
bir sonraki adıma geçip yedeklerimize uygulamak istediğimiz özellikleri
belirtiyoruz.
Biz bu çalışmamızda bir şifre girerek Encryption özelliğini ve yedeği sıkıştırmak için Compression özelliğini aktif ettik.
Finish diyerek sonraki adıma geçebilir tüm tanımlı kuralları görüp üzerinde
değişiklikler yapabilirsiniz.
Bu tanımlamayı yaptık sonra uygulamanın açık kalmasına gerek
yok. Ancak servisin açık olduğundan
emin olmamız gerekir. Tanımladığımız bu kural belirttiğimiz yedek klasöründe BackupToAzure grubuna özel izin verdi.
Bu iznin de varlığından emin olmamız
gerekir.
Örneğimde metadata
dosyasına dikkat çekmek için iki yedek alacağım. Bunlardan birisini araç ile takip etmediğim bir yere yani C:\AzureYedekler klasörüne şu script
yardımıyla alıyorum:
-- sıkıştırmadan lokale yedek alalım
BACKUP DATABASE
[Veritabani_2005-2012]
TO DISK = N'C:\AzureYedekler\Veritabani_2005-2012.bak'
Bu şekilde aldığım yedeğin boyutu 8MB ve içerisinde beklenildiği üzere gerçekten veri mevcut.
İkinci yedeğimi Backup to Azure aracı ile takip ettiğim yere
yani C:\AzureYedekler\2005_2012
klasörüne benzer şekilde alıyorum:
--sıkıştırarak Backup2Azure aracının
takip ettiği yere yedek alalım
BACKUP DATABASE
[Veritabani_2005-2012]
TO DISK = N'C:\AzureYedekler\2005_2012\Veritabani_2005-2012.bak'
Bu sefer yedek dosyası 23KB
olarak görünüyor. İşte bu dosya içerisinde veri değil işlenen yedeğe
ulaşabilmeyle alakalı bilgiler tutulmaktadır. Dosyayı açtığımızda aşağıdaki
şekilde başlayan metadataya
erişebilirsiniz.
Bulutta ise iki dosya oluşmaktadır.
Bunlardan sonu enc ile biten
içerisinde gerçekten veri bulunurken diğerinde ise yine metadata yer almaktadır.
İlk yedekten bu yana yapılan tüm işlemlere Azure Storage Explorer
aracını da dâhil ederek bakarsak aşağıdaki gibi bir ekranla karşılaşmış oluruz.
Azure disklerini neredeyse lokal diskleriniz kadar rahat
kullanmak istiyorsanız Azure Storage
Explorer aracını aşağıdaki adresten indirip kurmanızı öneririm. Bu araç
Azure Storageler ile ilgili çeşitli konularda işinizi kolaylaştıracak ücretsiz bir
araçtır.
Yedekleri aldık. Peki,
yedekten dönme işlemini nasıl yapacağız?
Bunun için ekstra bir çalışma yapmaya gerek yok. Yedek
aldığımız klasördeki metadata dosyasında
tüm bilgiler mevcut. Tek yapmamız gereken aşağıdaki şekilde bu dosyanın
yolunu belirtmek:
--yedekten dönmek için konfigurasyon
dosyasını kullanıyoruz.
USE [master]
RESTORE DATABASE
[Veritabani_2005-2012]
FROM DISK = N'C:\AzureYedekler\2005_2012\Veritabani_2005-2012.bak'
WITH REPLACE
Eğer yedek aldığınız klasördeki metadata dosyası kaybolursa Azure storagedeki metadata dosyasını
aynı klasöre indirerek yedeği kullanabilirsiniz. Eğer klasör silindiyse o zaman
Backup to Azure aracını kullanarak önceki ile aynı özellikte bir kural
oluşturup metadata dosyasını bu klasöre indirebilirsiniz.
Microsoft Backup to Windows Azure aracı SQL Server 2014
versiyonunda kullanılabilen URL Backup
ile buluta yedek alabilme, Backup Encryption
ve SQL Server 2008 ile birlikte gelen Compression
özelliklerini SQL Server 2005 ve sonraki
versiyonlardan alınan yedekler için de mümkün kılıyor. Kullanımı oldukça basit;
kuralları tanımla ve servisi açık tut.
Bu konu ilginizi çektiyse “SQL Server 2014 Yenilikleri - 1 (Hybrid Cloud)” adındaki yazımıza da
bir göz atmak isteyebilirsiniz.
