23 Haziran 2017 Cuma

Yine, gene ve tekrar: Bir felaket hikayesi (veri kaybı) daha...

Ne kadar yazarsak yazalım (yazı, yazı, yazı) sonuçta yazdıklarımız, konuştuklarımız belli bir kitleye ulaşabiliyor.

Dün akşam bir tekstil firmasından aradılar ve teknik işlere bakan arkadaş telefonda şöyle dedi: 

"Bir veritabanı sunucumuz var ve bunun diskleri aslında yedekli, ama bu disklerden biri hata verdi ve yedek diskten veritabanı dosyalarını ve yedek dosyalarını kurtardık; ama bir türlü Attach edemiyoruz."

Sorunun yaşandığı SQL Server sunucusuna uzaktan bağlandım ve veritabanı dosyalarını ve yedek dosyalarını kontrol ettim.

Veritabanı dosyalarını Attach etmeye çalıştığımda bütünlük/IO tutarlılığı hatası alındığını gördüm. Bu etapta hata 9 sayılı Page'te alınıyordu. Bu da Boot Page demek. Bu noktada yedek dosyalarını düşündüm, fakat onların bütünlük kontrollerini yaptığımda veritabanı yedek dosyalarının bozulmuş olduğunu gördüm.

Veritabanlarının 6 ay önceki çalışan hallerinin sağlam kopyaları da ayrıca vardı. Sorun Boot Page'te olduğu için, eski veritabanlarından Boot Page'leri bu sorun yaşanan veritabanlarına aktarabilirdim. Bunu yaptım. Fakat gördüm ki tek sorun Boot Page'te değil. Boot Page'i onardıktan sonra da farklı farklı Page'lerde sorun yaşandığını gördüm. Sonraki kontrollerimde 3. Page'ten 36. Page'e kadar verilerin veritabanı dosyalarından komple silinmiş olduklarını gördüm.

Bu noktada artık şahsen benim yapabileceğim bir şey kalmadı. Kendilerine veri kurtarma konusunda çalışabilecekleri bir firma aramalarını önerdim. Ne kadar başarılı bir sonuç alınabilir, emin değilim; ama maalesef bu noktada artık görüşmeyi sonlandırdık.

Benim başıma gelmez demeyin, gerekli önlemleri almazsanız herkesin başına gelebilir bu durum. Geçen hafta sağlık bakımı çalışması yaptığım çok önemli bir veritabanı sunucusunda 2 aydır yedek alınmadığını tespit edip ilgili yöneticilere bildirdiğimde şok oldular.

Veritabanı dosyalarınızı ve aldığınız yedekleri aynı sunucu üstünde tutsanız bile en azından aynı disk altyapısında tutmayın. Mümkünse muhakkak yedeklerinizi uzaktaki, ayrı bir sunucuda düzenli ve güncel olarak barındırın. Kaybetmeye tahammülünüz olabilecek veri miktarını ve azami olarak ne kadar sürede geri dönmeniz gerektiğini önceden belirleyin ve yedekleme stratejinizi buna göre oluşturun. Yedekleme "kısmet" kategorisine girmeyecek kadar önemli bir konu. Yukarıda bahsettiğim tekstil firması muhtemelen son 6 aylık verisini kaybetti. Şirket bununla nasıl başa çıkacak bilemiyorum, ama umarım çok büyük kayıp yaşamazlar. Başkalarının hatalarından ders alarak kazanılan tecrübe, en ucuz ve acısız kazanılan tecrübedir, unutmayın.

Kazasız, belasız güzel günler dilerim.

Ekrem Önsoy
Microsoft SQL Server Danışmanı

6 Haziran 2017 Salı

Veritabanlarıyla rus ruleti oynamak

Yedeklemenin önemi ile ilgili (Bağlantı1, Bağlantı2) birçok yazı yazmama karşın maalesef sahada bu konuda birçok kötü pratik görüyorum. Son zamanlarda ilginç bir iş geldi. Önceden de bir projede birlikte çalıştığımız bir şirketten aradılar ve şöyle bir senaryo anlattılar:

- Yazılımcı, sistem yöneticisine Y veritabanının yedeğinin olup olmadığını soruyor,
- Sistem yöneticisi "var" diyor ve X konumuna Y veritabanının dosyalarını kopyalıyor,
- Yazılımcı, Y veritabanının zaten yedeği var diye, Y veritabanının kendisini (ayrıntılarını bilmediğim bir nedenden dolayı) ilgili SQL Server Instance'ından siliyor,
- Aradan 15 günden fazla bir süre geçtikten sonra yazılımcı X konumundaki yedeklerden dosyaları Attach ederek Y veritabanını geri getirmeye çalışıyor; fakat fark ediyor ki veritabanı dosyalarından biri eksik ve bu nedenle veritabanı Attach olmuyor,
- Yazılımcı, sistem yöneticisine bu eksikliği bildiriyor,
- Sistem yöneticisi geriye dönük olarak sadece 15 günlük yedek tuttuklarını iletiyor ve Y veritabanı ilgili SQL Server Instance'ından silineli 15 günden fazla olduğu için artık herhangi bir yerde bu veritabanının herhangi bir yedeğinin olmadığı anlaşılıyor,
- Bahsi geçen Y veritabanı, ilgili şirketin 4-5 senelik arşivi.
- Bu noktada benimle temas kurdular.

Hiçbir ekstra açıklamaya gerek kalmadan sırf yukarıdaki maddelerden, neyi nasıl yapmamanız gerektiğine dair birçok sonuç çıkarmışsınızdır diye tahmin ediyorum.

Bu sefer gerçekten çok şanslılardı ve veritabanını ciddi bir kayıp olmadan kurtarabildik. Ben elimden geleni yaparım, ama kimse bu konularda sadece şansına güvenmesin lütfen, her zaman bu seferki gibi şanslı olmayabilirsiniz.

Ekrem Önsoy
Microsoft SQL Server Danışmanı
www.ekremonsoy.com