Yedekleme Stratejisi Nasıl Planlanır? Blog, E‑Ticaret ve SaaS Siteleri İçin RPO/RTO Rehberi

Yedekleme stratejisi neden bugün planlanmalı?

Birçok web sitesi sahibi ve yazılım ekibi, yedeklemeyi sadece “hosting firmanızın otomatik aldığı bir kopya” olarak görüyor. Gerçekte ise yedekleme, hem teknik hem de iş tarafı hedefleri olan bir strateji konusu. Özellikle blog, e‑ticaret ve SaaS projelerinde tek bir kayıp sipariş, tek bir silinen veritabanı tablosu ya da birkaç saatlik kesinti; itibar, gelir ve hukuk tarafında ciddi sonuçlar doğurabiliyor.

Yedekleme stratejisini sağlam kurmak için önce şu sorulara net cevap vermek gerekiyor:

• En fazla ne kadar veri kaybını göze alabilirsiniz?
• Siteniz en fazla ne kadar süre kapalı kalabilir?
• Bu hedeflere ulaşmak için hosting altyapınızda neleri doğru kurgulamanız gerekiyor?

Bu soruların teknik karşılığı RPO ve RTO kavramları. Yani yedeklemenin “ne sıklıkla” alınacağı değil, ne kadar veri kaybına ve ne kadar kesinti süresine tahammül edebileceğiniz. Biz DCHost tarafında, yeni bir blog, ölçeklenen bir e‑ticaret projesi ya da çok kiracılı (multi‑tenant) bir SaaS ürünü için altyapı planlarken, ilk toplantılarda RPO/RTO konusunu mutlaka masaya yatırıyoruz. Bu yazıda, benzer bir yaklaşımı siz de kendi siteniz için uygulayabilin diye adım adım bir rehber hazırladım.

Temel kavramlar: RPO, RTO, SLA ve veri sınıflandırması

RPO (Recovery Point Objective) nedir?

RPO, en fazla ne kadar veri kaybını kabul edebileceğinizi tanımlar. Yani geri dönüş yaptığınızda verinizin ne kadar eski olmasına razısınız?

• RPO = 24 saat: “Dün geceki yedeğe dönsem, sorun değil” demektir.
• RPO = 1 saat: “En fazla son 1 saatteki işlemler kaybolabilir” demektir.
• RPO = 5 dakika: “Neredeyse gerçek zamanlı replikasyon istiyorum” beklentisidir.

Örnekler:

• Kişisel blog: Günde bir yazı giriyorsanız, 12‑24 saatlik veri kaybı sizin için makul olabilir.
• E‑ticaret sitesi: 1 saatlik sipariş kaybı bile kabul edilemez olabilir; RPO genelde 5‑15 dakika aralığına çekilir.
• SaaS uygulaması: Kullanıcıların sürekli veri girdiği CRM, proje yönetimi vb. senaryolarda RPO sıklıkla dakika seviyesine indirilmeye çalışılır.

RTO (Recovery Time Objective) nedir?

RTO, bir kesinti sonrası sistemi tekrar ayağa kaldırmak için tolere edebileceğiniz maksimum süredir.

• RTO = 4 saat: “Dört saat içinde site tekrar çalışmalı” beklentisi.
• RTO = 30 dakika: “Yarım saatte ayağa kaldırmak zorundayım” yaklaşımı.
• RTO = 5 dakika: Aktif‑aktif veya çok agresif otomatik failover kurgularını gerektirir.

RTO sadece yedeği geri yüklemekle ilgili değildir; DNS yönlendirmeleri, SSL, uygulama konfigürasyonları, cache, kuyruklar, üçüncü parti servis bağlantıları gibi tüm parçaları kapsar. Bu nedenle felaket kurtarma planı nasıl yazılır rehberimizde de vurguladığımız gibi, RTO hedefi mutlaka dokümante edilmiş net bir aksiyon planıyla desteklenmelidir.

SLA ve iş gereksinimleriyle ilişki

Birçok e‑ticaret ve SaaS ürünü için müşterilere verilen SLA sözleri (örneğin %99.9 uptime) doğrudan RPO ve RTO hedeflerini etkiler. SLA’nız ne kadar sıkıysa:

