Yedekleme stratejisi oluşturmadan önce sorulması gereken sorulardan en önemlisi; “Veritabanında bulunan veriler ne kadar sıkılıkla güncelleniyor?” sorusudur.

Uygun bir plan oluşturmak amacıyla üretilecek sorular elbette çeşitlendirilebilir ancak soruların içeriği veritabanı ve ilgili verilerin taşıdığı önemi, son yedeklemeden sonra ne miktarda veri kaybına tahammül edilebileceği ve ya veritabanının büyüklüğünü hedef alarak sorgulayacak ise artık günümüzde geliştirilen uygulamaların içerik olarak zenginliği, işlem hacmi, firma için taşıdıkları değer ve herhangi bir veri kaybı durumunda yaşanılacak zaman ve emek kaybı düne göre fazla olduğu için eskiden olduğu kadar yedekleme öncesinde uzun uzadıya tartışmaya değer konular olduğunu sanmıyorum. Çünkü aslında yukarıdaki soruya verilecek cevap bir bakıma yedekleme planını ortaya koymak için minör kriterlerleri sorgulayacak olan diğer tüm soruların da yanıtını içerisinde barındırıyor olacaktır. Özellikle de OLTP (Online Transaction Processing) tipinde veritabanları için.

OLTP, birçok kullanıcı tarafından sürekli ve eşzamanlı olarak veri girişi, verilere anlık erişim ve veri değiş-tokuşu gerektiren işlem (transaction) odaklı uygulamalar tarafından kullanılan veritabanı türüdür. B2B ve B2C olmak üzere tüm e-ticaret sistemleri, online internet bankacılığı, havayolu ve ya turizm portalları gibi ödeme işlemleri, stok bilgisi değiş tokuşu, online rezervasyon gibi  anlık verilerin işlendiği tüm uygulama altyapılarının kullanmak durumunda olduğu teknolojidir. Etkinliği ve ilgili iş modelleri için sayısız kolaylıklar sağlıyor olmasına rağmen çevrimdışı (offline) modellemeler ile kıyaslandığında direk saldırı ve tacize açık olması sebebiyle en düşündürücü dezavantajı bu veritabanı türünün güvenlik ve stabilitesi ile ilgili hassasiyetidir. Bundan dolayıdır ki OLTP veritabanına dayalı iş modeline sahip girişimlerin tüm operasyonları, online işlem tabanlı (transcation-based) sistemlere ilişkin verilerde bozulma ve kayıplar, bağımlı olunan işletim sistemi ve ya platformda meydana gelebilecek beklenmedik arızalar, ağ ve ilgili ekipmanlarda oluşabilecek problemler nedeniyle çok çabuk ve çok ciddi miktarda etkilenecek, hatta söz konusu işin tamamiyle durması söz konusu olacaktır. Bu sebeple katı bir yedekleme stratejisi dahilinde düzenli ve sıklıkla yedeklenmelidirler. İşte bu, yazımızın başında sorduğumuz soru için özellikle OLTP sistemlere yönelik olarak verilmesi gereken ilk ve en önemli yanıttır. Gerisi sahip olduğunuz donanımlar, disk alanları ve 3. parti bir yazılım yatırımı için finansman gücü gibi konular çevresinde ne kadar risk alabileceğiniz ile ilgilidir.

Yedekleme stratejisi belirleme ve bu doğrultuda bir an önce harekete geçmek aslında kolay bir konu olmasına rağmen belkide en çok ihmal edilen ve ya oluşturulurken en çok yanlış yapılan süreçlerden bir tanesidir. Bu uygulamada, bir üretim sunucusunda bulunan farklı uygulamalara ilişkin OLTP veritabanlarını yedeklemek için nasıl bir yol izlenebileceğini adım adım ve mümkün olduğunca detaylı ele alıyor olacağız. Alacağınız yedekleri sadece sunucu üzerinde bulundurma riskine girmek yerine yedeklerizi aynı ve ya uzak bir lokasyondaki farklı bir sunucuda (offsite) düzenli olarak depolamak, yönetmek ve raporlamasının yapılmasını sağlamak üzere merkezi bir yedekleme çözümü arayışındaysanız FreeBSD Üzerinde Rsync İle Otomatik Yedekleme ve Senkronizasyon Çözümü başlıklı proje makalem ilginizi çekebilir.

