Veritabanı Yedekleme Stratejisi Kurmak: Hedefler, Yöntemler ve Kurtarma Provası

Yedek almak ile kurtarabilmek aynı şey değildir

Veritabanı yedekleme çalışmasında en sık yapılan yanılgı, yedeğin alınmış olmasını kurtarma güvencesi saymaktır. Yedek, ancak üzerinde geri yükleme denenmiş, süresi bilinen ve veri kaybı sınırı kabul edilmiş ise bir güvence sağlar. Bu yüzden strateji, yedekleme komutlarından önce şu sorularla başlar: en fazla ne kadar veri kaybı kabul edilebilir, sistem en fazla ne kadar süre kapalı kalabilir.

Bu sorular sırasıyla RPO (kurtarma noktası hedefi) ve RTO (kurtarma süresi hedefi) kavramlarıyla ifade edilir. Hedefler iş birimleriyle birlikte belirlenir, çünkü teknik ekip bu kararların maliyetini bilir ama değerini iş tarafı bilir. Hedefler netleşince yedekleme yöntemi, sıklığı, saklama yeri ve test periyodu bu hedeflere göre seçilir.

Adım adım: yedekleme stratejisi nasıl kurulur?

• Veritabanlarını sınıflandırın: iş için kritik olanlar, kaybı tolere edilebilenler, yeniden üretilebilenler.
• Her sınıf için RPO ve RTO hedeflerini yazın ve onaylatın.
• Yedekleme yöntemini seçin: mantıksal, fiziksel, artımlı, sürekli kayıt günlüğü arşivleme.
• Yedeklerin nereye ve nasıl saklanacağını belirleyin: aynı sunucudan ayrı bir depolama, ayrı bir konum, değiştirilemez saklama seçenekleri.
• Yedekleri şifreleyin ve erişimi sınırlayın.
• Otomasyonu kurun: zamanlama, başarı kontrolü, hata bildirimi, saklama süresi sonunda silme.
• Geri yükleme senaryolarını yazın ve düzenli olarak prova edin.
• Prosedürü, kimin neyi yapacağını belirten bir runbook olarak belgeleyin.

Mantıksal ve fiziksel yedek: farkı ve ne zaman hangisi

Mantıksal yedek, veritabanının içeriğini SQL ifadeleri ya da dışa aktarım dosyası olarak çıkarır. PostgreSQL'de pg_dump, MySQL ve MariaDB'de mysqldump bu işi görür. Küçük ve orta boyutlu veritabanlarında, tek bir tabloyu ya da şemayı geri getirmek istediğinizde ve veritabanı sürümleri veya platformlar arasında taşıma yapacağınızda kullanışlıdır. Büyük veritabanlarında hem yedekleme hem geri yükleme yavaştır.

Fiziksel yedek ise veri dosyalarının doğrudan kopyasıdır. Büyük hacimde hızlıdır ve noktasal geri dönüşün temelini oluşturur; ancak genellikle aynı veritabanı ürününe ve uyumlu sürüme geri yüklenir. PostgreSQL'de temel yedek için pg_basebackup, MySQL tarafında ise Percona XtraBackup ve MariaDB'nin kendi yedekleme aracı gibi seçenekler kullanılır. Pratikte bu yöntemler birlikte kullanılır: günlük fiziksel yedek ve sürekli kayıt arşivi ana kurtarma yolunu, düzenli mantıksal yedek ise ayrıntılı geri getirme ve taşıma ihtiyacını karşılar.

Noktasal geri dönüş (PITR) nasıl çalışır?

Noktasal geri dönüş, veritabanını son yedeğe değil, geçmişteki belirli bir ana döndürmeye yarar. Tipik ihtiyaç şudur: öğleden sonra yanlış bir güncelleme ya da silme komutu çalıştırıldı ve veritabanı komuttan hemen önceki ana geri alınmalı. Gece alınan tam yedeğe dönmek gün içindeki tüm işlemleri kaybettirir; PITR bu kaybı önler.

Mekanizma birbirini tamamlayan parçalardan oluşur: temel bir fiziksel yedek ve o yedekten sonraki tüm değişikliklerin sürekli arşivlenen kaydı. PostgreSQL'de bu kayıt WAL (write-ahead log) dosyalarıdır; MySQL ve MariaDB'de ise ikili kayıt (binary log) dosyalarıdır. Geri yükleme sırasında önce temel yedek açılır, ardından kayıtlar istenen zamana kadar yeniden oynatılır. Zincirin tek bir halkası eksikse bu sınıra kadar ilerlenemez; bu yüzden arşivlenen kayıtların bütünlüğü düzenli doğrulanır.