• Yedekleme sıklığınız o kadar artar (RPO küçülür).
• Otomatik failover, çok bölgeli mimari gibi çözümlere ihtiyaç duyarsınız (RTO kısalır).

RPO ve RTO’yu, pazarlama sunumlarında yer alan SLA sözleriyle uyumlu hale getirmeden, yedekleme planı yaptım demek aslında eksik kalıyor.

Veri sınıflandırması: Her veri eşit kritik değildir

Yedekleme stratejisinde ikinci kritik yaklaşım, veri sınıflandırmasıdır. Yani hangi verinin ne kadar kritik olduğunu ayrı ayrı değerlendirmek:

• Ürün verileri (e‑ticaret), müşteri kayıtları (SaaS): Yüksek önem, sık yedek, uzun saklama süresi.
• Loglar, geçici cache verileri: Daha düşük önem, kısa saklama süresi, bazen hiç yedeklenmeyebilir.
• Medya dosyaları (görseller, dokümanlar): Boyutları büyük, değişim sıklığı düşük; farklı depolama stratejisi gerektirir.

Böylece hem disk maliyetini kontrol altında tutar, hem de geri dönüş senaryolarında gerçekten kritik olan veriye odaklanırsınız.

Farklı site türleri için gerçekçi RPO/RTO hedefleri

Blog ve içerik siteleri

Blog, haber ve kurumsal içerik sitelerinde en kritik veri genellikle veritabanı içeriği (yazılar, sayfalar, yorumlar) ve medya dosyalarıdır. Sipariş, ödeme gibi anlık finansal akışlar olmadığı için, iş tarafı beklentileri biraz daha rahattır.

Tipik hedefler:

• RPO: 12‑24 saat (günlük yedek çoğu senaryoda yeterli).
• RTO: 2‑8 saat (kritikliğe göre, örneğin bir kişisel blog için birkaç saatlik kesinti kabul edilebilir).

Eğer yüksek trafikli bir içerik siteniz varsa ve arama motoru trafiği sizin için hayatiyse, yüksek trafikli blog ve haber siteleri için hazırladığımız hosting rehberindeki ölçeklendirme önerileriyle bu yedekleme stratejisini birleştirmeniz mantıklı olur.

E‑ticaret siteleri

E‑ticaret tarafında işler ciddi biçimde değişiyor. Çünkü artık sadece içerik değil, her dakika değişen bir stok, fiyat, sepet ve sipariş akışı söz konusu. Burada kaybedilen her dakika, doğrudan ciro kaybı anlamına gelebilir.

E‑ticaret için tipik hedefler:

• RPO: 5‑30 dakika arası (en azından veritabanı için).
• RTO: 15‑60 dakika (uygulamanın yeniden ayağa kalkması için).

Özellikle kampanya dönemleri, özel günler ve yoğun trafik alan reklam kampanyalarında bu hedefler daha da sıkılaşabilir. Sepet ve ödeme adımlarını izlemek için loglama ve alarm kuralları kullanıyorsanız, bu veri akışlarının da felaket senaryolarında tekrar ayağa kalkmasını sağlamalısınız. Bunun için e‑ticaret sepet ve ödeme adımlarını izleme rehberimizde anlattığımız log stratejilerini yedekleme planınızla birlikte düşünmek iyi bir pratik.

SaaS uygulamaları

SaaS ürünlerinde durum çoğu zaman e‑ticaretten bile kritik. Çünkü:

• Veri sadece sizin değil, onlarca/yüzlerce müşterinizin.
• Müşterileriniz, ürünü işlerinin kalbinde kullanıyor (CRM, proje yönetimi, finans, insan kaynakları vb.).
• SLA sözleri, sözleşmeler, KVKK/GDPR gibi regülasyonlar devreye giriyor.

Bu nedenle SaaS için tipik hedefler:

• RPO: 1‑15 dakika arası (özellikle veritabanı için sürekli replikasyon veya sık incremental yedek).
• RTO: 5‑30 dakika (en azından core servisler için).

SaaS tarafında ayrıca veri saklama politikaları, müşterinin hesabını kapattığında verinin ne kadar süre tutulacağı gibi ek sorular da devreye giriyor. Bu konuyu daha detaylı çalışan projeler için SaaS uygulamaları için müşteri verisi yedekleme ve saklama politikaları rehberimizi özellikle öneririm.

