12 Yaygın Veritabanı Yedekleme Hataları

Alexey Kovyazin tarafından, 11 Kasım 2015

PDF İndir (İngilizce) Bu makale başlangıçta Firebird DBMS geliştiricileri ve yöneticileri için tasarlanmıştı, ancak diğer veritabanlarının yöneticileriyle yapılan görüşmeler, hataların çoğunun onlar arasında da yaygın olduğunu ve neredeyse herkesin aynı taşlara takıldığını açıkça ortaya koydu. Bu listeye ekleyebileceğiniz bir şey varsa (belirli bir DBMS’ye özgü bir şey bile olsa), e-posta adresimiz üzerinden bizimle iletişime geçin [email protected].

1. Yeni bir yedek kopya oluşturulmadan önce önceki yedek kopyanın silinmesi

Bu hata, bir veritabanı yedek kopyasının asıl amacının yalnızca bir veritabanı kopyası oluşturmak değil, aynı zamanda bir bilgi sisteminin (önemli bir parçası veritabanı olan) kesinti süresini olabildiğince kısaltmak olduğunu fark etmeyen acemiler arasında en yaygın olanıdır.

Sonuç olarak, sistem en son yedek kopyanın silindiği andan yenisinin oluşturulduğu ana kadar korumasız kalır çünkü bu süre boyunca veritabanının tek bir yedek kopyası bile yoktur. Yedek kopya oluşturmak oldukça uzun sürebileceğinden, Murphy yasasının devreye girmesi için mükemmel bir zamandır. Bu yaklaşım, aşağıdaki 7. Sorunla birleştirildiğinde özellikle iyi çalışır.

Öneriler: yeni yedek kopya oluşturulmadan önce önceki yedek kopyayı silmeyin! (ve mevcut bir dosyaya yeni bir yedek kopya oluşturmayın).

Firebird için öneri: HQbird (Firebird’un gelişmiş bir dağıtım paketi) içinde yer alan bir FBDataGuard aracı vardır; bu araç, geçmişteki en eski yedek kopyayı yalnızca yenisi oluşturulduktan sonra siler.

2. Bir yedek kopyadan geri yüklerken mevcut bir veritabanının üzerine yazılması

Bu hata daha az yaygındır ancak sonuçları çok daha kötü olabilir. Yedek kopya doğrulanmamışsa ve bozuk olduğu ortaya çıkarsa (bkz. Sorun 6), ne veritabanının önceki kopyasına ne de geçerli bir yedek kopyaya sahip olursunuz.

Böyle bir karışıklık genellikle işlerin yoğun olduğu ve yönetimden gelen talimatların biraz çelişkili olduğu bir Cuma akşamı meydana gelir. Biraz şanssızlık ve sunucu odasında huzurlu bir hafta sonu sizi bekliyor demektir.

Firebird bu hataya karşı bir tür korumaya sahiptir - gbak yardımcı programı varsayılan -create anahtarı açıkken ve belirtilen dosya adı mevcut bir veritabanını gösteriyorsa, bir yedek kopyadan veritabanını geri yüklemek mümkün olmayacaktır. Ne yazık ki, bu korumayı aşmanın bir yolu vardır: -rep anahtarı mevcut dosyanın üzerine yazılmasına hâlâ izin verir.

Öneri: yönetiminizden yazılı bir talimat olmadan çalışan bir veritabanının dosyasının üzerine asla yazmayın.

Firebird için öneri: FBDataGuard kullanın çünkü veritabanı dosyasının üzerine asla yazmaz.

3. Ara yedek dosyası kullanılmadan tek adımlı yedekleme/geri yükleme yapılması

Standart giriş/çıkış akışları, birçok DBMS’de (Firebird dahil) komik bir numara yapmayı mümkün kılar: veritabanını aynı anda geri yükleyen akış tabanlı bir yedekleme uygulamak. Sonuç olarak ara yedek dosyası oluşturulmaz. Bu, rutin bakım ve test amaçlı geri yükleme işlemi çalıştırmak için uygundur (başka bir yedek kopyanın mevcut olması koşuluyla), ancak otomatik yedekleme için kullanmamalısınız!

