Senaryo Analizi: Beyanname Haftasında Disk Arızası — RTO ve RPO'nun Sahadaki Anlamı

Bu yazı, sahada tekrar eden gerçek vakaların birleştirilmiş, kişi ve kurum bilgisi içermeyen temsili bir anlatımıdır.

Yirmi kişilik bir mali müşavirlik ofisi düşünün: beyanname haftası, herkes sistemde, muhasebe yazılımının veritabanı ofisteki sunucuda. Salı 09:20'de yazılım donar, sunucu kasasından düzenli bip sesi gelir: disk arızası. Bu senaryoyu aynı ofisin iki farklı yılında izleyeceğiz — çünkü aradaki fark donanım değil, iki kısaltmanın varlığı: RTO ve RPO.

Birinci Yıl: Hedefsiz Gün

O yıl "yedek var" cümlesi doğruydu ama eksikti: gece yedeği, sunucunun yanındaki tek NAS'a alınıyordu ve hiç geri dönüş testi görmemişti. Kronoloji acımasız işledi: sabah arıza, öğlene kadar "belki düzelir" denemeleri, öğleden sonra yeni disk arayışı. Ertesi gün disk takıldı, yedekten dönüş başladı — ve ilk sürpriz: yedek dosyasının son üç gecesi bozuktu, sağlam kopya dört gün öncesine aitti. İkinci sürpriz: kimse restore'un kaç saat süreceğini bilmiyordu; veritabanı boyutunda bir dönüş sekiz saat aldı. Üçüncü gün öğleden sonra sistem açıldığında dört günlük kayıt elle yeniden girilecekti — beyanname haftasında, mesai sonralarında. Toplam fatura: üç iş günü kesinti, günlerce fazla mesai ve bir müşteri kaybı.

Yönetim Toplantısındaki İki Soru

O yılın ardından yapılan değerlendirmede teknik ekip iki soruyu yönetimin önüne koydu — RTO/RPO çerçevesinin ta kendisi:

• "Bu sistem çöktüğünde kaç saat içinde dönmüş olmalıyız?" Cevap tartışıldı ve yazıldı: normal dönemde 4 saat, beyanname dönemlerinde 2 saat (RTO).
• "En fazla kaç saatlik veri girişini gözden çıkarabiliriz?" Cevap: normalde 4 saat, yoğun dönemde 1 saat (RPO) — çünkü bir günlük kaydın yeniden girilmesi, bu ofiste iki kişilik tam mesai demekti.

Bu iki sayı, teknik alışveriş listesine dönüştü: saatlik yedek alabilen düzen, 3-2-1 kuralına uygun ikinci kopya, veritabanına özgü yedek yöntemi, disk sağlığını önceden haber veren izleme ve çeyrekte bir süre ölçen tatbikat.

İkinci Yıl: Aynı Arıza, Başka Gün

Saat	Olay	Fark yaratan
09:20	Disk arızası; sunucu yavaşladı, alarm düştü	İzleme, arızayı kullanıcı şikayetinden önce bildirdi
09:25	Plan devrede: son saatlik yedek doğrulandı (09:00 kopyası sağlam)	RPO penceresi: en fazla 20 dakikalık giriş riski
09:40	Karar: onarım beklemeden yedek donanıma restore	RTO 2 saat olduğu için "belki düzelir" beklemesi yok
11:10	Veritabanı yedek sunucuda açıldı, uygulama bağlantıları çevrildi	Tatbikatlarda ölçülen 80 dakikalık restore, 90 dakikada bitti
11:50	Ekip çalışıyor; 09:00-09:20 arası girişler kontrol listesiyle tamamlandı	Kesinti: 2,5 saat · veri penceresi: 45 dakika

Aynı ofis, aynı yazılım, benzer arıza. Fark; iki sayının yazılı olması ve altyapının o sayılara göre kurulmuş olmasıydı.

Bu Senaryonun Dört Dersi

• RAID yedek değildir: İkinci yıl sunucuda RAID de vardı ama plan ona yaslanmadı — RAID disk arızasını tolere eder, silmeyi, bozulmayı ve çift arızayı etmez. Nitekim senaryodaki arıza, RAID yeniden yapılanması sırasında ikinci diskin de sinyal vermesiyle ciddileşmişti.
• Test edilmeyen yedek, umuttur: Birinci yılın "bozuk son üç gece" sürprizi, düzenli tatbikat yapan bir düzende yaşanamazdı — bozulma ilk tatbikatta görünürdü.
• RTO/RPO dönemseldir: Mali müşavirin ocak ayı ile temmuz ayı aynı değildir. Yoğun dönemde yedek sıklığını artıran takvimli kural, yılın geri kalanında gereksiz maliyeti önler.
• Donanım yaşı plan girdisidir: Arızalanan sunucu altı yaşındaydı; yenileme sinyalleri izlense arıza planlı değişime dönüşebilirdi. İkinci yılın izleme düzeni bu dersin ürünüydü.

Kendi Sayılarınızı Belirleyin

Bu senaryonun şablonu her işletmeye uygulanabilir: kritik sistemlerinizi listeleyin, her biri için iki soruyu yönetimle cevaplayın, mevcut yedek düzeninizin bu cevapları gerçekten karşılayıp karşılamadığını bir tatbikatla ölçün. Çoğu işletmede ilk ölçüm, hedefle gerçek arasında rahatsız edici bir boşluk gösterir — ve o boşluğu arıza gününden önce görmek, bu yazının bütün amacıdır.

Yamanlar Bilişim'in Yaklaşımı

Yedekleme projelerimiz teknoloji seçiminden önce bu iki sayının belirlenmesiyle başlar; kurulum RTO/RPO hedeflerine göre boyutlanır, çeyreklik tatbikatlarla süreler ölçülüp raporlanır ve dönemsel kritiklik (beyanname, sezon, yıl sonu) takvime işlenir. Bakım anlaşmalı müşterilerde disk sağlığı ve yedek başarısı günlük izleme kalemidir. Ayrıntılar Yedekleme & Felaket Kurtarma sayfasında.

SSS