3‑2‑1 kuralı ve site türüne göre yedek topolojisi

3‑2‑1 kuralını hatırlayalım

İyi bir yedekleme stratejisinin temel taşı hâlâ 3‑2‑1 kuralıdır:

• 3 kopya veri (1 canlı, 2 yedek).
• 2 farklı ortam (örneğin farklı disk türleri ya da dosya sistemi).
• 1 adet farklı lokasyon (farklı veri merkezi ya da coğrafya).

Bu yaklaşımı paylaşımlı hosting, VPS/dedicated ya da colocation fark etmeksizin her yapıda uygulayabilirsiniz. Teknik detaylarını anlattığımız 3‑2‑1 yedekleme stratejisi neden işe yarıyor rehberimizi okursanız, burada özetlediğimiz konseptlerin pratik kurulum adımlarını da bulursunuz.

Blog için örnek topoloji

• 1. Kopya: Canlı veritabanı ve dosya sistemi (web sunucusu).
• 2. Kopya: Aynı sunucuda veya aynı veri merkezinde günlük otomatik yedek (snapshot, full backup).
• 3. Kopya: Farklı bir veri merkezindeki object storage’a (S3 uyumlu) haftalık veya günlük yedek replikasyonu.

Burada en büyük risk genelde “aynı fiziksel sunucudaki” yedeklere güvenmek. Disk arızası, yanlışlıkla silme veya güvenlik ihlalinde hem canlı verinizi hem de yedeğinizi aynı anda kaybedebilirsiniz. Bu yüzden en az bir kopyanın DCHost altyapısında farklı bir depolama katmanında ya da farklı bir bölgede tutulmasını öneriyoruz.

E‑ticaret için örnek topoloji

• 1. Kopya: Canlı veritabanı (ayrı bir VPS/dedicated veritabanı sunucusu önerilir) ve uygulama sunucusu.
• 2. Kopya: Aynı veri merkezinde sık incremental veritabanı yedeği (örneğin 5‑15 dakikada bir WAL/binlog arşivleme) + saatlik dosya yedeği.
• 3. Kopya: Farklı bölgede object storage’a günlük tam yedek + daha seyrek (örneğin haftalık) uzun süre saklanan arşiv kopyaları.

Böylece lokal bir arıza durumunda hızlı dönüş (RTO) için aynı bölgede güncel yedeğiniz olur, veri merkezi ölçeğinde bir problemde ise farklı bölgede daha geriden de olsa kurtarıcı bir kopyaya sahipsiniz.

SaaS için örnek topoloji

• 1. Kopya: Canlı veritabanı kümesi (primary/replica veya cluster) ve çoklu uygulama sunucuları.
• 2. Kopya: Aynı bölgede sürekli log tabanlı yedekleme (Point‑in‑Time Recovery destekli) + dosya sistemi için hourly snapshot.
• 3. Kopya: Başka bir bölgede hem veritabanı dump’ı hem de dosya yedekleri için şifreli object storage + isteğe göre immutable (değiştirilemez) yedekler.

Burada ayrıca müşteri bazında (tenant bazlı) yedeklerden, tek bir müşterinin verisini geri döndürebilmeyi sağlayan stratejilerden de bahsetmek gerekir. Bu genellikle veritabanı tasarımı ve yedekleme katmanının birlikte planlanmasını gerektirir.

Hosting tarafında uygulanabilir yedekleme senaryoları

Paylaşımlı hosting veya yönetilen WordPress/blog siteleri

Paylaşımlı hosting veya yönetilen WordPress planlarında, kontrol paneli üzerinden sunucu yedeği almak oldukça kolaydır. Ancak burada sık gördüğümüz bazı hatalar var:

• Sadece WordPress eklentisi ile yedek almak ve bunu aynı sunucuya kaydetmek.
• Hiç geri yükleme testi yapmadan, yedek almanın yeterli olduğunu varsaymak.
• Yalnızca veritabanını, yalnızca dosyaları ya da sadece paneldeki “full backup” seçeneğini kullanmak; tüm senaryolar için uygun olduğunu düşünmek.