Örneğin, bu yedekleme/geri yükleme işlemi sırasında ciddi bir disk arızası meydana gelirse, henüz yeni bir veritabanı oluşturulmamışken orijinal veritabanı hasar görebilir. Elbette, Sorun 1’i dikkate alırsanız ve önceki denemeden bir veritabanı kopyası varsa, yalnızca bu kopya oluşturulduktan sonra veritabanında oluşturulan veya güncellenen veriler kaybolacaktır.

Öneriler: otomatik modda tek adımlı yedekleme/geri yükleme kullanmayın ve manuel modda her zaman yeterince güncel bir kopyanın mevcut olduğunu kontrol edin.

4. Yedek kopyaların ve veritabanının aynı fiziksel cihazda saklanması

Birçoğunuz verdiğimiz tavsiyeyi biraz çocukça bulabilir - yedeklemenin ABC’si. Doğru, bu doğru, ancak sanal ortamların popülaritesi nedeniyle veritabanı ve disk aynı veri depolama sisteminde saklanabilir. Ve bu sistem kesinlikle en uygunsuz anda arızalanacaktır. Ayrıca, RAID dizileri kullanırlarsa (1. sürüm veya daha yükseği :)) verilerine hiçbir şey olamayacağına inanan insanlar hâlâ var. Ayrıca, bazı “marka” sunucuların arıza yapmayacağına inanan insanlar da var, ancak bu özel bir durumdur.

Öneriler: ne kadar güvenilir görünürse görünsün, yedek kopyaları ve veritabanını aynı cihazda saklamayın.

5. Yedekleme işleminin başarıyla tamamlandığının kontrol edilmemesi

Bu, hem yöneticiler hem de BT departmanlarının başkanları arasında oldukça yaygın bir hatadır. Yedekleme işleminin sonuçlarını kontrol etmiyorsanız, hiç yapmamanız daha iyidir. Başarıyla tamamlanan yedekleme işlemi hakkında e-posta veya daha da iyisi SMS yoluyla bildirim almalısınız. Ve bu bildirimlerin olmaması bir sorunun işaretidir!

Makalemizin bu noktasına ulaşan dikkatli bir okuyucu (şimdilik bunun için ödül vermek için henüz erken olsa da) şunu sorabilir: ‘Peki bunun yönetimle ne ilgisi var?’ İşte şu: yönetici genellikle yedekleme işlemini yapılandırır, ancak özellikle ayrı bir klasörde saklandıklarında bildirimleri kontrol etmeyi çok sıkıcı bulur, bu nedenle sürecin durumu hakkında ek raporlar talep etmek asla fazla değildir. Bu, yedek kopyalar varmış gibi göründüğünde ama aslında onlara ihtiyaç duyduğunuz anda orada olmadıklarında kimin suçlanacağı sorusuyla ilgilidir :)

! Sorun 2 ile birleştirildiğinde, ne veritabanına ne de yedek kopyasına sahibiz.

Öneriler: başarılı ve başarısız yedekleme işlemlerini izleyebilen, kullanıcıları sorunlar hakkında bilgilendiren ve özet kontrol araçları sunan yedekleme otomasyon araçlarını kullanın (özellikle farklı sunucularda düzinelerce ve yüzlerce yedekleme işlemini kontrol etmeniz gerektiğinde önemlidir).

Firebird için öneri: FBDataGuard, yedekleme işleminin tamamlanıp tamamlanmadığını kontrol eder ve ilgili bildirimi gönderir. Çok sayıda veritabanına sahip sistemler için, tüm izlenen sunucuların ve veritabanlarının durumlarını tek bir sayfada görmenizi sağlayan Control Center aracıyla ikinci seviye özet izleme vardır.

6. Yedek doğrulamasının yapılmaması

Yedek kopyaların bir yerde saklanması, oradan okunabilecekleri anlamına gelmez.

Bu nedenle, bozuk olmadıklarından veya /dev/null’a kopyalanmadıklarından emin olmak için oluşturduğunuz yedek kopyaları düzenli olarak doğrulamalısınız.