Sürekli olarak erişilen ve güncellenen OLTP veritabanları için sadece düzenli olarak full backup alınması kafi değildir. Eğer full backup ile yetinilirse son yedekleme sonrasında gerçekleşmiş tüm işlemlerin tekrar girilmesi gerekecektir ki işlem yoğunluğu bulunan ve birden fazla uygulamanın birbiriyle etkileşerek aynı veritabanlarını güncellediği profesyonel altyapılarda bu neredeyse imkansızdır. Full, Differential ve Transaction Log yedeklemeleri kombinasyonu iyi bir çözüm olacaktır. Bu yedekleme tiplerine kısaca değinelim;

Full backup: Veritabanının bütünüyle kopyasını tek bir yedekleme dosyasına alır. Yedekleme stratejisine neredeyse her zaman full backup ile başlangıç yapılır diyebiliriz.

Differential backup: Son full backup gerçekleştiği andan itibaren değişen verilerin yedeğini alır. Bu nedenle gerçekleştirilebilmesi için önce full backup alınmış olması gerekir. Genel olarak full yedeklerden daha küçük olacakları ve daha az sürede ve süratli alınabildikleri için full yedekleme sonrasında periodik olarak çalıştırmaya yöneliktirler.

Transaction Log backup: Son transaction log yedeğinin alındığı andan itibaren veritabanında gerçekleşen tüm işlemlerin (transactions) yedeğini alır. Transaction Log yedeğinin alınabilmesi için önce bir full yedek alınmış olması gereklidir. Transactin Log yedekleri veritabanı işlemlerine ilişkin zaman içerisinde dönülebilecek bir nokta sunuyor olacaktır. Bu özellikle hatalı ve ya problem teşkil eden veri giriş çıkışlarına yönelik anlık geri dönülebilirlik imkanı sunar.

Uygulamamızda da kullanacağımız Transaction Log yedeklemesi, herhangi bir veritabanı için ancak Full Recovery Model etkinleştirildiğinde mümkün olabilir. Aksi taktirde Simple Recovery Model ile Transaction Log yedeklemesi yapılamaz. Bu kurtarma modellerine kısaca değinelim;

Simple Recovery Model: Bu model her zaman transaction loglarınızı keser (truncate eder) ve üstlenilmiş işlemleri (commited transactions) sürekli olarak siler. Bu sebeple bu model ile transcation log yedeklemesi yapmak mümkün değildir. Sadece Full ve Differential yedekler alabilirsiniz. Bu nedenle söz konusu model OLTP veritabanları için oluşturulacak stratejiler için uygun değildir.

Full Recovery Model: SELECT INTO, CREATE INDEX gibi tüm işlem yığınları ve geçmişleri bütünüyle kaydedilir ve loglanır. Transaction log yedeklemesi yapılabilir, bu sayede spesifik bir hata anına ve ya zaman içerisinde herhangi bir noktaya geri dönülebilir. Yönetimsel ve alan kullanımı açısından sisteme ek yük getiriyor olsa da veri güvenliği ve kurtarma operasyonları için en güvenli modeldir.

Uygulamamızı veritabanlarınız üzerinde gerçekleştirecekseniz Full Recovery Model’e geçmelisiniz. Ek olarak henüz gerçekleştirmediyseniz ve imkanınız varsa sunucunuzu service pack 1 ve ya üstüne güncellemenizi tavsiye ederim.

Pratikte görelim;

1. SQL Server Management Studio’yu açalım. Management -> Maintenance Plan (sağ tuş) -> Maintenance Plan Wizard’ı çalıştıralım.

2. İlk olarak oluşturacağımız FULL backup için uygun bir isim belirleyerek girin, arzu ederseniz description kısmına açıklayıcı bir tanımlama da ekleyebilirsiniz.