DCHost üzerinde paylaşımlı hosting kullanıyorsanız, cPanel ya da benzeri bir panel üzerinden:

• Otomatik günlük/haftalık yedeklerin açık olduğundan emin olmalı,
• Belirli aralıklarla manuel tam yedek alıp farklı lokasyonda (yerel bilgisayarınız, başka bir sunucu, object storage vb.) saklamalı,
• En azından yılda birkaç kez test geri yükleme yapmalısınız (farklı bir alt alan adı veya staging ortamına).

Bunun pratik adımlarını görmek için cPanel’de tüm siteyi yedekleme ve geri yükleme rehberimize ve WordPress özelindeki senaryolar için WordPress yedekleme stratejileri yazımıza göz atabilirsiniz.

VPS/dedicated üzerinde çalışan e‑ticaret ve SaaS uygulamaları

VPS veya dedicated sunucu kullandığınızda çok daha esnek ama bir o kadar da sorumluluk gerektiren bir dünyaya geçiyorsunuz. Burada hem dosya sistemi hem de veritabanı için ayrı ayrı strateji belirlemek zorundasınız.

Önerdiğimiz genel yaklaşım:

• Veritabanı için uygulama‑tutarlı yedekler: MySQL/MariaDB için mysqldump, XtraBackup ve Point‑in‑Time Recovery karşılaştırmasını anlattığımız rehberi; PostgreSQL için ise WAL arşivli çözümleri inceleyin.
• Dosya sistemi için snapshot tabanlı yedekler: LVM snapshot + fsfreeze gibi tekniklerle, yedek alınırken disk tutarlılığını korumak mümkün. Bunu adım adım anlattığımız uygulama‑tutarlı yedekler rehberine mutlaka göz atın.
• Uzak depolama: Yedekleri aynı VPS’te tutmak yerine, DCHost altyapısındaki S3 uyumlu depolama gibi harici bir ortama kopyalamak.

Bu senaryolarda; yedekleme aracı olarak restic, Borg gibi deduplikasyon destekli çözümler kullanıp, hedef olarak S3 uyumlu bir endpoint seçmek hem maliyet hem de esneklik açısından oldukça avantajlıdır. Ayrıca yedek akışını cron veya systemd timer ile otomatikleştirip, hata durumlarında e‑posta/SMS/Slack uyarısı alacak şekilde kurgulamak gerekir.

Çok bölgeli ve felaket kurtarma (DR) senaryoları

Daha sıkı RPO/RTO hedefleri olan e‑ticaret ve SaaS projelerinde, yedek sadece “geri dönüş” için değil, aktif felaket kurtarma için de kullanılır. Örneğin:

• Birincil bölge: Canlı trafik ve ana veritabanı kümesi.
• İkincil bölge: Asenkron replikasyon alan, düşük trafikli standby ortam.
• Yedek: Hem birincil hem ikincil bölgeden bağımsız object storage üzerinde versiyonlu ve şifreli yedekler.

Burada S3/MinIO gibi object storage çözümlerinde çapraz bölge replikasyon (Cross‑Region Replication) kurmak oldukça yaygın bir yöntem. Teknik detaylarına adım adım bakmak isterseniz, S3/MinIO’da çapraz bölge replikasyon rehberimiz, DR runbook ile birlikte nasıl planlanacağını örneklerle gösteriyor.

Adım adım yedekleme stratejisi planlama

1. Varlık envanteri çıkarın

Önce neyi yedekleyeceğinizi bilmeniz gerekiyor. Detaylı bir liste hazırlayın:

• Veritabanları (hangi uygulama hangi veritabanını kullanıyor?).
• Uygulama kodu (git repo’dan mı geliyor, sunucuda özel bir şey var mı?).
• Medya ve dosya yüklemeleri (kullanıcı upload’ları, ürün görselleri vb.).
• Konfigürasyon ve sırlar (config dosyaları, .env, TLS sertifikaları, SSH anahtarları vb.).
• Loglar ve raporlar (ne kadar süre saklanması gerekiyor?).

2. Risk analizi ve iş etkisini değerlendirin

Her varlık için şu iki soruyu sorun:

