YAZILIM GELİŞTİRME
Yazılımda Yedekleme ve Felaket Kurtarma Planı Nasıl Yapılır?
Hiç test edilmemiş bir yedek, yedek sayılmaz. Yedekleme ve felaket kurtarma planını RPO/RTO kararlarına, yedek türlerine ve düzenli geri yükleme testlerine bağlayan iş odaklı bir rehber.
İçindekiler
Çoğu ekip "yedek alıyoruz" dediğinde aslında bir soruyu atlar: Bu yedekten gerçekten geri dönebiliyor muyuz? Hiç test edilmemiş bir yedek, teknik olarak bir dosyadır; iş açısından bir güvence değildir. Bir sorun yaşandığında yedeğin bozuk, eksik ya da geri yüklenemez olduğunu fark etmek, yedek hiç olmamasından çok daha pahalıya mal olur.
Felaket kurtarma planı; teknik bir detay gibi görünse de aslında bir iş kararıdır. Ne kadar veri kaybını ve ne kadar kesintiyi kabul edebileceğinizi işin sahibi belirler; biz bu kararları hangi yedekleme ve kurtarma kurgusuna bağlayacağınızı planlar ve test ederiz. Aşağıda bu kararı veren bir yöntem var.
Önce iki soruyu işin sahibi yanıtlasın: RPO ve RTO
Yedekleme planının temeli iki sorudur. Birincisi: Bir sorun anında en fazla ne kadarlık veriyi kaybetmeyi göze alabilirsiniz? Buna RPO (kabul edilebilir veri kaybı) denir. İkincisi: Sistem ne kadar süre kapalı kalırsa iş kabul edilemez hale gelir? Buna da RTO (kabul edilebilir kesinti) denir. Bu iki sayı teknik değil, iş kararıdır: maliyet, risk ve müşteri beklentisi arasında bir denge kurar.
RPO'yu küçültmek (daha sık yedek) ve RTO'yu küçültmek (daha hızlı geri dönüş) genellikle maliyeti artırır. Bu yüzden her sistem için aynı hedefi koymak gerekmez; kritik olanla ikincil olanı ayırmak daha gerçekçidir. Aşağıdaki tablo bu dengeyi temsili senaryolarla gösterir.
| Senaryo | RPO (kabul edilebilir veri kaybı) | RTO (kabul edilebilir kesinti) | Önlem |
|---|---|---|---|
| Sipariş/ödeme veritabanı | Dakikalar | Saatler içinde | Sık yedek + çoğaltma, hazır geri yükleme adımları |
| Kurumsal site içeriği | Saatler | Yarım gün | Günlük yedek, şehir dışı kopya |
| İç raporlama/arşiv | Günler | Birkaç gün | Daha seyrek yedek, düşük öncelik |
Yedek türü, sıklık ve nerede durduğu
RPO ve RTO hedefleri belli olunca yedekleme kurgusu bunlara göre tasarlanır. Üç soruyu birlikte yanıtlamak gerekir: hangi tür yedek, ne sıklıkla ve nerede saklanacak. Tek bir sunucuda duran, aynı sistem çökünce birlikte kaybolan bir yedek güvence sayılmaz.
- Yedek türü: tam yedek mi, yoksa sadece değişenleri alan artımlı/fark yedek mi? Çoğu kurguda ikisinin birleşimi kullanılır.
- Sıklık: yedek aralığı RPO'yu belirler. Günde bir yedek alıyorsanız en kötü senaryoda bir günlük veriyi kaybedersiniz.
- Şehir dışı/ayrı kopya: en az bir kopya ana sistemden fiziksel veya mantıksal olarak ayrı yerde dursun; aynı kaza ikisini birden silememeli.
- Saklama süresi: yedekleri ne kadar geriye kadar tutacağınız (ör. son günler + aylık arşiv) baştan kararlaştırılsın.
Düzenli geri yükleme testi ve net sorumluluk
Bir yedeğin değeri, ancak gerçekten geri yüklenebildiğinde ortaya çıkar. Bu yüzden yedek almak kadar, o yedekten geri dönmeyi düzenli olarak test etmek de plana dâhil olmalıdır. Test edilmeyen bir kurtarma planı, çoğu zaman en kötü anda açığını verir.
- Geri yükleme testini takvime bağlayın; "ara sıra" yerine belirli aralıklarla yapılan bir prova olsun.
- Testte sadece dosyanın açılmasına değil, sistemin çalışır hale gelip gelmediğine ve verinin bütünlüğüne bakın.
- Her adımın bir sorumlusu olsun: yedeği kim izliyor, sorun anında kim kurtarmayı başlatıyor, kimi bilgilendiriyor?
- Kurtarma adımlarını yazılı tutun; kritik bilgi tek bir kişinin aklında kalmasın.
UYGULAMA ÖZETİ
Yedekleme ve felaket kurtarma kontrol listesi
Karar ve kurgu
- Her kritik sistem için RPO ve RTO işin sahibiyle belirlendi.
- Yedek türü, sıklık ve saklama süresi bu hedeflere göre tasarlandı.
- En az bir kopya ana sistemden ayrı yerde tutuluyor.
Test ve sorumluluk
- Geri yükleme testi düzenli bir takvime bağlandı.
- Kurtarma adımları yazılı ve güncel.
- İzleme, kurtarma ve bilgilendirme için sorumlular atandı.
SSS
Sık sorulan sorular
RPO ve RTO nedir, basitçe açıklar mısınız?
RPO, bir sorun anında geriye dönük ne kadarlık veriyi kaybetmeyi göze alabildiğinizdir; örneğin "en fazla son 1 saat" demek RPO'nuzun 1 saat olduğu anlamına gelir. RTO ise sistemin en fazla ne kadar süre kapalı kalabileceğidir; "en geç 4 saatte ayakta olmalı" demek RTO'nuzun 4 saat olduğunu söyler. İkisi de teknik değil, iş kararıdır.
Yedeğimiz var ama test etmiyoruz; sorun mu?
Evet. Hiç test edilmemiş bir yedek, geri yüklenebileceğinin garantisi değildir; bozuk, eksik ya da uyumsuz olabilir ve bunu ancak kötü günde fark edersiniz. Düzenli geri yükleme testi, yedeğin gerçekten işe yarayıp yaramadığını önceden gösterir.
Sıfır veri kaybı garantisi verebilir misiniz?
Hayır, hiçbir dürüst kurgu "sıfır veri kaybı" garantisi veremez. Yapabileceğimiz, sizin belirlediğiniz kabul edilebilir veri kaybı ve kesinti hedeflerine (RPO/RTO) uygun bir yedekleme ve kurtarma planı kurmak, test etmek ve riski bu hedefler içinde yönetilebilir kılmaktır.
BİRİNCİL KAYNAKLAR
Kaynaklar ve İleri Okuma
- Google — Faydalı, güvenilir, insan öncelikli içerik (yeni sekmede açılır)
İçeriği gerçek kullanıcı değeri ve dürüstlük üzerinden kurmak.
YAZAR
Next Medya Strateji ve Teknoloji Ekibi
Özel yazılım ve operasyon
Next Medya ekibi; yedekleme, kurtarma ve sistem geçişini iş sürekliliğiyle birlikte ele alır. Bu rehberlerdeki senaryolar, karar yöntemini açıklayan temsili örneklerdir.
İLGİLİ HİZMET
Veri taşıma ve sistem geçişiSONRAKİ OKUMA
İlgili diğer analizler
YAZILIM GELİŞTİRME
Web Formundan CRM’e Nitelikli Talep Akışı
Web formu ve CRM arasında alan eşleme, mükerrer kayıt, talep sahibi ve satış aşamalarını planlayın. Kesinti ve tekrar durumları için kontrol listesi kullanın.
Okumaya devam edinYAZILIM GELİŞTİRME
Ürün Konfigüratöründe Seçenek ve Fiyat Kuralları
Ürün konfigüratöründe uyumsuz seçenekleri, üretim kısıtlarını, fiyat sürümünü ve teklif onayını tasarlayın. Temsili örnek ve kabul matrisiyle kapsamı belirleyin.
Okumaya devam edinKurtarma planınızı birlikte kurgulayalım ve test edelim
Sistemlerinizi ve kabul edilebilir kesinti/veri kaybı beklentinizi paylaşın; yedekleme ve kurtarma planını birlikte planlayıp test edelim.
Projenizi görüşelim