3. Yedeği alınacak olan veritabanlarında yer alan tüm objelere ilişkin yerleşimi (allocation) ve yapısal bütünlüğü (structural integrity) denetleyecek olan Check Database Integrity görevini ve yedekleme işlemini gerçekleştirecek olan Back Up Database (Full) görevini işaretleyerek devam edin.

Görev sıralamasını belirleyeceğimiz ekranda varsayılan sıralamayı değiştirmeden devam edelim.

Check Integrity ön göreviyle yedekleme öncesinde denetlemenin yedeği alınmak üzere seçilecek ilgili hangi kullanıcı veritabanları için gerçekleşeceğini belirtin.

Bir sonraki adımda yine Databases: kısmında bu kez yedekleme işleminin gerçekleştirileceği kullanıcı veritabanlarını belirtmek üzere seçimimizi yapıyor ve örneğimizde kullanmakta olduğumuz APPLICATIONX, DEPOT ve ICODE kullanıcı veritabanlarını tekrar seçiyoruz.

“Define Back Up Database (Full) Task” ekranında veritabanı seçimlerimizi tamamladığımızda aktif hale dönüşecek olan yedekleme özelliklerini düzenleyin. Destination, “Back up to: Disk” seçeneği ile yedeklerimizi disk üzerine almak istediğimizi, “Create a backup file for every database” seçeneği ile her bir veritabanı için ayrı ayrı yedekleme dosyası yaratılacağını ifade ediyoruz. “Create a sub-directory for each database” seçeneği ile her bir veritabanı için ayrı ayrı alt klasörler oluşturulacağını belirterek altında bulunan “Folder:” alanında bu alt klasörlerin hangi klasör altında bulunacaklarını tayin ediyoruz. Sadece Full yedekleriniz için yaratacağınız “F:\BACKUP\AUTOCURRENT\FULL” şeklinde yolu bu alana girin. Yedeklerin sistem bölümlemesinde değil F:\ gibi bağımsız bir bölümleme ve ya disk alanında bulunmasına özen gösterin. FULL klasörü altında yedeklenmesi için seçtiğimiz APPLICATIONX, DEPOT ve ICODE veritabanları için aynı isimde alt klasörler yaratılacaktır. “Backup file extension” seçeneğiyle belirleyebileceğimiz “bak” yedekleme uzantısını, özel farklı bir seçimimiz yok ise varsayılan şekilde bırakıp son olarak “Verify backup integrity” seçeneği ile yedeklerimizin alındıktan sonra bütünlüğünün kontrol edilmesini sağlıyoruz.

Bir sonraki adımda karşılaşacağımız “Select Plan Properties” ekranında “Change” butonunu kullanarak Full yedek planımızın düzenli olarak yürütülebilmesi için zaman programlaması gerçekleştireceğiz.

Örneğimize istinaden APPLICATIONX_DEPOT_ICODE_FULL_EveryNight şeklinde belirleyici bir ifadeyle isimlendirdiğimiz zaman programlamanızı (New Job Schedule) sürekli olarak tekrarlanacak (Recurring) şekilde düzenlemelisiniz. Full yedeklemeye dahil ettiğiniz farklı veritabanlarının ebatları sebebiyle yedeklemenin totalde alacağı zamanı göz önünde bulundurarak normal veritabanı işlemlerinin nispeten en az yoğun olacağını düşündüğünüz saatler için örneğin geceyarısı 03:30 için aşağıda gösterildiği şekilde programlama yapabilirsiniz. Bu şekilde Full yedekleme günde sadece 1 kez geceyarısı saat 03:30′da devreye girecektir. (Occurs: Daily, Recurs every: 1 day, Occurs once at: 03:30, No End Date)

“Select Report Options” ekranında Full yedeklememize ilişkin raporun text dosyasına yazılarak yedeklerimizle aynı klasör içerisinde yani \FULL klasörü altında saklanacağını belirtiyoruz. Bu sayede yedeklerimizi komple bir başka lokasyona aktardığımızda yedekleme planı işlemleri için çalıştırılmış  T-SQL script detayları da dahil olmak üzere tüm raporlama bilgilerinin gerektiğinde incelenmek üzere yedeklerle birlikte aktarılmasını sağlamış olacağız.