Firebird için öneri: yedek doğrulamasını FBDataGuard yardımıyla otomatikleştirebilirsiniz.

7. Doğrulanmamış yedek kopyalar kullanılırken veritabanı sağlık kontrollerinin yapılmaması

Genellikle veritabanları birkaç tür yedekleme kullanır - dökümler, düzenli yedek kopyalar vb. Ayrıntılara girmeden iki kategoriyi ayırt edebiliriz: doğrulanmış ve doğrulanmamış. Firebird söz konusu olduğunda, bunlar gbak ve nbackup’tır.

Gbak, bir yedek dosyası oluşturmak için veritabanının tamamını kayıt düzeyinde okur ve yeni bir veritabanına kayıtlar ekleyerek bir veritabanı oluşturur, böylece yedek kopyayı (geri yüklenen kopyaya hataların sızmasının yolları vardır, ancak bu, veritabanı yöneticisinin kötü organize edilmiş geçişle ilgili işleri karıştırmasının başka bir yoludur) ve veritabanının kendisini (baştan sona okunabiliyorsa, büyük olasılıkla bozuk değildir) doğrular.

Nbackup (diğer adıyla artımlı yedekleme), ana veritabanı dosyasını geçici olarak güncellemeler için kilitler (tutarlı durumda) ve veritabanı dosyasının hızlı bir şekilde kopyalanmasını (tamamen veya kısmen/artımlı olarak) mümkün kılar.

Büyük Firebird veritabanları (500 GB’den büyük) söz konusu olduğunda, kullanıcı işlemlerini yavaşlatmamak için nbackup kullanılması tavsiye edilir, ancak aynı zamanda veritabanını doğrulamak da gereklidir çünkü oluşturduğu doğrulanmamış yedek kopyalar veritabanı sayfa kopyalarıdır ve kayıt düzeyinde (RAM arızası nedeniyle) veya mantıksal düzeyde bir hata varsa, doğrulanmamış bir yedek kopya orijinal veritabanıyla birlikte bu hatayı da içerecektir.

Bunu önlemek için, orijinal veritabanı için çevrimiçi doğrulama kullanmalısınız (gfix ile çevrimiçi doğrulama Firebird sürüm 2.5.4’ten itibaren kullanılabilirken, FBDataGuard aracımız 1.5-2.5 sürümleri için çevrimiçi veritabanı doğrulamasını destekler).

Ayrıca, doğrulanmamış yedeklemeye ek olarak zaman zaman (örneğin haftada bir) doğrulanmış yedekleme yapılması tavsiye edilir.

Firebird için öneri: FBDataGuard, çevrimiçi sağlık kontrolünün yanı sıra yedek geri yükleme sürecini otomatik modda test etmenize olanak tanır.

8. Yedek kopyalar için boş alanın kontrol edilmemesi

Aslında bu klasik bir hatadır: yeterli alan yoksa, yedek kopyalar tüm boş alanı kaplar ve süreç bir hatayla sona erer. Yedek kopyaları veritabanıyla aynı diskte saklamak veritabanının çalışmasının kesintiye uğramasına yol açabilir ve bunları sistem diskinde saklamak sistem arızasıyla sonuçlanabilir.

Sorun 4 ile birleştirildiğinde, mümkün olan en iyi sonuç, veritabanının da boş alana ihtiyaç duyması ancak bu alanın yedek kopyalar tarafından işgal edilmesi nedeniyle sistemin çalışmayı durdurmasıdır. Sorunlar 5 ve 2 ile birleştirildiğinde ise, bizi yine ne veritabanı ne de yedek kopyasıyla bırakır.

Öneriler: yedek boyutunu tahmin eden ve olası boş alan eksikliği konusunda sizi uyaran yedekleme araçlarını kullanın.

Firebird için öneri: FBDataGuard, yedekleme amaçlı boş alan boyutunu ve ayrıca veritabanlarının bulunduğu diskteki ve sistem diskindeki boş alan boyutunu kontrol eder.

9. Yedek kopya oluşturma süresinin kontrol edilmemesi

