Sunucunuzun günlük yedeği alınıyor. Peki bir kullanıcı bugün öğlen yanlışlıkla bin kaydı sildiyse ne olacak? Gece yedeğine dönerseniz o günün tüm işlemlerini de kaybedersiniz.
Veritabanı yedekleme, dosya yedeklemeden farklı bir problemdir. Bu yazı, VDS sunucunuzda veritabanı yedekleme stratejisini anlatıyor.
Neden Farklı?
Veritabanı dosyalarını kopyalamak, çalışan bir veritabanında güvenilir bir yedek üretmez:
- Dosyalar sürekli değişir. Kopyalama sırasında yazma devam eder.
- Bellekteki veriler henüz diske yazılmamış olabilir.
- Tutarsız bir an yakalanabilir. Bir tablo yeni, diğeri eski hâlde kopyalanır.
Sonuç: açılamayan veya bozuk bir yedek. Ve bunu genellikle geri yüklemeye çalıştığınızda öğrenirsiniz.
Bu yüzden veritabanı yedeği, veritabanının kendi araçlarıyla alınmalıdır.
Yedek Türleri
| Tür | Ne içerir | Süre ve boyut |
|---|---|---|
| Mantıksal yedek | Veriyi yeniden oluşturan komutlar | Yavaş, sıkıştırılabilir |
| Fiziksel yedek | Veri dosyalarının kopyası | Hızlı, büyük |
| İşlem günlüğü | Her değişikliğin kaydı | Sürekli, küçük parçalar |
Mantıksal yedek en yaygın ve en esnek yöntemdir: metin tabanlı olduğu için farklı sürümlere ve hatta farklı sunuculara geri yüklenebilir.
Fiziksel yedek büyük veritabanlarında tercih edilir çünkü geri yükleme çok daha hızlıdır.
Üçüncü satır ise stratejinin kilit parçasıdır ve en çok atlanan yöntemdir.
Zaman Noktası Kurtarma
Baştaki soruna dönelim: gece yedeği var, kayıp öğlen oldu. Aradaki işlemleri nasıl kurtarırsınız?
Cevap işlem günlüklerindedir. Veritabanı, yapılan her değişikliği bir günlüğe yazar. Bu günlükler saklanırsa:
- Gece yedeği geri yüklenir
- İşlem günlükleri sırayla uygulanır
- İstenen zaman noktasında durdurulur
Sonuç: kaybın olduğu andan bir saniye öncesine dönebilirsiniz. Günlük yedek + işlem günlüğü kombinasyonu, veri kaybını dakikalardan saniyelere indirir.
Bu özelliği etkinleştirmek için gereken:
- İşlem günlüğü kaydının açık olması
- Günlüklerin ayrı bir yerde saklanması
- Saklama süresinin yedek sıklığından uzun olması
Üçüncü madde kritiktir: günlükler yedeklerden daha kısa süre saklanıyorsa, zincir kopar ve kurtarma yapılamaz.
Kilitleme Sorunu
Yedek alırken veritabanının tutarlı bir hâli yakalanmalıdır. Bunun yolu genellikle kilitlemedir — ama kilitleme, o süre boyunca siteyi yavaşlatır veya durdurur.
Çözümler:
- Tutarlı anlık görüntü modu. Modern veritabanı motorları, kilitlemeden tutarlı yedek almayı destekler.
- Çoğaltma sunucusundan yedek almak. Ana sunucu hiç etkilenmez.
- Düşük trafik saatinde almak. Basit ama etkili.
İkinci seçenek büyük veritabanlarında en temiz çözümdür: bir kopya sunucu kurulur, yedekler oradan alınır ve canlı sistem yedekleme yükünden tamamen kurtulur.
Bu yaklaşım ikinci bir sunucu gerektirir ama düşünüldüğü kadar maliyetli değildir: kopya sunucu yalnızca veri alıp yedek ürettiği için, ana sunucudan çok daha mütevazı bir VDS paketi yeterli olur.
Sıklık Belirleme
Yedek sıklığını belirleyen iki soru vardır:
- Ne kadar veri kaybını göze alabilirsiniz? Bu, yedek sıklığını belirler.
- Ne kadar sürede geri dönmeniz gerekir? Bu, yedek türünü ve saklama yerini belirler.
Örnek bir eşleştirme:
- Blog veya tanıtım sitesi: günlük yedek yeterli
- E-ticaret: günlük yedek + işlem günlüğü
- Finansal işlem: sürekli çoğaltma + sık yedek
İkinci satırdaki kombinasyon, çoğu ticari site için doğru dengedir: günlük tam yedek fazla yer kaplamaz, işlem günlükleri ise aradaki boşluğu kapatır.
Saklama ve Konum
Yedeğin nerede durduğu, ne kadar sık alındığından daha önemli olabilir:
- Aynı sunucuda tutmayın. Sunucu kaybedilirse yedek de gider.
- Aynı diskte hiç tutmayın. Disk arızasında ikisi birden gider.
- Farklı bir lokasyona kopyalayın. Veri merkezi sorununa karşı.
- Şifreleyin. Yedek, verinizin en kolay taşınabilir hâlidir.
- Erişimi kısıtlayın. Herkes yedeklere erişememeli.
Dördüncü madde sıkça atlanır ama ciddi bir risktir: şifresiz bir veritabanı yedeği, tüm müşteri verinizin taşınabilir bir kopyasıdır.
Saklama Planı
Tüm yedekleri sonsuza kadar saklamak hem maliyetli hem gereksizdir. Kademeli bir plan:
| Dönem | Saklanan |
|---|---|
| Son bir hafta | Her günün yedeği |
| Son bir ay | Haftalık birer yedek |
| Son bir yıl | Aylık birer yedek |
Bu yapı, hem yakın geçmişe ayrıntılı erişim sağlar hem de uzun vadeli bir arşiv tutar — makul bir depolama maliyetiyle.
Uzun vadeli arşivin değeri şudur: bazı veri kayıpları aylar sonra fark edilir. Yalnızca son bir haftanın yedeği varsa, o kaydı geri getirmek imkânsızdır.
Geri Yükleme Testi
Bu bölüm, yazının en önemli kısmıdır: test edilmemiş bir yedek, yedek değildir.
Test edilmesi gerekenler:
- Yedek dosyası açılabiliyor mu? Bozuk arşivler yaygındır.
- Geri yükleme tamamlanıyor mu? Hatasız bitiyor mu?
- Veri eksiksiz mi? Tablo ve kayıt sayıları karşılaştırılmalı.
- Ne kadar sürüyor? Kriz anında bu süreyi bilmeniz gerekir.
- Uygulama çalışıyor mu? Geri yüklenen veriyle site ayakta mı?
Dördüncü madde planlama için kritiktir: geri yükleme süresini bilmiyorsanız, kesinti süresini de tahmin edemezsiniz. Büyük veritabanlarında bu süre saatleri bulabilir.
Testi üç ayda bir yapmak makul bir sıklıktır. Test ortamınıza geri yükleyerek yapın — canlı sisteme dokunmadan.
Yedekleme İzleme
Sessizce başarısız olan bir yedekleme, en tehlikeli senaryodur. İzlenecekler:
- Yedek işi çalıştı mı?
- Hatasız tamamlandı mı?
- Dosya boyutu makul mü? — Aniden küçülmesi sorun işaretidir
- Uzak konuma kopyalandı mı?
- Eski yedekler planına göre temizleniyor mu?
Üçüncü madde ince bir kontroldür: yedek alınıyor, hata vermiyor ama dosya boyutu belirgin şekilde küçülmüşse, muhtemelen tabloların bir kısmı yedeklenmiyor.
Sonuç
Veritabanı yedeği, dosya kopyalamakla alınmaz — çalışan bir veritabanının dosyalarını kopyalamak tutarsız ve açılamayan bir yedek üretir. Stratejinin en çok atlanan parçası ise işlem günlükleridir: günlük tam yedek + işlem günlüğü kombinasyonu, veri kaybını saatlerden saniyelere indirir ve kaybın olduğu andan bir saniye öncesine dönmenizi sağlar. Yedekleri şifreleyin ve farklı bir lokasyonda tutun. Ve en kritik alışkanlığı edinin: üç ayda bir geri yükleme testi yapın — test edilmemiş bir yedek, yedek değildir.
Sıkça Sorulan Sorular (SSS)
Veritabanı dosyalarını kopyalamak yeterli değil mi?
Çalışan bir veritabanında hayır. Kopyalama sırasında yazma devam eder, bellekteki veriler henüz diske yazılmamış olabilir ve tutarsız bir an yakalanır. Sonuç genellikle açılamayan bir yedektir. Veritabanının kendi yedekleme araçlarını kullanın.
Gece yedeğim var ama öğlen veri kaybettim, ne yapabilirim?
İşlem günlükleri saklanıyorsa gece yedeğini geri yükleyip günlükleri kaybın olduğu ana kadar uygulayabilirsiniz. Bu özellik açık değilse aradaki tüm işlemler kaybolur — bu yüzden günlük yedek tek başına yeterli değildir.
Yedek alırken sitem yavaşlıyor?
Yedekleme, tutarlı bir hâl yakalamak için kilitleme yapıyor olabilir. Modern veritabanı motorları kilitlemeden tutarlı yedek almayı destekler. Büyük veritabanlarında en temiz çözüm, bir kopya sunucu kurup yedekleri oradan almaktır.
Yedeğimi ne sıklıkla test etmeliyim?
Üç ayda bir makul bir sıklıktır ve test ortamına geri yükleyerek yapılmalıdır. Yalnızca dosyanın açıldığını değil, kayıt sayılarının eksiksiz olduğunu ve geri yüklemenin ne kadar sürdüğünü de ölçün — kriz anında bu süreyi bilmeniz gerekir.