“Complete the Wizard” ekranında planınızı oluştururken belirlediğiniz kriterlere son bir kez göz atıp, Finish butonuyla planı devreye alabiliriz. Bunu yaptığımızda planınızın Maintenance Plans altında ve ilgili görevin (Job) ise SQL Server Agent | Jobs altında “MaintenancePlanFULL” ismiyle oluşturulduğunu göreceksiniz.

Dikkat ederseniz yedeklemek üzere veritabanlarımızı belirlerken sistem veritabanları olan master, model ve msdb veritabanlarını seçimimize dahil etmedik. Tıpkı kullanıcı veritabanları gibi yedeklerinin alınması gereken bu veritabanları, kullanıcı veritabanları ile karıştırılmayıp ayrı bir plan dahilinde yedeklenmeleri daha mantıklı olacağı için ayrıca ele alacağız. Bu şekilde kullanıcı veritabanlarından bağımsız olarak sistem veritabanları için farklı zamanlama programlamasına sahip bir plan geliştirmemiz gerekirse özgür hareket edebileceğiz. Özellikle donanım arızaları gibi sistemin baştan kurulmasını gerektirecek durumlarda önem taşıyan sistem veritabanları içerisinde SQL sunucusu her başlatılışında yeni baştan yaratılan tempdb’nin ise yedeklenmesine gerek bulunmamaktadır. Ayrıca SQL sunucusu durdurulduğunda içerisindeki veriler temizlendiği için sadece SQL sunucusunun kullanımına tahsis edilmesi gereken tempdb veritabanında uygulamalarınıza yönelik hiçbir verinin saklanmaması gerektiğini unutmamalısınız.

Şimdi sistem veritabanlarımız için de bir plan oluşturarak devam edeceğiz.

master veritabanı için differential ve transaction log yedeklemeleri mümkün olmayıp, sadece full yedekleme yapılabileceği için sistem veritabanları için de tıpkı kullanıcı veritabanları için gerçekleştirdiğimiz gibi ayrıca bir full yedekleme planı hazırlamalıyız. Bunun için farklı bir isimle, örneğin “MaintenancePlanSYSFULL” ismini kullanarak kullanıcı veritabanlarında takip ettiğimiz yolu takip etmeniz kafi olacaktır. Check Database Integrity ve Back Up Database (Full) Task gibi veritabanı seçimi yapmanız gereken ekranlarda ise manüel olarak sadece master, model ve msdb veritabanlarını ya da kısaca “All system databases (master, msdb, model)” opsiyonunu seçmelisiniz. Depolama ve raporlama için dizin belirtmeniz gerektiğinde ise yine kullanıcı veritabanlarınızı yedeklerken kullandığınız “F:\BACKUP\AUTOCURRENT\FULL” yolunu kullanmanız, full yedeklerin topluca aynı dizinde bulunmasını sağlamak adına yararlı olacaktır.

Sistem veritabanlarına ilişkin full yedekleme zamanını, kullanıcı veritabanlarının full yedeklenmesinden 1 saat öncesine yani her gün saat 02:30′a programlayabilirsiniz.

Bu şekilde stratejimizin başlangıç adımını oluşturan FULL yedekleme kısmını tamamlamış oluyoruz. Stratejimizi geliştirmek ve olası bir felaket karşısında gerçekleştirilecek kurtarma operasyonunda geri yükleme sürecini kısaltmak amacıyla şimdi planımıza DIFFERENTIAL yedekleme eklemeliyiz. Bunun için Maintenance Plan Sihirbaz’ında “MaintenancePlanDIFF” ismini vereceğimiz yeni bir plan oluşturmaya başlamalı ve ilgili görevleri aşağıdaki gibi işaretlemeliyiz.