• Kaybolursa ne olur (maddi, hukuki, operasyonel, itibar etkisi)?
• Ne kadar süreye kadar geçmiş veriye geri dönmeyi göze alabilirsiniz?

Bu sayede her veri türü için farklı RPO/RTO hedefleri belirleyebilirsiniz. Örneğin, e‑ticaret sitenizde logların birkaç saatlik kaybı tolere edilebilirken, sipariş tablosunun birkaç dakikadan fazla kaybı kabul edilemez olabilir.

3. RPO/RTO hedeflerini somutlaştırın

Şimdi bu değerlendirmeyi net rakamlara dökün:

• “Blog veritabanı: RPO 24 saat, RTO 8 saat.”
• “E‑ticaret sipariş DB’si: RPO 10 dakika, RTO 30 dakika.”
• “SaaS müşteri dosyaları: RPO 1 saat, RTO 1 saat.”

Bunları mutlaka yazılı hale getirin ve ekip içinde üzerinde mutabakata varın. Yarın bir kesinti olduğunda, “bizim hedefimiz neydi?” tartışmasını o anda yapmak istemezsiniz.

4. Doğru yedekleme topolojisi ve teknolojileri seçin

Hedefler netleşince, bunu karşılayacak teknolojiyi seçmek daha kolaydır:

• RPO 24 saat: Günlük full backup yeterli olabilir.
• RPO 1 saat: Saatlik incremental + günlük full backup kombinasyonu.
• RPO 5‑10 dakika: Log tabanlı yedekleme, replikasyon, streaming WAL/binlog yapıları.

Buna paralel olarak RTO hedeflerine göre:

• RTO 4‑8 saat: Manuel müdahale ile geri yükleme kabul edilebilir.
• RTO 30‑60 dakika: Otomatik script’ler, önceden hazırlanmış runbook, staging ortamında denenmiş adımlar gerekir.
• RTO < 15 dakika: Aktif‑pasif veya aktif‑aktif DR ortamları, otomatik failover, health check ve DNS tabanlı yönlendirme gibi çözümler devreye girer.

5. Saklama süreleri ve sürümleme politikasını belirleyin

Yedeklerin ne kadar geriye doğru tutulacağı, maliyet ve hukuki gereklilikler ile doğrudan ilişkilidir:

• Son 7 gün: Günlük yedekler (hızlı geri dönüş için).
• Son 4‑8 hafta: Haftalık full yedekler (haftalar öncesine dönmek gerektiğinde).
• Son 6‑12 ay: Aylık arşiv yedekler (nadiren ihtiyaç olur ama kritik vakalarda hayat kurtarır).

KVKK/GDPR gibi regülasyonlar, bazı verilerin belirli süre sonunda silinmesini de gerektirebilir. Bu nedenle saklama süresini belirlerken “hem fazlası hem eksiği” sorun çıkarabilir. Otomatik lifecycle kuralları olan object storage çözümleri bu noktada büyük avantaj sağlar.

6. Test geri yüklemeler ve DR tatbikatları yapın

Yedek almak değil, yedekten dönebilmek önemlidir. Bu yüzden:

• Belirli periyotta (örneğin üç ayda bir) staging ortamında tam geri yükleme testi yapın.
• Veritabanı + dosya + DNS + SSL + uygulama konfigürasyonlarının birlikte çalıştığını doğrulayın.
• Bu sürece harcanan süreyi ölçün; gerçek RTO’nuzun, hedefinizle uyumlu olup olmadığını görün.

Bu tatbikatlarda çıkan aksiyon maddelerini dokümante edip, felaket kurtarma runbook’unuzu güncelleyin. Böylece gerçek bir kesintide ekip panik yapmak yerine elindeki reçeteyi uygular.

7. İzleme, alarm ve gözden geçirme döngüsü kurun

Son adım, tüm bu sistemi “kurup bırakmamak”. Zamanla:

• Veri hacminiz artacak,
• Yeni modüller, mikrositeler, alt servisler eklenecek,
• İş gereksinimleri (SLA’lar, müşteri beklentileri) değişecek.

Bu yüzden:

• Yedekleme job’larının başarısını izleyin, başarısızlıkta alarm üretin.
• Yılda en az bir kez RPO/RTO hedeflerinizi tekrar gözden geçirin.
• Yeni devreye alınan her özellik için, yedekleme kapsamına alındığından emin olun.

