Veritabanlarını Yedeklerken Yapılan 12 Yaygın Hata
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 kelimenin tam anlamıyla herkesin neredeyse aynı taşlara takıldığını açıkça gösterdi. Bu listeye bir şey ekleyebilirseniz (belirli bir DBMS’ye özgü bir şey bile olsa), bize e-posta yoluyla ulaşın [email protected].
1. Yeni bir yedek kopya oluşturulmadan önce önceki yedek kopyanın silinmesi
Bu hata en çok, bir veritabanı yedek kopyasının asıl amacının sadece bir veritabanı kopyası oluşturmak değil, aynı zamanda bir bilgi sisteminin (önemli bir parçası veritabanı olan) kesinti süresini mümkün olduğunca kısa tutmak olduğunu fark etmeyen yeni başlayanlar arasında yaygındı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ı 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 özellikle Sorun 7 ile birleştirildiğinde çok iyi işler (aşağıya bakın).
Ö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’ün gelişmiş bir dağıtım paketi) içinde yer alan bir FBDataGuard aracı vardır ve geçmişteki en eski yedek kopyayı yalnızca yeni bir kopya oluşturulduktan sonra siler.
2. Bir yedek kopyadan geri yüklerken mevcut 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ğunlaştığı ve yönetimden gelen talimatların bir şekilde çelişkili olduğu bir Cuma akşamı meydana gelir. Biraz kötü şans ve sunucu odasında hüzünlü bir hafta sonu sizi bekliyor.
Firebird’ün bu hataya karşı bir tür koruması vardır - varsayılan -create anahtarı açıksa ve belirtilen dosya adı mevcut bir veritabanını gösteriyorsa, gbak yardımcı programıyla 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ı hâlâ mevcut dosyanın üzerine yazmaya 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 bir yedek dosya kullanmadan tek adımlı yedekleme/geri yükleme kullanılması
Standart giriş/çıkış akışları, birçok DBMS ile (Firebird dahil) eğlenceli bir numara yapmayı mümkün kılar: akışlı bir yedekleme uygulayın ve veritabanını aynı anda ondan geri yükleyin. Sonuç olarak ara bir yedek dosya oluşturulmaz. Rutin bakım ve bir test 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, başlangıçtaki veritabanı hasar görebilir ve henüz yeni bir veritabanı oluşturulmamış olabilir. Elbette, Sorun 1’i hesaba katarsanız ve önceki denemeden bir veritabanı kopyası varsa, yalnızca o kopya oluşturulduktan sonra veritabanında oluşturulan veya güncellenen veriler kaybolur.
Öneriler: otomatik modda tek adımlı yedekleme/geri yükleme kullanmayın ve manuel modda her zaman yeterince güncel bir kopyanın mevcut olup olmadığını kontrol edin.
4. Yedek kopyaların ve veritabanının aynı fiziksel cihazda saklanması
Birçoğunuz verdiğimiz tavsiyenin biraz çocukça olduğunu düşünebilirsiniz - yedeklemenin ABC’si. Doğru, bu doğru, ancak sanal ortamların popülerliği nedeniyle veritabanı ve disk aynı veri depolama sisteminde saklanabilir. Ve kesinlikle en uygunsuz anda başarısız olacaktır. Ayrıca, RAID dizileri (sürüm 1 veya daha yüksek :)) kullanırlarsa verilerine hiçbir şey olamayacağına inanan insanlar hâlâ var. Ayrıca, bazı “marka” sunucuların hatasız olduğuna 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 tamamlanması üzerinde kontrol olmaması
Hem yöneticiler hem de BT departmanı başkanları arasında oldukça yaygın bir hatadır. Yedekleme işleminin sonuçlarını kontrol etmezseniz, hiç gerçekleştirmemiş olmanız da bir o kadar iyidir. Başarıyla tamamlanan yedekleme işlemiyle ilgili bildirimleri e-posta yoluyla veya daha da iyisi SMS yoluyla da almalısınız. Ve bu tür bildirimlerin olmaması bir sorun işaretidir!
Makalemizde bu noktaya ulaşan dikkatli bir okuyucu (gerçi bunun için bir ödül vermek henüz çok erken) şunu sorabilir: ‘Ama bunun yönetimle ne ilgisi var?’ İşte şu - yönetici genellikle yedekleme sürecini yapılandırır, ancak bildirimleri kontrol etmeyi özellikle ayrı bir klasörde saklandıklarında çok sıkıcı bulur, bu nedenle sürecin durumu hakkında ek raporlar talep etmek asla fazla değildir. Bu, yedek kopyalar sanki varmış gibi göründüğünde, ancak ihtiyaç duyduğunuz anda aslında orada olmadıklarında kimin suçlanacağı sorusuyla ilgilidir :)
! Sorun 2 ile birleştirildiğinde, ne veritabanına ne de yedek kopyasına sahip oluruz.
Öneriler: başarılı ve başarısız yedekleme süreçlerini izleyebilen, kullanıcıları sorunlar hakkında bilgilendirebilen ve özet kontrol araçları sunabilen yedekleme otomasyon araçları kullanın (bu özellikle farklı sunucularda düzinelerce ve yüzlerce yedekleme sürecini kontrol etmeniz gerektiğinde geçerlidir).
Firebird için öneri: FBDataGuard yedekleme sürecinin 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ı yardımıyla ikinci düzey özet izleme vardır.
6. Yedek doğrulaması olmaması
Yedek kopyaların bir yerde saklanıyor olması, 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: FBDataGuard yardımıyla yedek doğrulamasını otomatikleştirebilirsiniz.
7. Doğrulanmamış yedek kopyalar kullanılırken veritabanı sağlık kontrollerinin olmaması
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 tüm veritabanını kayıt düzeyinde okur ve yeni bir veritabanına kayıtlar ekleyerek bir veritabanı oluşturur, böylece yedek kopyayı (hataların geri yüklenen kopyaya sızmasının yolları vardır, ancak bu, veritabanı yöneticisinin kötü organize edilmiş geçişle ilgili işleri berbat etmesinin başka bir yoludur) ve veritabanının kendisini doğrular (baştan sona okunabiliyorsa, büyük olasılıkla bozuk değildir).
Nbackup (diğer adıyla artımlı yedekleme) ana veritabanı dosyasını güncellemeler için geçici olarak kilitler (tutarlı durumda) ve veritabanı dosyasını hızlı bir şekilde kopyalamayı mümkün kılar (tamamen veya kısmen/artımlı olarak).
Büyük Firebird veritabanları söz konusu olduğunda (500 GB’dan büyük), 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 bir hata kayıt düzeyinde (RAM arızası nedeniyle) veya mantıksal düzeyde bulunuyorsa, doğrulanmamış bir yedek kopya da onu orijinal veritabanında olduğu gibi içerecektir.
Bunu önlemek için, orijinal veritabanı için çevrimiçi doğrulama kullanmalısınız (gfix yardımıyla çevrimiçi doğrulama Firebird 2.5.4 sürümünden itibaren mevcuttur, FBDataGuard aracımız ise 1.5-2.5 sürümleri için çevrimiçi veritabanı doğrulamasını destekler).
Ayrıca, doğrulanmamış yedeklemeye ek olarak ara sıra (örneğin haftada bir) doğrulanmış yedekleme yapılması tavsiye edilir.
Firebird için öneri: çevrimiçi sağlık kontrolünün yanı sıra, FBDataGuard yedek geri yükleme işlemini otomatik modda test etmenizi sağlar.
8. Yedek kopyalar için boş alan üzerinde kontrol olmaması
Aslında bu klasik bir hatadır: yeterli alan yoksa, yedek kopyalar tüm boş alanı kaplar ve işlem bir hatayla sona erer. Yedek kopyaları veritabanıyla aynı diskte saklamak veritabanının çalışmasında bir kesintiye yol açabilir ve bunları sistem diskinde saklamak bir sistem arızasına neden olabilir.
Sorun 4 ile birleştirildiğinde, en iyi olası sonuç sistemin çalışmayı durdurması olacaktır çünkü veritabanının da boş alana ihtiyacı vardır, ancak bu alan yedek kopyalar tarafından işgal edilmiştir. Sorun 5 ve 2 ile birleştirildiğinde ise, yine ne veritabanına ne de yedek kopyasına sahip oluruz.
Öneriler: yedek boyutunu tahmin eden ve olası boş alan eksikliği konusunda sizi uyaran yedekleme araçları kullanın.
Firebird için öneri: FBDataGuard yedekleme amacıyla 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üresi üzerinde kontrol olmaması
Yedekleme işlemi tam anlamıyla altı ay önce 40 dakika sürüyordu ve sonra aniden üç saat sürüyor - neden? Veritabanının boyutu artmış olabilir veya RAID dizinizden bir disk çıkmış olabilir, bu da yazma performansının önemli ölçüde yavaşlamasına neden olabilir 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ırmış olabilir (bu arada, Firebird aynı anda birkaç yedekleme süreci çalıştırmanıza izin verir, ancak bunun neden gerekli olabileceği pek açık değildir). Yedek kopya oluşturma süresini kontrol etmezseniz, yeni ortaya çıkan bir sorunu gözden kaçırabilir ve kitlesel hale gelmeden önce düzeltme şansını kaçırabilirsiniz.
Ayrıca, yedekleme sistemi yedekleme görevlerinin durumlarını izlemez ve bunları sadece programa göre çalıştırırsa, kolayca “erken davranabilirsiniz”, yani sistem önceki işlem henüz bitmemişken yeni bir yedekleme süreci başlattığında ortaya çıkan durum.
Ö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 çok yaygın bir sorundur, özellikle Sorun 9 ile birleştirildiğinde ve otomatik Windows güncellemeleri etkinleştirildiğinde (varsayılan olarak güncellemeler saat 3’te uygulanır). En iyi ihtimalle bir yavaşlamaya yol açar, ancak güncellemeleri uygulamak için işletim sistemi yeniden başlatılırsa, yedek kopya hasar görür. En azından iyi haber şu ki, işletim sistemi her gün güncellenmez.
Öneriler: işletim sistemi güncellemelerini yedekleme işlemini engellemeyecekleri bir zamana planlayın.
11. Veritabanı sunucusu çalışırken veritabanının dosya yedekleme araçları veya sanal makine yedekleme araçları yardımıyla yedeklenmesi
Birçok yönetici, herhangi bir DBMS’nin, veritabanı dosyaları rastgele erişim modunda açıkken okunan ve yazılan verileri içeren etkin ve karmaşık bir önbelleğe sahip olduğunu unutur. Bu nedenle, salt dosya yedeklemesi (yalnızca veritabanı dosyalarının kopyalanması dahil) veya sanal makine yedeklemesi yerine özel yedekleme türlerinin kullanılması gerekir. Dosya yedekleme araçları veritabanını sırayla okur ve bu ö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 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 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:
- önbellekte hiçbir şey kalmaması için DBMS hizmetlerini ve süreçlerini tamamen kapatmak,
- veritabanını, veritabanı dosyasının sıralı olarak kopyalanmasını güvenli hale getiren özel bir moda geçiren ajanlar ve/veya betikler kullanmak. Örneğin, MSSQL veritabanları için VSS writer adı verilen bir mekanizma vardır. İstek üzerine, snapshot alındığı anda veritabanını snapshot dostu moda geçirir. Değişen Blok İzleme’ye 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 bir sabit sıfırlama (örneğin, elektrik kesintisi) meydana gelmiş gibi görünecektir. Bu güvenilirlik düzeyi çoğu işletme için kesinlikle yetersizdir. Bu konuda daha fazlasını “Sanal Makinelerde Veritabanlarıyla Çalışmanın Özellikleri” makalesinde öğrenebilirsiniz.
Firebird için, yedekleme işlemi başlamadan önce nbackup yardımıyla veritabanının ana dosyasının kilitlenmesi ve işlem bittikten sonra kilidinin açılması gerekir. Diğer DBMS’ler için de ilgili modları açıp kapatmaya yönelik benzer araçlar vardır.
Bazı veritabanı yöneticileri, DBMS’nin bir işlem günlüğü varsa veritabanlarını standart dosya yedekleme araçlarıyla 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 diğer yoğun güncellenen dosyaların gelişmiş yapılandırma gerektirdiğinden genellikle bahsetmez. Abartılı reklamlara inanmayın - her yoğurdun faydası eşit değildir.
Öneriler: veritabanları için ilgili otomasyon araçları olmadan dosya ve VM yedekleme araçlarını kullanmayın.
Firebird için öneri: HQbird dağıtım paketinden FBDataGuard’ı kullanın; VSS uyumlu yedekleme araçlarıyla entegrasyon sağlar.
12. Yedeklemeyi replikasyonla değiştirmek
Veri yedekleme ve veri replikasyonu, güvenilirliği artırmak ve veri kaybını önlemek için kullanılır, ancak yine de oldukça farklıdırlar.
Herkes, verileri başka bir sunucuda minimum gecikmeyle senkronize edebilme yeteneği nedeniyle replikasyonu sever, ancak yedeklemenin de tartışılmaz avantajları vardır. Örneğin, kazara (veya kasıtlı) veri silme durumunda replikasyon değişiklikleri hızla ve sarsılmadan replikaya gönderecekken, yedekleme (özellikle salt okunur ortamdaki kopyalarla) bu tür işlemlere karşı bağışıktır. Hem replikasyonu hem de yedeklemeyi doğru şekilde yapılandırmak belirli bir çaba gerektirir ve yine de hata olasılığı her zaman vardır.
Öneriler: Replikasyon yapılandırdıysanız, yedek kopyaları ihmal etmeyin, her ikisini de kullanın.
Firebird için öneri: hem yedekleme hem de replikasyon araçlarını içeren HQbird Enterprise dağıtım paketini kullanın.
Özet
En sevdiğiniz DBMS için yedeklemeyi 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 almalarına ve sorunları önlemelerine olanak tanıyan profesyonel yedekleme araçları kullanır.
Firebird için (reklam için affınıza sığınarak) FBDataGuard içeren HQbird adlı bir paket vardır.
Ayrıca şirketimiz, Firebird ve diğer veritabanları için eksiksiz yedekleme ve bakım desteği sunar; bu, yedeklemelerin tüm teknik ayrıntılarını bilmeyenler için iyi bir seçimdir.
Ve elbette, yönetici paranoyanızı beslemeye devam edin, örneğin, şimdi kalkın ve yedek kopyalarınızı kontrol edin :)
İletişim
Her türlü sorunuzu çekinmeden sorun: [email protected]
Firebird hakkında haber ve makaleler almak ister misiniz? Telegram’da bize katılın https://t.me/firebirdsql