Hem “Define Database Check Integrity Task” hem de “Define Back Up Database (Differential) Task” bölümlerinde, kontrolü ve yedeklemesi gerçekleştirilecek veritabanlarını belirlerken full yedekleme planını oluşturduğumuz veritabanlarının aynılarını, yani örneğimizde APPLICATIONX, DEPOT ve ICODE kullanıcı veritabanlarını seçerek yapılandırmamıza devam ediyoruz. Yedekleme seçeneklerinde farklı olarak “Folder:” alanında Differential yedekleriniz için yaratacağınız “F:\BACKUP\AUTOCURRENT\DIFF” klasörünü gösterin. Böylece herbir kullanıcı veritabanı yedeğine ilişkin otomatik olarak yaratılacak ve differential yedek dosyalarını barındıracak olan tüm alt klasörler DIFF klasörü altında toplanacaklardır.

Söz konusu differential yedeklerin alınma zamanını gün ortasına, muhtemelen veritabanı işlemlerinin nispeten daha az yoğun olabileceği bir saate, örneğin öğle tatili saatine ayarlayın. Hergün aynı saatte, 12:30′da tekrarlanacak şekilde yapılandıracağınız New Job Schedule ismine “APPLICATIONX_DEPOT_ICODE_DIFF_MidDay” gibi belirleyici bir isim verebilirsiniz.

Select Report Options ekranında full yedekleme planında olduğu gibi raporlama dosyalarının ilgili yedeklerle aynı klasörde bulunmasını sağlamak için “F:\BACKUP\AUTOCURRENT\DIFF” dizinini kullanarak differential yedekleme planınızı devreye alabilirsiniz.

Şimdi yedekleme stratejimizin en önemli parçalarından bir tanesi olan ve kurtarma durumunda veri kaybını minimize etmemizi sağlayacak TRANSACTION LOG yedeklemesi ile mevcut planımızı pekiştirmeliyiz. Yine sihirbaz yardımıyla yeni bir plan oluşturarak “MaintenancePlanTRN” ismini verin ve görevleri işaretleyin.

Yedekleme seçeneklerinde, yedeklerini almakta olduğumuz APPLICATIONX, DEPOT VE ICODE kullanıcı veritabanlarına ilişkin Transaction Log yedeklerinin ve raporlamalarının depolanacağı “F:\BACKUP\AUTOCURRENT\TRN” dizinini yaratarak Folder alanına girin ve devam edin. Bu kez yedekleme dosyalarımızın uzantısı “trn” olacak, varsayılan bu değeri değiştirmenize gerek bulunmamakta.

Son olarak transaction log yedeklerinizin her gün saat 04:00 itibariyle başlayarak 04:00 – 03:29 saatleri arasındaki dilimde her 1 saatte bir, yani full ve differential yedeklemeler için daha önce belirlemiş olduğumuz buçuklu saatlerle mümkün olduğunca çakışmayacak şekilde alınmasını sağlamak amacıyla aşağıdaki gibi zaman programlaması gerçekleştirin ve “APPLICATIONX_DEPOT_ICODE_TRN_1Hour” ismiyle kaydederek ilerleyin, raporlama dizinini “F:\BACKUP\AUTOCURRENT\TRN” olarak belirterek planı sonlandırın.

Yedekleme stratejimizi neredeyse tamamladık sayılır. Ayrı ayrı oluşturduğumuz FULL, SYSFULL, DIFFERENTIAL ve TRANSACTION LOG yedekleme planlarını Management -> Maintenance Plans altında, bu planların herbirine ilişkin otomatik olarak yaratılan görevleri ise SQL Server Agent -> Jobs altında görebilirsiniz. Dilerseniz Maintenance Plans altında planlarınıza çift tıklayarak yeniden düzenleyebilir ve ya SQL Server Agent Jobs altında bulunan Job Activity Montior’ü kullanarak görev özelliklerini, planlarınızın yürütülmesine ilişkin detaylı geçmişi inceleyebilirsiniz. Stop/Start manüplasyonları gerçekleştirebilir, görevi devre dışı bırakabilirsiniz. İlgili planı Management -> Maintenance Plans altından sildiğinizde SQL Server Agent -> Jobs altında söz konusu plana karşılık gelen görevin de otomatik olarak silineceğini hatırlatmak isterim.

