Yedekleme Nedir, Hangi İki Ölçüte Göre Planlanır?

---

Yedekleme çoğu yerde "bir kopya al" diye anlatılıyor. Oysa asıl soru kopyanın varlığı değil: kesinti olduğunda ne kadar sürede ayağa kalkacaksınız ve hangi ana kadarki veriyi geri getirebileceksiniz?

Bu yazı yedeklemenin tanımını, planlamada kullanılan iki temel ölçütü ve kopyaların nerede saklanması gerektiğini standart kaynaklara dayanarak açıklıyor.

Tanım​

RFC 4949 Internet Güvenlik Sözlüğü yedeği, sistem kaynaklarının kaybına rağmen sistem işlevlerini yerine getirmenin alternatif yolu olarak tanımlıyor.

Verdiği örnek veri tarafına bakıyor: aslı kaybolur veya zarar görürse kullanılmak üzere tutulan yedek kopya; tercihen aslından ayrı yerde saklanan bir kopya.

Sözlük bunu arşivden ayırıyor. Arşiv, denetim hizmetini veya sistem bütünlüğünü desteklemek gibi tarihsel ve başka amaçlarla göreli olarak uzun süre saklanan veri topluluğu. Yani arşiv geçmişi tutmak, yedek geri dönebilmek için var.

• Yedek: Kayıp durumunda işlevi sürdürmenin alternatif yolu.
• Tercih: Kopyanın aslından ayrı yerde durması.
• Arşiv değil: Arşivin amacı uzun süreli saklama.

İki ölçüt: RTO ve RPO​

NIST SP 800-34 Rev. 1 planlamayı iki ölçüte bağlıyor.

Kurtarma Süresi Hedefi (RTO), bir sistem kaynağının diğer sistem kaynakları ve desteklenen iş süreçleri üzerinde kabul edilemez bir etki doğmadan önce ne kadar süre kullanılamaz kalabileceğinin azamisini tanımlıyor. Belgeye göre bu değeri belirlemek, azami tolere edilebilir kesintiyi karşılamaya en uygun teknolojileri seçmek için önemli.

Kurtarma Noktası Hedefi (RPO) ise farklı bir soruya yanıt veriyor: kesinti veya sistem arızası öncesinde, iş süreci verisinin hangi ana kadar geri getirilebileceği. Bu, en güncel yedek kopyaya göre belirleniyor.

Belge farkı da açıkça koyuyor: RPO, azami tolere edilebilir kesintinin parçası sayılmıyor; iş sürecinin kurtarma sırasında ne kadar veri kaybını kaldırabileceğinin bir göstergesi.

Püf nokta' Alıntı:

RTO "ne kadar sürede döneriz", RPO "ne kadarını kaybederiz" sorusunu yanıtlıyor. İkisi ayrı kararlar.

Genişletmek için tıkla ...

Politika neyi belirlemeli?​

Belge sistem verisinin düzenli yedeklenmesi gerektiğini söylüyor ve politikanın neleri içermesi gerektiğini sıralıyor.

Önce sıklık ve kapsam: politikalar asgari yedekleme sıklığını ve kapsamını, verinin kritikliğine ve yeni bilginin eklenme sıklığına göre belirlemeli. Örnek olarak günlük veya haftalık, artımlı veya tam yedek seçenekleri veriliyor.

Ardından saklama ayrıntıları geliyor. Politika; saklanan verinin konumunu, dosya adlandırma kurallarını, ortam döndürme sıklığını ve verinin tesis dışına taşınma yöntemini belirlemeli.

Yöntem seçimi de keyfi değil. Belgeye göre yedekleme için seçilecek yöntem, sistemin ve verinin erişilebilirlik ile bütünlük gereksinimlerine dayanmalı.

Kopya nerede duracak?​

NIST belgesi tesis dışı saklamayı iyi bir iş pratiği sayıyor. Ticari veri saklama tesisleri ortamları arşivlemek ve veriyi tehdit edici unsurlardan korumak için özel olarak tasarlanıyor.

Süreç de tarif ediliyor: veri kurumun kendi tesisinde yedekleniyor, ardından etiketlenip paketlenerek saklama tesisine taşınıyor. Kurtarma veya test amacıyla gerektiğinde kurum saklama tesisiyle iletişime geçip belirli verinin kuruma ya da alternatif bir tesise getirilmesini istiyor.

Sunucu tarafında ayrı bir öneri var: birden çok sunucu bulunan ortamlarda depolamanın her sunucuya ayrılması yerine merkezileştirilmesi öneriliyor. Birden çok sunucunun verisinin merkezileştirilmesi, tesis dışı saklama için ortak bir yedek alınmasına imkân veriyor.

Belge yedeklenecek veri miktarının büyüklüğü nedeniyle, yedekleme için gereken veri aktarımlarına ayrı ve adanmış bir ağ kullanılmasını da öneriyor; böylece birincil ağ üretim trafiğine kalıyor ve yedekleme süreci etkilenmiyor.

Yedek geri yüklenmiyorsa yedek değildir​

Tanımdaki "işlevi sürdürmenin alternatif yolu" ifadesi, kopyanın alınmasıyla değil geri yüklenmesiyle anlam kazanıyor. RPO da zaten en güncel yedek kopyaya göre hesaplanıyor; o kopya açılmıyorsa hedef kâğıt üstünde kalıyor.

Bu yüzden sınama ayrı bir iş. Veritabanı tarafında geri yükleme provasını veritabanı yedekleme yazımızda, barındırma tarafında aynı soruyu hosting yedeği testi yazımızda ele almıştık.

Erişim tarafında da benzer bir mantık var: kimlik doğrulama yönteminiz çalışmazsa geri dönüş yolu gerekiyor; bunu kurtarma planı yazımızda anlatmıştık.

Sık Sorulan Sorular​

Yedekleme nedir?
RFC 4949'a göre sistem kaynakları kaybolsa bile işlevleri sürdürmenin alternatif yolu; veride aslından ayrı tutulan kopya.

RTO ne anlama geliyor?
Bir kaynağın kabul edilemez etki doğmadan kullanılamaz kalabileceği azami süre.

RPO ne anlama geliyor?
Kesinti öncesinde verinin hangi ana kadar geri getirilebileceği; en güncel yedek kopyaya göre belirleniyor.

Ne sıklıkla yedek almalı?
NIST'e göre sıklık, verinin kritikliğine ve yeni bilginin eklenme sıklığına göre politikada belirleniyor.

Yedek nerede saklanmalı?
Tesis dışı saklama iyi bir iş pratiği sayılıyor; kopyanın aslından ayrı yerde durması tercih ediliyor.

Özetle​

Yedekleme, kayıp durumunda işlevi sürdürebilmek için tutulan ayrı kopya. Planlamanın iki ölçütü var: RTO kesintinin süresini, RPO kaybedilebilecek veri miktarını sınırlıyor. Politika sıklığı, kapsamı, saklama yerini, adlandırmayı ve taşıma yöntemini belirlemeli; kopyanın tesis dışında durması öneriliyor. Ve en önemlisi, geri yüklenebildiği sınanmamış bir kopya hedefleri karşılamıyor.

Son geri yükleme provanızı ne zaman yaptınız?

Güncelleme: 2 Eylül 2026. RFC 4949 ve NIST SP 800-34 Rev. 1 kontrol edildi.

---