Yedek almak ile yedekten geri dönebilmek aynı şey değildir. Birincisi bir yazılımın gece çalışıp bitirdiği iştir; ikincisi, sistem çöktüğünde işletmenin kaç saat durduğu ve kaç saatlik verinin bir daha gelmediğidir. Bu iki süreyi adlandıran iki kısaltma var: RTO ve RPO. Bu yazı ikisini sade dille tanımlıyor, KOBİ ölçeğinde nasıl belirleneceğini anlatıyor ve yedeğin gerçekten geri dönüp dönmediğini nasıl test edeceğinizi gösteriyor.
RTO nedir?
RTO (Recovery Time Objective, kurtarma süresi hedefi), bir sistem durduktan sonra yeniden çalışır hale gelmesi için kabul edilebilir en uzun süredir. Dakika ya da saat olarak ifade edilir ve özünde bir iş kararıdır: muhasebe sunucusu bir gün kapalı kalabilir mi, sipariş sistemi bir saat kapalı kalabilir mi?
RTO’yu belirleyen şey yedeğin ne kadar hızlı kopyalanabildiği kadar, geri dönüşü kimin yürüttüğüdür. Yedek dosyası elinizde olsa bile onu yeni bir sunucuya açacak kişi, o sunucunun kurulumu ve uygulamanın yeniden ayağa kaldırılması sürenin büyük kısmını alır. RTO, yedeğin bulunduğu ana kadar değil, işin yeniden çalışmaya başladığı ana kadar geçen sürenin tamamını kapsar.
RPO nedir?
RPO (Recovery Point Objective, kurtarma noktası hedefi), bir arıza anında kaybetmeyi göze alabileceğiniz en fazla veri miktarıdır ve zamanla ölçülür. Son yedek dün gece alındıysa ve arıza öğleden sonra olduysa kaybınız yaklaşık bir iş günüdür; fiili RPO’nuz 24 saattir.
RPO doğrudan yedekleme sıklığına bağlıdır. Günde bir yedek alan bir işletmenin RPO’su bir günden kısa olamaz. Saatlik yedek RPO’yu bir saate indirir, ama depolama ve ağ yükünü artırır. Bu yüzden RPO her sistem için ayrı belirlenir: sipariş veritabanı için kısa, arşiv dosya sunucusu için uzun bir RPO makul olabilir.
Yedek almak ile geri dönebilmek arasındaki fark nedir?
Yedek almak verinin bir kopyasını üretir; geri dönebilmek, o kopyadan çalışan bir sistem çıkarabilmektir. Aradaki fark felaket gününde ortaya çıkar: kopya bozuk olabilir, eksik olabilir, açılması günler sürebilir ya da onu açacak kişiye ulaşılamayabilir.
Sahada en sık görülen durumlar şunlardır:
- Yedek işi haftalardır hata veriyor, uyarı e-postasını kimse okumuyor.
- Kopya var ama tutarlı değil: veritabanı yedeği açılıyor, uygulama yedeği eski sürümde kalıyor.
- Yedek, üretim sunucusuyla aynı odada ve aynı ağda duruyor; yangın ya da fidye yazılımı ikisini birden vuruyor.
- Geri dönüş adımlarını bilen tek kişi o hafta izinde.
Bu listedeki hiçbir madde yedekleme yazılımının hatası değildir. Hepsi geri dönüş sürecinin hiç sınanmamış olmasından kaynaklanır.
KOBİ için RTO ve RPO nasıl belirlenir?
KOBİ ölçeğinde RTO ve RPO, sistemleri önem sırasına dizip her biri için iki soruyu cevaplayarak belirlenir: bu sistem kaç saat durabilir ve kaç saatlik veriyi kaybedebiliriz? Cevapları işi yürüten kişiler verir; teknik ekip bu cevapları plana çevirir.
- Sistemleri listeleyin: muhasebe, ERP, e-posta, dosya sunucusu, web sitesi, üretim yazılımı.
- Her biri için durma maliyetini kabaca tarif edin: sipariş alamamak, fatura kesememek, üretim hattının durması.
- Her birine bir RTO ve bir RPO yazın. Kısa süreler daha fazla kaynak ister, bu yüzden her sisteme aynı hedefi vermeyin.
- Yedekleme planını bu hedeflere göre kurun: yedekleme sıklığı RPO’yu, geri dönüş yöntemi ve destek modeli RTO’yu belirler.
- Hedefleri yılda bir gözden geçirin; yeni bir sistem devreye girdiğinde listeyi güncelleyin.
Bu tablo çıktığında çoğu işletme, RPO’yu kısaltmanın (daha sık yedek almak) RTO’yu kısaltmaktan (daha hızlı geri dönmek) çok daha kolay olduğunu görür. Kısa RTO için gereken şey daha büyük bir disk değil, provası yapılmış bir geri dönüş süreci ve o anda telefona çıkan bir mühendistir.
Yedek testi neden zorunludur ve nasıl yapılır?
Yedek testi, bir kopyadan gerçekten çalışan bir sistem çıkarılıp çıkarılamadığını arıza olmadan önce gösteren tek yöntemdir. Test edilmemiş yedek bir varsayımdır; test edilmiş yedek bir plandır.
Pratik bir test düzeni şöyle kurulur:
- Ayda bir, rastgele bir sunucuyu ayrı bir ortama geri yükleyin ve uygulamanın açıldığını doğrulayın.
- Geri dönüşün kaç dakika sürdüğünü not edin. Bu sayı sizin gerçek RTO’nuzdur; hedefinizle karşılaştırın.
- Geri yüklenen verinin tarihine bakın. Bu da gerçek RPO’nuzdur.
- Yılda bir tam senaryo çalışın: ana sunucu yok sayılır, iş bir gün boyunca yedekten yürütülür.
- Her testte adımları yazılı hale getirin; süreç tek kişinin hafızasında kalmasın.
Katmanlı yedek ve değiştirilemez kopya RTO ve RPO’yu nasıl etkiler?
Katmanlı yedek, günlük, haftalık ve aylık kopyaları ayrı tutarak farklı geçmiş noktalarına dönebilmeyi sağlar; değiştirilemez kopya ise saklama süresi dolmadan silinemediği için fidye yazılımı saldırısında bile geri dönülecek temiz bir nokta bırakır.
Günlük kot dünkü hatadan dönmek için, haftalık kot günlerdir fark edilmeyen bir bozulmadan dönmek için, aylık çekirdek ise aylar önce başlamış bir sızmadan önceki temiz duruma dönmek için kullanılır. RPO burada tek bir sayı olmaktan çıkar; her katman farklı bir geri dönüş noktası sunar. RTO tarafında ise kopyanın nerede durduğu belirleyicidir: üretim ağından ayrı bir düzlemde ve şirket dışında duran kopya, yerel bir felakette de erişilebilir kalır.
Layer Sistem’in LayerBackup hizmeti bu mimariyi Veeam Cloud Connect üzerinden, resmî Veeam Cloud Service Provider statüsüyle kendi altyapısında işletir. Yedekler kaynaktan çıktığı anda şifrelenir ve İstanbul’daki veri merkezinde, Türkiye sınırları içinde saklanır. Günlük, haftalık ve aylık kotlar ayrı tutulur; en derindeki aylık çekirdek değiştirilemez biçimde korunur. Kurtarma süresi ve kurtarma noktası hedefleri plan aşamasında kurumla birlikte belirlenir. Geri dönüş anında ticket kuyruğu yoktur; altyapıyı tanıyan mühendis telefondadır ve dönülecek kot birlikte seçilir. Kısa RTO, kâğıt üzerindeki hedeften çok bu anın nasıl yönetildiğine bağlıdır.
Sonuç
Yedek almak bir yazılımın işidir; geri dönebilmek işletmenin kararıdır. RTO ve RPO’yu her sistem için yazın, yedekleme planını bu hedeflere göre kurun ve yedeği düzenli olarak geri yükleyerek test edin. Felaket gününde elinizde bir kopya değil, denenmiş bir yol olsun.
Konuyu derinleştirmek için: Fidye yazılımına karşı değiştirilemez yedek ve Kurumsal felaket kurtarma çözümü nasıl seçilir.
İletişim: +90 850 500 0 166 | [email protected] | www.layersistem.com