Uygulamamızda biz geceyarısı alınan 1 adet Full, gün ortası alınan 1 adet Differential ve saat başı alınan Transaction Log yedeklemesi kullandık. Sizler, veritabanını kullanan uygulamanızın türünü, veritabanlarını barındıran sunucunuzun ve veritabanlarınızdaki işlem yoğunluğunuzu göz önünde bulundurarak daha sıkı ve ya esnek farklı planlar oluşturabilirsiniz. Örneğin geri yükleme süresi uzunluğu ve veri kaybı miktarına tahammülsüz hassas bir uygulama için günde 4 kez 6 saate bir alınacak Differential ve yarım saatte bir alınacak Transaction Log yedekleri kombinasyonu içeren bir strateji tercih edebilirsiniz.

Planlarınızı oluşturduktan sonra çalışıp çalışmadıklarını kontrol etmek isterseniz manüel çalıştırarak deneyebilir, sonuç raporunu inceleyebilirsiniz.

Kontrolünüz sonucunda herhangi bir hata mesajı ile karşılaşmadığınız taktirde belirtmiş olduğunuz dizinlerde yedeklerinize ilişkin ilgili alt klasörlerin oluşturulduğunu, yedek ve raporlama dosyalarının bu klasörlere yerleştirildiğini görebiliyor olmanız gerekir.

Son olarak yedekleriniz planlarınız dahilinde alınmaya başlandığında bir süre sonra ilgili alt klasörler altında birikmeye başlayacaklardır. Belirli bir süreden daha eski yedekler otomatik olarak silinmezse diski tamamen dolduracaklar ve özellikle eğer veritabanları da yedeklerle aynı disk ve ya dilimde yer alıyorlarsa bu durum SQL sunucusu için ciddi bir tehdit haline gelecektir. Konuyu çözmek için SQL sunucusu tarafında Maintenance Cleanup Task aracına başvurulabilir. Ancak söz konusu araç, Maintenance Plan Sihirbazı dahilinde karşımıza çıkan “Clean Up History” göreviyle sürekli olarak birbiriyle karıştırılmaktadır. Oysa ikisi aynı şey değiller. Maintenance Cleanup Task, belirteceğiniz klasörler altında bulunan belirli bir süreden eski yedekleme (bak) ve raporlama (txt) dosyalarını silebilmekteyken, Clean Up History sadece yedekleme ve kurtarma geçmişini, SQL Server Agent görev geçmişini ve Maintenance Plan işlemlerine ilişkin geçmişi silebilir.

Maintenance Cleanup Task, Microsoft SQL Server Management Studio içerisinde bulunan menülerden View -> Toolbox tıklanarak açılacak olan pencere  içerisinde yer alır. Toolbox içerisinde ki Maintenance Cleanup Task aracını, daha önce oluşturmuş olduğunuz planlardan istediğiniz herhangi bir tanesini örneğin MaintenancePlanDIFF’i çift tıklayarak açacağınız [Design] penceresi içerisine sürükleyerek bırakmalısınız. Design bölümündeki mevcut görev objelerinden asıl yedeklemeyi yapan Back Up Database görev penceresine tıkladığınızda belirecek yeşil bağlantı (connection) okunu altına bırakmış olduğunuz Maintenance Cleanup Task penceresine bağlayınız. Bu işlem ile ana yedekleme bileşeninin çıkışını (output), eski yedek ve raporlama dosyalarını silecek olan Maintenance Clean Up Task bileşeninin girişine (input) bağlayarak sıralamada yedekleme bittikten sonra eski dosyaların temizlenmesi işleminin başlamasını sağlamış olacaksınız. Fakat öncesinde Maintenance Clean Up Task bileşenini yapılandırmanız gerekli.

