Her hafta yedek alan, yılda bir kez kurtarma denemeyen ekipler, kendilerini güvende hisseder. Ama yedek ile kurtarma arasındaki fark, uçak biletiniz ile uçuşunuz arasındaki fark kadar büyüktür: biri plan, öteki uygulama. Yedek, verinin bir kopyasının var olduğunu kanıtlar; kurtarma, o kopyanın gerçekten çalıştığını. İkisinin arasındaki boşluk, çoğu felaket sonrası hikâyesinde sessizce dolar.

Yedek provası nedir

Kurtarma provası, yedeği üretimden izole bir ortamda gerçekten geri yükleyip sistemin çalıştığını gösterme pratiğidir. Üç soruya cevap ister: yedek tam mı, geri yükleme ne kadar sürüyor, geri yüklenen sistem gerçekten çalışıyor mu? Üçüncüsü en çok atlananıdır; veri geri geldiyse bile uygulamanın yeni şemaya, ortam değişkenlerine, sertifika ve bağlantı dizilerine ihtiyacı vardır.

# Prova: izole ortamda geri yükleme ve doğrulama
gun=$(date +%F)
pg_restore -h localhost -U kurtarma -d kanit_$gun \
  --no-owner --role=kurtarma yedekler/kanit_$gun.dump

# Doğrulama: satır sayıları ve uygulama testleri
psql -d kanit_$gun -c "SELECT count(*) FROM siparislar;"
pytest tests/kurtarma_provasi.py --env=kanit

Prova sıklığı, felaketin acımasızlığına göre belirlenir: kritik sistemlerde aylık, diğerlerinde üç aylık bir ritim uygundur. Önemli olan sıklık değil disiplindir: prova, takvimde köşe taşına dönüştüğü gün anlamlıdır. Provaları kimse kurtarmak istemediği için otomatikleştirin: her provadan sonra ölçülen süre, rapor dizinine yazılır ve önceki provayla karşılaştırılır. Süre üç provadır artıyorsa alarm zilidir; sistemin değil ekibin belleği eskimektedir.

RTO ve RPO: iki sayı, tek taahhüt

Kurtarma hedefi iki sayıyla anlatılır. RPO, ne kadar veri kaybetmeyi göze aldığınız; yedek sıklığınızı belirler. RTO, sistemi ne kadar sürede ayağa kaldıracağınızı taahhüt ettiğiniz süre; mimarinizi belirler. Bu sayılar iş birimiyle konuşulmalıdır: "günde bir saatlik veri kaybı kabul edilebilir" cümlesi, günlük yedek yeter demektir; "en fazla beş dakika" cümlesi ise günlük yedekle değil, akış tabanlı çoğaltma ile mümkündür. Sayıyı belirlemeden mimari seçmek, haritaya bakmadan yol seçmek gibidir.

Yedekleme stratejisinin tamamlayıcısı, kendini kanıtlamaktır: otomasyonla çalıştırılan geri yükleme, rapor üreten doğrulama ve takvimde yer tutan provalar. Felaket anında yöneticinin sorusu "verimiz var mı" değil "ne zaman geri döneriz" olur; bu sorunun cevabını ilk kez orada bulmak, kariyerin en pahalı test anıdır.

Prova tek başına da değerlidir ama zincirleme işler. Yedeği üretimden ayrı bir makineye geri yükleyin; uygulama sürümünü de aynı ortamda ayağa kaldırın; sonra bir kullanıcı gibi giriş yapıp kayıt oluşturun. Zincirin en zayıf halkası çoğu kez veritabanı değildir: süresi geçmiş sertifika, ortam değişkeninde unutulmuş anahtar, kurulu olmayan font ya da sabitlenmiş bir IP adresi olur. Prova bu halkaları felaketten önce görünür kılar.

En sık gözden kaçan üç detayı da listeye ekleyin: geri yüklenen veritabanında kullanıcı yetkileri ve parolalar, yedekten sonra değişmiş olabilecek ortam değişkenleri, DNS ve sertifika gibi veritabanının dışında duran ama sistemi ayağa kaldırmadan çalışmayan bileşenler. Provada bir şeyler ters giderse üzülmeyin; tam olması gereken de budur. Provanın değeri, kusursuz geçmesinde değil, kusurları felaket gününden önce yüzeye çıkarmasındadır.

Son cümle kısa olsun: prova bugün iki saat sürer; provasızlık, felaket günü iki gün demektir. Seçim sizin.