Sık yapılan hatalar ve DCHost olarak nasıl yaklaşıyoruz?

Yanlış varsayımlar

Sahada en sık gördüğümüz hatalar şunlar:

• “Hosting firması mutlaka yedekliyordur” varsayımı: Evet, çoğu sağlayıcı bir şekilde yedek alır, ama bu her zaman sizin RPO/RTO hedeflerinizle uyumlu değildir.
• “cPanel full backup alınca her şey çözüldü” inancı: Bu yedeklerin nerede tutulduğu, ne kadar sıklıkla alındığı ve nasıl geri dönüleceği çoğu zaman belirsiz bırakılıyor.
• Yedek ve canlı verinin aynı diskte saklanması: Disk arızasında hem üretim hem yedek aynı anda kayboluyor.
• Hiç test restore yapılmaması: İlk geri yükleme denemesi genellikle en kritik anda yapılıyor.

DCHost tarafında benimsediğimiz prensipler

Biz DCHost’ta hem paylaşımlı hosting, hem VPS/dedicated hem de colocation müşterilerimizle çalışırken şu prensipleri temel alıyoruz:

• Önce iş hedefi: “Ne kadar veri kaybı / ne kadar kesinti” sorusuna net cevap olmadan, yedekleme aracı seçmiyoruz.
• 3‑2‑1 kuralına yakınsamak: En az bir kopyanın farklı bir depolama katmanında ve tercihen farklı bir lokasyonda olmasını sağlıyoruz.
• Uygulama‑tutarlılık: Özellikle veritabanı yoğun e‑ticaret ve SaaS iş yüklerinde, snapshot ve log bazlı yedek yapıları ile tutarlı geri dönüş senaryoları kurguluyoruz.
• Testi zorunlu görmek: Yılda en az bir kez tam geri dönüş tatbikatı yapmayı müşterilerimize ısrarla tavsiye ediyoruz.

İster basit bir blog, ister kompleks bir SaaS ürünü olsun; yeni bir projeyi DCHost altyapısına taşırken ya da sıfırdan kurarken, bu prensiplerle birlikte sizin için en uygun RPO/RTO ve yedek topolojisini birlikte tasarlayabiliriz.

Özet ve sonraki adımlar

Yedekleme stratejisi; “günlük backup var” demekten çok daha fazlası. Özellikle blog, e‑ticaret ve SaaS sitelerinde, iş tarafındaki beklentilerle RPO/RTO hedeflerini uyumlu hale getirip, bunu destekleyecek 3‑2‑1 odaklı bir mimari kurmadığınız sürece, yedeklerinizin sizi gerçekten kurtaracağının garantisi yok.

Bu yazıda RPO, RTO, veri sınıflandırması, 3‑2‑1 kuralı, farklı site türleri için hedef örnekleri ve hosting tarafında uygulanabilir senaryolara değindik. Detay adımlar ve komut seviyesinde örnekler için; 3‑2‑1 stratejisi rehberi, WordPress yedekleme yazımız, MySQL/MariaDB yedekleme stratejileri ve uygulama‑tutarlı yedek alma rehberimize mutlaka göz atın.

Eğer mevcut DCHost hizmetiniz üzerinde “gerçekten çalışır” bir yedekleme stratejiniz olup olmadığından emin değilseniz, kendi içinizde şu kısa check‑list’i uygulayabilirsiniz:

• RPO/RTO hedefleriniz yazılı mı?
• Son üç ay içinde en az bir tam geri yükleme testi yaptınız mı?
• En az bir yedek kopyanız farklı bir lokasyonda ve farklı bir depolama katmanında mı?
• Veritabanı yedekleriniz uygulama‑tutarlı mı, yoksa sadece dosya kopyası mı?

Bu sorulardan birine bile “emin değilim” diyorsanız, yedekleme stratejinizi gözden geçirmenin tam zamanı. DCHost ekibi olarak; blog, e‑ticaret ve SaaS projeleriniz için RPO/RTO hedeflerini birlikte netleştirip, bütçenize ve risk iştahınıza uygun bir yedekleme ve felaket kurtarma planını adım adım tasarlamaya hazırız.