PITR kullanılacaksa saklama süresi de bilinçli seçilmelidir. Hatalı bir değişikliğin fark edilmesi bazen günler sürer; temel yedek ve kayıt arşivi o güne kadar korunmuyorsa kurtarma mümkün olmaz.

Depolama, güvenlik ve otomasyon

Yedeğin veritabanı ile aynı sunucuda ya da aynı depolama sisteminde durması, sunucu kaybında hem veriyi hem yedeği kaybetmek demektir. Yedekler ayrı bir depolamada ve idealde ayrı bir konumda tutulmalıdır. Fidye yazılımı tehdidine karşı değiştirilemez ya da silinemez saklama sağlayan seçenekler ve erişimi ayrı hesapla sınırlamak önemlidir.

Yedekler veri içerdiği için veritabanı kadar korunmalıdır: şifreleme, anahtar yönetimi ve yetkili erişim. Gizlilik mevzuatı kapsamındaki kişisel veriler yedeklerde de bulunur; saklama süresi bitince yedeğin gerçekten silindiğinden emin olunmalıdır.

Otomasyonda asıl tuzak, işin çalıştığını varsayıp sonucu kontrol etmemektir. Zamanlanmış görev hata verdiğinde bildirim gitmeli, yedeğin boyutu ve süresi beklenen aralığın dışına çıktığında uyarı oluşmalı, saklama politikası eski yedekleri temizlemelidir. Başarısız bir yedeğin haftalarca fark edilmemesi sık görülen bir olaydır.

Kurtarma tatbikatı ve prosedür

Geri yükleme düzenli denenmeyen bir yedek, varsayımdır. Tatbikat için ayrı bir ortamda en son yedeği geri yükleyin, veri bütünlüğünü kontrol edin ve süreyi ölçün. Ölçülen süre RTO hedefini aşıyorsa strateji yeniden düşünülmelidir: daha hızlı depolama, artımlı yedek, yedek sunucu ya da replikasyon gibi seçenekler devreye girer.

Farklı senaryolar ayrı prova edilmelidir: tek tablonun yanlışlıkla silinmesi, belirli bir ana dönüş, sunucunun tamamen kaybı, depolama arızası, bölgesel kesinti. Her biri için adım adım runbook yazın; kriz anında kimin kime haber vereceği, hangi sırayla işlem yapılacağı ve son kararı kimin vereceği önceden bilinmelidir.

Tatbikattan sonra bulgular kayda geçer ve prosedür güncellenir. Altyapı, sürüm ya da veri hacmi değiştiğinde prova tekrarlanır.

Sık yapılan hatalar

• Geri yüklemeyi hiç denememek.
• Yedeği veritabanıyla aynı diske ya da aynı sunucuya almak.
• RPO ve RTO hedeflerini yazılı olarak belirlememek.
• PITR için kayıt arşivinde kopukluk bırakmak ya da arşiv alanını doldurmak.
• Yedek şifreleme anahtarını yedekle birlikte aynı yerde tutmak.
• Yedekleme işinin sessizce başarısız olmasını izlememek.
• Yalnızca mantıksal yedeğe güvenip büyük veritabanında geri yükleme süresini hesaplamamak.
• Saklama süresini yasal ve işle ilgili gereksinimlere bakmadan belirlemek.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mindset kataloğunda bu alanla ilgili birbirini tamamlayan eğitimler vardır. Veritabanı Yedekleme ve Felaket Kurtarma Stratejileri; Kurtarma Hedefleri ve Risk Analizi, Yedekleme Yöntemleri ve Araçları, Kurtarma Senaryoları, Prova, Otomasyon ve Saklama Politikası modüllerinden oluşur. Veritabanı Yedekleme ve Noktasal Geri Dönüş (PITR) Stratejileri ise Kurtarma Hedefleri ve Strateji Tasarımı, Fiziksel ve Mantıksal Yedekleme, PostgreSQL ile Noktasal Geri Dönüş, MySQL ve MariaDB ile Noktasal Geri Dönüş, Depolama, Güvenlik ve Otomasyon, Kurtarma Tatbikatları ve Prosedür modüllerini içerir.