Yedekleme (Backup) Nedir?

RPO ve RTO: planın iki sorusu

“Yedeğimiz var” cümlesi tek başına bir şey söylemez. Yedekleme planı iki soruya verilen cevapla tanımlanır:

RPO yedekleme sıklığını, RTO ise geri yükleme yöntemini belirler. Kurumsal bir tanıtım sitesi için bir günlük RPO kabul edilebilirken, sipariş ve ödeme alan bir sistemde dakikalarla ölçülen bir RPO gerekebilir.

3-2-1 kuralı

Yaygın kabul gören bu pratik kural, yedeklerin aynı olayla birlikte yok olmamasını hedefler:

• 3 kopya: canlı veri ve en az iki yedek.
• 2 farklı depolama türü veya ortamı: örneğin sunucu diski ve nesne depolama servisi.
• 1 kopya başka bir konumda: farklı bir veri merkezi, bölge ya da sağlayıcı.

Günümüzde buna sık eklenen bir şart, kopyalardan birinin değiştirilemez (immutable) veya çevrimdışı olmasıdır. Fidye yazılımı veya ele geçirilmiş bir yönetici hesabı, sunucudan erişilebilen her yedeği de şifreleyebilir ya da silebilir. Aynı sunucudaki bir klasöre alınan yedek ise sunucuyla birlikte kaybolur; bu nedenle tek başına yedek sayılmamalıdır.

Neler yedeklenmeli?

• Veritabanı: Sitenin ya da uygulamanın asıl değeri genellikle buradadır.
• Kullanıcıların yüklediği dosyalar: Görseller, belgeler, faturalar. Veritabanı yedeği bunları içermez.
• Yapılandırma: Web sunucusu ayarları, cron tanımları, DNS kayıtları ve gizli bilgiler (şifrelenmiş olarak).
• Kod: Git repository'si kodun geçmişini tutar ama verinin yedeği değildir.

PostgreSQL belgeleri üç temel yaklaşım tanımlar: SQL dökümü (pg_dump), dosya sistemi düzeyinde yedek ve WAL arşivlemeyle sürekli yedekleme. Sonuncusu, veritabanını geçmişteki belirli bir ana döndürmeye (point-in-time recovery) imkân verir ve küçük RPO hedefleri için gereklidir.

# Mantıksal yedek al (özel format, sıkıştırılmış)
pg_dump --format=custom --file=/yedek/magaza-2026-10-03.dump magaza

# Ayrı bir test veritabanına geri yükle
createdb magaza_geri_yukleme_testi
pg_restore --dbname=magaza_geri_yukleme_testi /yedek/magaza-2026-10-03.dump

Denenmemiş yedek, varsayımdır

Yedekleme işinin en sık atlanan kısmı geri yüklemedir. Aylarca “başarılı” görünen bir görev boş dosya üretiyor, yanlış veritabanını alıyor ya da şifreleme anahtarı kaybolmuş olabilir. Bunu ancak gerçek bir geri yükleme ortaya çıkarır:

• Belirli aralıklarla yedeği ayrı bir ortama geri yükleyin ve uygulamanın o veriyle açıldığını doğrulayın.
• Geri yüklemenin ne kadar sürdüğünü ölçün; gerçekçi RTO bu sayıdır.
• Başarısız veya beklenenden çok küçük yedekler için otomatik uyarı kurun.
• Adımları, sorumlu kişiyi aranamadığında bile başkasının uygulayabileceği şekilde yazılı tutun.

Felaket kurtarma ve güvenlik

Felaket kurtarma (disaster recovery) planı, tek bir dosyanın geri yüklenmesinden daha büyük senaryoları kapsar: sunucunun, veri merkezinin ya da sağlayıcı hesabının tamamen erişilemez olması. Planda yeni altyapının nerede ve nasıl kurulacağı, DNS'in nasıl yönlendirileceği ve kimin karar vereceği yer alır. Bu bağlamda yüksek erişilebilirlik ile yedeklemeyi karıştırmamak gerekir; ölçeklenebilirlik için kurulan canlı kopyalar, hatalı bir silme işlemini de anında çoğaltır.

Yedekler, canlı sistemdeki tüm veriyi bir arada içerdiği için saldırganlar açısından değerli hedeflerdir. Bekleyen yedekleri şifrelemek, yedek depolama erişimini üretim sunucusunun kimlik bilgilerinden ayırmak ve saklama sürelerini belirlemek gerekir. Kişisel veri içeren yedekler de KVKK kapsamındadır: verinin canlı sistemden silinmesi, onun yedeklerde süresiz kalabileceği anlamına gelmez. Saklama ve imha politikası yedekleri de kapsamalıdır.