Yedekleme işlemi tam altı ay önce 40 dakika sürüyordu ve aniden üç saat sürmeye başladı - neden? Veritabanının boyutu artmış olabilir veya RAID dizinizden bir disk düşmüş olabilir, bu da yazma performansının önemli ölçüde yavaşlamasına neden olur ve tüm yedek kopyalarınız bu dünyadan ayrılmak üzere olabilir. Ya da iyi bir meslektaşınız aynı anda bir yedekleme sistemi daha çalıştırıyor olabilir (bu arada, Firebird aynı anda birkaç yedekleme işlemi çalıştırmanıza izin verir, ancak buna neden ihtiyaç duyulduğu pek açık değildir). Yedek kopya oluşturma süresini kontrol etmezseniz, yeni ortaya çıkan bir sorunu gözden kaçırabilir ve büyümeden önce düzeltme şansını kaçırabilirsiniz.

Ayrıca, yedekleme sistemi yedekleme görevlerinin durumlarını izlemiyor ve bunları yalnızca programa göre çalıştırıyorsa, “topu önceden ateşleyebilirsiniz”, yani sistem önceki işlem henüz bitmemişken yeni bir yedekleme işlemi başlatır.

Öneriler: yedekleme işleminin süresini kontrol eden araçları kullanın!

Firebird için öneri: FBDataGuard, yedekleme işleminin süresini kontrol eder.

10. İşletim sistemi güncellemeleri uygulanırken veritabanının yedeklenmesi

Bu, özellikle Sorun 9 ve etkinleştirilmiş otomatik Windows güncellemeleriyle (varsayılan olarak güncellemeler sabah 3’te uygulanır) birleştirildiğinde çok yaygın bir sorundur. En iyi ihtimalle yavaşlamaya yol açar, ancak işletim sistemi güncellemeleri uygulamak için yeniden başlatılırsa, yedek kopya hasar görecektir. En azından iyi haber şu ki işletim sistemi her gün güncellenmez.

Öneriler: işletim sistemi güncellemelerini yedekleme işlemiyle çakışmayacakları zamanlara planlayın.

11. Veritabanı sunucusu çalışırken dosya yedekleme araçları veya sanal makine yedekleme araçlarıyla veritabanının yedeklenmesi

Birçok yönetici, herhangi bir DBMS’nin okunan ve yazılan verileri içeren aktif ve karmaşık bir önbelleğe sahip olduğunu ve veritabanı dosyalarının rastgele erişim modunda açık olduğunu unutur. Bu nedenle, yalnızca dosya yedekleme (veritabanı dosyalarının kopyalanması dahil) veya sanal makine yedekleme yerine özel yedekleme türleri kullanmak gerekir. Dosya yedekleme araçları veritabanını sırayla okur ve özellikle büyük veritabanları söz konusu olduğunda oldukça uzun sürebilir, bu nedenle oluşturulan yedek kopyanın bütünlüğünü garanti etmek imkansızdır.

Sanal makineler, anlık görüntü (snapshot) ve Değişen Blok İzleme (Changed Block Tracking) mekanizmalarını kullanabilir, ancak tutarlı bir veritabanı yedek kopyası elde etmek için oluşturulan yedek kopyaların senkronize edilmesi gerekir; çünkü değişen blokların toplanması sırasında veritabanıyla ilgili herhangi bir aktif yazma işlemi varsa yedek kopya tutarsız olacaktır.

Veritabanlarını dosya veya sanal makine yedekleme araçlarıyla yedeklemek isteyenler için iki yöntem sunabiliriz:

1. DBMS hizmetlerini ve işlemlerini tamamen kapatın, böylece önbellekte hiçbir şey kalmasın,
2. veritabanını, veritabanı dosyasının sıralı olarak kopyalanmasını güvenli hale getiren özel bir moda geçiren aracılar ve/veya betikler kullanın. Örneğin, MSSQL veritabanları için VSS writer adı verilen bir mekanizma vardır. İstek üzerine, anlık görüntü alındığı anda veritabanını anlık görüntü dostu moda geçirir. Değişen Blok İzlemeye dayalı mekanizmalar kullanıyorsanız, senkronizasyon anında veritabanının tutarlı olduğundan kendiniz emin olmalısınız.

