Haziran başında platformda miras aldığımız yan sistemlerden birinde rutin kontrol yapıyorduk. Gece yedeklerinin durduğu klasörü açtık: dosyalar her gece düzenli olarak oluşmuş, isimlendirme tertemiz, yedi aylık arşiv duruyor. Tek kusurları vardı — hepsi 0 bayttı. Veritabanı şifresi yedi ay önce değiştirilmiş, mysqldump o günden beri hata veriyormuş. Ama script çıkış koduna bakmadığı için her gece "yedekleme tamamlandı" maili atmaya devam etmiş. Yedi ay boyunca, her sabah, yalan söyleyen bir mail.
Şanslıydık; bunu bir felaketten sonra değil, rutin bir iç kontrolde öğrendik. Sektörde bu hikâyenin kötü biten versiyonunu da az görmedim ve inanın, o toplantılarda bulunmak istemezsiniz.
Yedeğiniz Var mı, Yoksa Yedek Aldığınıza Dair İnancınız mı Var?
Bu ikisi farklı şeyler ve aradaki farkı ancak restore denemesi gösterir. Yedek dosyasının var olması hiçbir şey kanıtlamaz: dosya bozuk olabilir, şifreleme anahtarı kayıp olabilir, dump eksik tablolarla alınmış olabilir, ya da bizim vakadaki gibi içi bomboş olabilir.
Bizim ekipte kural şu: her ay en az bir kez, yedekten temiz bir ortama tam restore yapılır ve uygulama o ortamda ayağa kaldırılıp birkaç kritik senaryo elle ya da otomasyonla doğrulanır. Bu prova bir kez otomatikleştirildikten sonra maliyeti neredeyse sıfır; script yedeği indiriyor, izole bir konteynerde restore ediyor, tablo sayılarını ve son kayıt tarihlerini üretimle karşılaştırıp raporunu yazıyor. Son dönemde bu raporu bir AI ajanına okutuyoruz; sapma varsa insan uyandırılıyor, yoksa arşive not düşülüyor. İnsan eli değmeden dönen ama insan gözünden de kaçmayan bir döngü.
Bu ayki restore provanız ne zaman? Cevabınız "hiç yapmadık" ise, bu yazının geri kalanını o toplantıyı ayarladıktan sonra okuyun.
Patronunuza Sorulacak İki Soru: RPO ve RTO
Yedekleme stratejisi teknik ekipte başlamaz; iş tarafına sorulan iki soruyla başlar. Birincisi: en fazla kaç saatlik veriyi kaybetmeyi göze alabiliriz? Buna RPO deniyor. İkincisi: sistem en fazla kaç saat kapalı kalabilir? Bu da RTO.
Bu iki cevap her şeyi belirliyor. RPO'su 24 saat olan bir kurumsal tanıtım sitesi için gece yedeği yeter. RPO'su 15 dakika olan bir e-ticaret sistemi için gece yedeği komik kalır; binary log ile point-in-time recovery, belki de senkron replika gerekir. Yıllar önce kurduğum bir araç takip sisteminde iş tarafının cevabı "en fazla 5 dakika" idi — mimari de o cevaba göre kuruldu ve evet, o mimari daha pahalıydı. Pahalı olduğunu iş tarafı bilerek seçti; mesele de zaten bu, kararın mühendisin omzunda değil işletmenin masasında verilmesi.
RTO tarafı ise genelde unutuluyor. Yedeğiniz sapasağlam olabilir ama 400 GB'lık bir veritabanının restore süresi kaç saat? Bunu bilmiyorsanız RTO taahhüdünüz temenniden ibaret. Restore provasının bir faydası da tam burada: süreyi her ay ölçüyorsunuz, veri büyüdükçe sürenin nereye gittiğini görüyorsunuz.
Restore provasının bir yan geliri daha var: her ay elinizde üretimin taze ve çalışan bir kopyası oluyor. Kişisel verileri maskeleyen bir adım eklediğinizde bu kopya mükemmel bir test ortamına dönüşüyor — geliştiriciler gerçekçi hacimde veriyle performans testi yapabiliyor, o meşhur "üretimde yavaş ama testte hızlı" sorgular daha üretime gitmeden yakalanıyor. Tek taşla iki kuş, üstelik ikinci kuş bedava.
Yedeğin türü de RPO hesabının devamı. Gece alınan tam dump ile gün içi artımlı yedekleri (MySQL'de binary log, PostgreSQL'de WAL arşivi) birleştirdiğinizde, "dün geceye dön" seçeneğinin yanına "bugün 14:37'ye dön" seçeneği de gelir. Yanlış çalıştırılan bir toplu güncellemeyi geri almak için genelde ikincisine ihtiyaç duyarsınız; felaketlerin çoğu yangın değil, yanlış WHERE ile çalışan UPDATE çünkü.
Aynı Sunucudaki Yedek, Yedek Değildir
Klasik 3-2-1 kuralını hatırlatayım: en az üç kopya, iki farklı ortamda, biri fiziksel olarak başka yerde. Kulağa eski moda geliyor ama fidye yazılımı çağında her kelimesi güncellendi. Saldırganlar artık önce yedekleri şifreliyor ya da siliyor, sonra üretime geçiyor. Yedeğiniz üretim sunucusuyla aynı makinede, hatta aynı ağda erişilebilir durumdaysa, saldırı günü onu da kaybedersiniz.
Bu yüzden en az bir kopyanın değiştirilemez (immutable) depoda durmasını şart koşuyoruz: nesne depolamada object lock, yazılabilir ama silinemez-üzerine-yazılamaz bucket'lar. Üretim sunucusundan yedek deposuna tam yetkili erişim anahtarı koymak da aynı sebepten yasak — sunucu ele geçtiğinde anahtar da ele geçer. Yedek sistemi üretimden çekmeli, üretim yedek deposuna itebilmeli ama silememeli.
Hesap ayrımını da atlamamak lazım: yedeklerin durduğu bulut hesabı, üretimin çalıştığı hesaptan ayrı olsun, ayrı kimlik doğrulamayla korunusun. Tek bir yönetici hesabının ele geçirilmesiyle hem üretimin hem yedeklerin gittiği vakalar sektörde kayıtlı. Yedekler kişisel veri içerdiği için KVKK da masada: dump dosyalarını şifreleyin ve şifreleme anahtarını yedekle aynı yerde tutma hatasına düşmeyin — kapının anahtarını paspasın altına koymanın dijital versiyonu bu ve emin olun, ilk bakılan yer orası.
Ve baştaki hikâyenin asıl dersi: yedek sisteminin kendisi de izlenmeli. "Yedekleme tamamlandı" maili tasarım olarak sakat — insanlar gelen maile alışır ve okumaz, gelmeyen maili ise hiç fark etmez. Doğrusu tersine kurmak: yedek işi her başarılı turda bir izleme servisine sinyal atar, sinyal gelmezse alarm çalar. Ölü adam düğmesi denen bu desen, bizim yedi aylık sıfır baytlık faciayı daha ilk gece yakalardı. Alarm da mail değil, telefon çaldıran kanaldan gelsin.
Bir de kapsam körlüğü var: veritabanı yedekleniyor da yüklenen dosyalar, .env'ler, TLS sertifikaları, kuyruk durumu? Felaket günü "veritabanı elimizde ama kullanıcıların yüklediği 200 GB görsel gitti" cümlesi kimseyi teselli etmiyor.
Felaket Günü Provası: Kağıt Üzerinde Herkes Kahraman
Son adım, çoğu ekibin hiç yapmadığı şey: felaket tatbikatı. Senaryo basit — "üretim sunucusu az önce yandı, başlayın." Kim hangi adımı atacak? Restore talimatı nerede yazılı, o talimata sunucu yokken erişilebiliyor mu? (Runbook'u yanan sunucunun wiki'sinde tutmak, itfaiye planını yanan binada saklamak gibidir.) DNS'i kim değiştirecek, yetkisi var mı, o kişi tatildeyse?
Bu tatbikatı ilk kez yapan her ekipte — istisnasız her ekipte — en az üç sürpriz çıkıyor. İyi haber: sürprizlerin tatbikatta çıkması, gerçeğinde çıkmasından bin kat ucuz.
Yedekleme düzeninizi gözden geçirecekseniz ilk iş belli: o "yedekleme tamamlandı" mailinin doğru söyleyip söylemediğini bugün kontrol edin. Gerisini — restore provası, RPO/RTO hesabı — konuşmayı severim; iletişim sayfası açık.