Maintenance Cleanup Task ekranında Connection menüsünün yanındaki “New…” butonuyla yeni bir bağlantı arayüzü açın. “Connection name:” alanına uygun bir isim girerek “Select or enter a server name:” alanında sunucunuzu listeden seçin ve ya direk olarak sunucu ismini yazın. Kimlik doğrulama bilgilerinizi seçerek yeni bağlantıyı oluşturun.

“Delete files of the following type:” kısmında Backup files seçeneği ile yedek dosyalarını, Maintenance Plan text reports seçeneği ile raporlama dosylarının silinmesini sağlayabilirsiniz. “Search folder and delete files based on an extension” kısmında uzantı türüne dayalı olarak dosyaların bulunması ve silinmesini sağlayacağımız için “Folder:” alanına yedek dosyalarının bulunduğu ilgili dizini ve altındaki “File extension:” bölümüne ise plan oluştururken kullandığımız uzantı ismini giriyoruz. Uzantı isminin önüne (.) koymadan girmeliyiz. En alt satırda “Delete files older than the following:” kısmında ne kadar süreden eski olan dosyaların silinmesi gerektiği koşulunu belirliyoruz.

Yapılandırmamızı tamamladığınızda [Design] sayfasında, MaintenancePlanDIFF[Design]* başlığı üzerinde sağ tıklayıp çalışmanızı kaydetmeyi unutmayın.

Özellikle MS SQL için sp1 ve üstü service pack kurulumu yapmamış okurlarımızın Cleanup Task ayarlarında alt klasörler arası geçiş özelliği seçeneği (Include first-level subfolders) bulunmayacağı için yedek dosyalarının bulunduğu alt klasörlerin herbiri için ayrı ayrı task oluşturmak ve dizin belirtmek zorunluluğu doğacağı için SQL sunucusu tarafında böyle bir çözümün ne kadar efektif olacağı tartışılır. Üstelik sadece yedekleme dosyaları için değil, raporlama dosyaları için de ilgili dizinleri içeren görevler oluşturmak zorunda kalınacaktır. Diğer taraftan service pack geçmiş kullanıcıların dahi planlarında sürüm ve yapılandırma farklılıkları sebebiyle Cleanup Task uygulamasının beklendiği gibi çalışmadığına ilişkin bildirimler alıyorum. Bu durumda alternatif fakat daha pratik bir yöntemi kullanmak isteyebilirsiniz. İşte önerim;

Sunucu üzerinde clean.bat ismiyle aşağıdaki batch dosyasını oluşturun ve Planlanmış Görevler (Scheduled Tasks) altına kaydederek günde bir kez çalıştırılmasını sağlayın. Yedeklerinizin bulunduğu ana dizini ve süreyi belirterek tek bir hamleyle planlarınızın tamamına yönelik yedekleme ve raporlama dosyalarını periyodik olarak sildirebilirsiniz.

@ECHO OFF
FORFILES /P F:\BACKUP\AUTOCURRENT\ /S /M *.* /D -14 /C "CMD /C DEL @FILE"
exit

Şu ana kadar örneklerimizde tüm yedekleri depolamak için neden direk olarak F:\BACKUP dizinini değilde AUTOCURRENT isimli bir alt klasör kullanmış olduğumuzu ve planlama aşamasında neden israrla raporlama dosyalarını yedeklerin ilgili klasörleri içerisine kaydettirdiğimizi merak etmiş olabilirsiniz. Bunu, yerel MS SQL veritabanı yedeklerini ve raporlarını, rsync ile bir başka sunucuya göndererek o sunucuda depolamak, yönetmek ve düzenli raporlanmasını sağlamak konusunda yayımladığım proje makalemde yer alan örnek kodlara zemin teşkil edebilmesi için bu şekilde gerçekleştirdim. AUTOCURRENT klasörü, rsync projemizde kodlar içerisinde bu tip yedekleri topluca transfer edebilmek için kullanılan örnek bir klasör ismidir. Sizler elbette bir rsync uygulaması gerçekleştirmeyecekseniz farklı dizin ve klasör isimleri kullanabilirsiniz.

İlgili Makaleler

  İlgili makale bulunamadı.