Veritabanını yedekleme dostu moda geçirmezseniz, ortaya çıkan veritabanı kopyası, ana bilgisayarda sert bir sıfırlama (örneğin, elektrik kesintisi) yaşanmış gibi görünecektir. Bu güvenilirlik düzeyi çoğu işletme için kesinlikle yetersizdir. Bu konuda daha fazla bilgiyi “Sanal Makinelerde Veritabanlarıyla Çalışmanın Özellikleri” makalesinde bulabilirsiniz.

Firebird için, yedekleme işlemi başlamadan önce nbackup yardımıyla veritabanının ana dosyasını kilitlemek ve işlem bittikten sonra kilidi açmak gerekir. Diğer DBMS’ler için de ilgili modları açıp kapatmaya yarayan benzer araçlar mevcuttur.

Bazı veritabanı yöneticileri, DBMS’nin işlem günlüğü varsa standart dosya yedekleme araçlarıyla veritabanlarını güvenle yedekleyebileceklerinden emindir; çünkü en fazla yalnızca bu günlük bozulacaktır. Bu, DBMS geliştiricilerinin desteklemediği tehlikeli bir yanılgıdır.

Bu yanılgının kökleri açıktır: sanal makine ve yedekleme aracı geliştiricilerinin agresif reklamları, veritabanlarının ve yoğun olarak güncellenen diğer dosyaların gelişmiş yapılandırma gerektirdiğinden genellikle bahsetmez. Abartıya kanmayın - her yoğurt aynı faydayı sağlamaz.

Öneriler: veritabanları için ilgili otomasyon araçları olmadan dosya ve VM yedekleme araçlarını kullanmayın.

Firebird için öneri: FBDataGuard (HQbird dağıtım paketinden) kullanın; VSS destekli yedekleme araçlarıyla entegrasyon sağlar.

12. Yedeklemeyi çoğaltma ile değiştirmek

Veri yedekleme ve veri çoğaltma, güvenilirliği artırmak ve veri kaybını önlemek için kullanılır, ancak yine de oldukça farklıdırlar.

Herkes çoğaltmayı, verileri başka bir sunucuda minimum gecikmeyle senkronize etme yeteneği için sever; ancak yedeklemenin de tartışmasız avantajları vardır. Örneğin, kazara (veya kasıtlı) veri silinmesi durumunda, çoğaltma değişiklikleri hızla ve sarsılmadan replikaya gönderirken, yedekleme (özellikle salt okunur ortamdaki kopyalarla) bu tür işlemlere karşı bağışıktır. Hem çoğaltmayı hem de yedeklemeyi doğru yapılandırmak belirli bir çaba gerektirir ve yine de hata olasılığı her zaman vardır.

Öneriler: Çoğaltma yapılandırdıysanız, yedek kopyaları ihmal etmeyin, ikisini de kullanın.

Firebird için öneri: HQbird Enterprise dağıtım paketini kullanın; hem yedekleme hem de çoğaltma araçlarını içerir.

Özet

En sevdiğiniz DBMS için yedekleme yapılandırmak o kadar kolay değildir; bu nedenle verilerine değer veren kuruluşlardaki veritabanı yöneticileri genellikle yukarıda belirtilen sorunları dikkate alan ve sorunları önleyen profesyonel yedekleme araçlarını kullanır.

Firebird için (reklam için özür dilerim) HQbird adında bir paket vardır ve bu paket FBDataGuard içerir.

Ayrıca şirketimiz Firebird ve diğer veritabanları için eksiksiz yedekleme ve bakım desteği sağlar; bu, yedeklemelerin tüm teknik ayrıntılarına hakim olmayanlar için iyi bir seçimdir.

Ve elbette, yönetici paranoyanızı beslemeye devam edin; örneğin, hemen kalkıp yedek kopyalarınızı kontrol edin :)

İletişim

Lütfen sorularınızı sormaktan çekinmeyin: [email protected]

Firebird hakkında haberler ve makaleler almak ister misiniz? Bize Telegram’da katılın https://t.me/firebirdsql