Blog, E-Ticaret ve SaaS İçin RPO/RTO Yedekleme Planı

Yedekleme stratejisi neden bugün planlanmalı?

Yedeklemeyi sadece “hosting firmasının otomatik aldığı bir kopya” olarak görmek, kurtarma planında boşluk bırakabilir. 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. Yeni bir blog, ölçeklenen bir e‑ticaret projesi ya da çok kiracılı (multi‑tenant) bir SaaS ürünü için altyapı planlarken RPO/RTO hedeflerini baştan belirlemek gerekir. Bu rehber, yaklaşımı kendi sitenize uygulamanız için gerekli adımları açıklıyor.

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: “En fazla son 24 saatteki veriyi kaybetmeyi kabul edebilirim” demektir.
• RPO = 1 saat: “En fazla son 1 saatteki işlemler kaybolabilir” demektir.
• RPO = 5 dakika: “En fazla son 5 dakikadaki işlemler kaybolabilir” demektir; tek başına kullanılacak teknolojiyi belirlemez.

Ö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 için örneğin 5‑15 dakika hedeflenebilir; kabul edilebilir kayıp iş gereksinimleriyle belirlenir.
• SaaS uygulaması: Kullanıcıların sürekli veri girdiği CRM, proje yönetimi vb. senaryolarda RPO’nun dakika seviyesinde olması gerekebilir.

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: Çok hızlı kurtarma gerektirir; otomatik failover veya aktif‑aktif mimari seçenek olabilir. Seçilen yaklaşımın bu süreyi karşılayabildiği tatbikatlarla ölçülmelidir.

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 taahhütleri kurtarma planını etkiler. Ancak %99.9 uptime gibi bir erişilebilirlik hedefi, tek başına kabul edilebilir veri kaybını (RPO) belirlemez. SLA’yı değerlendirirken:

• RPO’yu veri kaybının iş etkisine ve varsa sözleşmedeki veri koruma taahhütlerine göre belirleyin; yedekleme sıklığını buna göre seçin.
• RTO’yu SLA’nın ölçüm dönemi, kapsamı ve kesinti bütçesiyle uyumlu planlayın; otomatik failover veya çok bölgeli mimari gerekip gerekmediğini değerlendirin.

Yedekleme planını yalnızca pazarlama sunumlarındaki SLA ifadelerine dayandırmayın. RPO ve RTO hedeflerini iş gereksinimleri ve geçerli sözleşmenin kapsamıyla karşılaştırın; erişilebilirlik taahhüdünü veri koruma veya kurtarma süresi garantisiyle eş tutmayın.

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): Genellikle yüksek önem ve sık yedek ihtiyacı; saklama süresi iş ve mevzuat gereksinimlerine göre belirlenir.
• Loglar: Güvenlik, denetim veya kurtarma için kritik olabilir; önem ve saklama süresi kullanım amacına göre belirlenir. Yeniden üretilebilen geçici cache verileri ise 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 örnek 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ş ve ödeme akışlarının bulunmadığı sitelerde daha esnek hedefler mümkün olabilir; ancak sık güncellenen haber sitelerinde veya kesintinin gelir kaybına yol açtığı projelerde daha sıkı hedefler gerekebilir.

Aşağıdaki blog, e‑ticaret ve SaaS aralıkları standart veya garanti değil, planlama örnekleridir. Hedefleri iş etkisine göre seçin; karşılanabildiğini geri yükleme tatbikatlarıyla doğrulayın. Blog için örnek hedefler:

• RPO: 12‑24 saat (24 saatlik hedef için günlük yedek başlangıç olabilir; 12 saatlik hedef için günlük yedek tek başına yetmez. Kullanılabilir son yedeğin yaşı hedefi aşmamalıdır).
• 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 örnek 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 veri kaybının etkisi, müşteri sayısı ve kullanım amacına bağlı olarak çok geniş olabilir. Çü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 gereksinimlere sahip bir SaaS için örnek hedefler:

• RPO: 1‑15 dakika arası (özellikle veritabanı için sık incremental yedek gibi yöntemler değerlendirilebilir. Replikasyon da sürekliliği destekleyebilir, ancak silme veya bozulmayı taşıyabileceğinden geçmişe dönüş sağlayan yedeklerin yerini tutmaz).
• 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ı depolama ortamı veya biçimi: Klasik örnek disk ve teyptir. Modern yorumlarda yerel depolama ve bulut gibi farklı biçimler de kullanılır; yalnızca dosya sistemini değiştirmek bağımsız bir ortam oluşturmaz.
• En az 1 kopya farklı lokasyonda (farklı veri merkezi ya da coğrafya); ağ ve erişim ayrımını da planlayın.

Aşağıdaki blog, e‑ticaret ve SaaS topolojileri üç kopya ve uzak lokasyon düzenini örnekler. Snapshot bir kopyalama tekniği, object storage ise bir depolama biçimidir; bu adlar tek başına farklı fiziksel ortam veya bağımsız hata alanı kanıtlamaz. Klasik fiziksel ortam çeşitliliğini karşılamak için disk ve teyp gibi iki ortam türünü somutlaştırın. Yerel depolama ve bulut yorumunu kullanıyorsanız da ortak donanım, bölge, ağ ve erişim yetkilerinden doğan riskleri sağlayıcı ve kurulum bilgileriyle değerlendirin. Farklı depolama katmanı, farklı ortam türü ve bağımsız hata alanı aynı şey değildir.

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ı veri merkezinde, canlı sunucudan bağımsız depolamada hedefe göre 12‑24 saatte bir otomatik yedek (snapshot veya full backup; snapshot canlı depolamaya bağımlı kalmamalı).
• 3. Kopya: Farklı bir veri merkezindeki object storage’a (S3 uyumlu) hedefe göre 12‑24 saatte bir yedek aktarımı. Haftalık aktarım seçilirse yerel kopyaların kaybında veri kaybı bir haftaya yaklaşabilir; bu seçenek 12‑24 saatlik RPO’yu karşılamaz.

Aynı fiziksel sunucudaki yedeklere güvenmek ortak kayıp riski yaratır. Disk arızası, yanlışlıkla silme veya güvenlik ihlalinde hem canlı verinizi hem de yedeğinizi aynı anda kaybedebilirsiniz. Yerel yedeği canlı sunucudan bağımsız depolamada, en az bir yedek kopyayı da farklı lokasyonda tutmayı planlayın. Blog örneğinde object storage kullanılması, klasik iki fiziksel ortam koşulunun sağlandığını göstermez; seçtiğiniz 3‑2‑1 yorumuna göre ortam çeşitliliğini ve hata alanı ayrımını ayrıca doğrulayın.

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 düzenli tam veritabanı yedeği ve bu yedekten itibaren kurtarma için gereken WAL/binlog arşivleri (örneğin 5‑15 dakikada bir aktarım) + 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ı.

Bu e‑ticaret örneğinde yerel arıza ve bölgesel felaket için RPO aynı değildir. Yerel veritabanı kurtarmasında 5‑30 dakikalık hedef, temel yedek ve gerekli log zincirinin kullanılabilirliğine ve aktarım gecikmesine bağlıdır; yerel yedekler canlı sunucudan bağımsız depolamada tutulmalıdır. Uzakta yalnızca günlük tam yedek varsa bölgesel kayıp yaklaşık bir güne, aktarım gecikmesi veya başarısızlığında daha fazlasına çıkabilir; bu düzen bölgesel felakette 5‑30 dakikalık RPO’yu karşılamaz. Aynı hedef bölge kaybı için de isteniyorsa, gerekli temel yedek ve kesintisiz binlog/WAL zincirini uzak lokasyona hedefe uygun gecikmeyle aktarın ve oradan kurtarmayı test edin. Saatlik dosya yedeği için ayrı RPO belirleyin; veritabanı ve dosyaların birlikte tutarlı geri dönebildiğini doğrulayın. Güncel yerel kopya da tek başına RTO garantisi değildir.

SaaS için örnek topoloji

• 1. Kopya: Canlı veritabanı kümesi (primary/replica veya cluster) ve çoklu uygulama sunucuları.
• 2. Kopya: Aynı bölgede, canlı depolamadan bağımsız saklanan düzenli temel veritabanı yedekleri ve bunlarla birlikte kesintisiz log arşivleriyle Point‑in‑Time Recovery planı + dosya sistemi için bağımsız depolamaya kopyalanan saatlik snapshot.
• 3. Kopya: Başka bir bölgede şifreli object storage üzerinde veritabanı dump’ı ve dosya yedekleri + isteğe göre immutable (değiştirilemez) yedekler. Dump ve dosya aktarım sıklığını bölgesel RPO’ya göre yazılı belirleyin. Bölgesel veritabanı RPO’su da 1‑15 dakika olacaksa tek başına aralıklı dump’a güvenmeyin; kullanılan kurtarma yöntemine uygun temel yedekleri ve gerekli kesintisiz log zincirini uzakta kullanılabilir tutun, aktarım gecikmesini hedef içinde izleyin ve uzak kopyadan kurtarmayı test edin.

Yerel ve bölgesel kurtarma hedeflerini ayrı kaydedin. Uzak kopyanın sıklığı ve kurtarma zinciri belirlenmeden bu SaaS topolojisinin bölgesel 1‑15 dakikalık RPO’yu karşıladığı söylenemez. Saatlik dosya kopyası da veritabanının dakika düzeyindeki hedefini karşılamaz; dosyalar için ayrı hedef ve tutarlı geri dönüş noktası belirleyin.

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 panelden alınabilen yedeğin kapsamı ve geri yükleme yetkileri plana göre değişir; hesap/site yedeği, tüm sunucunun yedeğiyle aynı değildir. Kaçınılması gereken hatalar:

• 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.

Paylaşımlı hosting için yedekleme planı oluştururken:

• Otomatik yedekleme olanağını, kapsamını, sıklığını ve saklama süresini doğrulamalı; RPO hedefinizi karşılayan bir zamanlama oluşturmalı,
• 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 (erişimi kısıtlanmış, canlı sistemden izole bir test 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 teknikler dosya sistemi tutarlılığını destekler; bu, tek başına veritabanı veya uygulama tutarlılığı garantisi değildir. Uygulamanın yedekleme gereksinimlerini ayrıca karşılayın ve snapshot’ı bağımsız depolamaya kopyalayın. Ayrıntılar için uygulama‑tutarlı yedekler rehberine göz atın.
• Uzak depolama: Yedekleri yalnızca aynı VPS’te tutmak yerine, bağımsız bir hata alanındaki harici depolamaya kopyalamak; S3 uyumlu bir hedef seçilecekse yedekleme aracıyla uyumluluğunu doğrulamak.

Bu senaryolarda restic veya Borg gibi deduplikasyon destekli araçlar değerlendirilebilir. Hedef depolamayı seçerken aracın kullanılan sürümünün desteklediği bağlantı yöntemlerini ve toplam depolama/aktarım maliyetini karşılaştırın; S3 uyumlu bir endpoint’in her araçla doğrudan çalışacağını varsaymayın. 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.

Object storage katmanında çapraz bölge replikasyon (Cross‑Region Replication) bir tasarım seçeneğidir; seçtiğiniz S3 uyumlu hizmetin veya MinIO kurulumunun ilgili özelliklerini ve koşullarını doğrulayın. Replikasyon gecikmesini bölgesel RPO açısından izleyin; kopyalanan silme veya bozulmalara karşı geçmişe dönüş korumasını ayrıca planlayın. Teknik ayrıntılar için S3/MinIO’da çapraz bölge replikasyon rehberimizi DR runbook’unuzla birlikte değerlendirebilirsiniz.

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 soruları sorun:

• Kaybolursa ne olur (maddi, hukuki, operasyonel, itibar etkisi)?
• Ne kadar süreye karşılık gelen veri kaybını göze alabilirsiniz (RPO)?
• İlgili hizmet en fazla ne kadar süre kullanılamaz durumda kalabilir (RTO)?

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, bunları karşılayacak teknolojiyi seçmek daha kolaydır. Aşağıdaki zamanlamalar başlangıç örnekleridir: Yedek alma ve aktarım süresi, başarısız işler ve log gecikmesi dahil, ilgili felaket senaryosunda kullanılabilir son kurtarma noktasının yaşı RPO’yu aşmamalıdır. Yerel ve uzak kopyaları ayrı değerlendirin:

• 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: Düzenli temel yedeklerle birlikte sık veya sürekli log arşivleme. Replikasyon kurtarmayı hızlandırmak için ayrıca değerlendirilebilir; bağımsız, geçmişe dönülebilen yedeklerin yerine geçmez.

Buna paralel olarak RTO hedefleri için aşağıdaki yaklaşımlar değerlendirilebilir. Bunlar süre garantisi değildir; veri hacmi, aktarım hızı, altyapıyı hazırlama ve hizmeti doğrulama süreleriyle birlikte tatbikatta ölçülmelidir:

• 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. Aşağıdaki örnek saklama katmanlarını veri türüne, RPO hedeflerine ve geç fark edilen hatalardan kurtarma ihtiyacına göre uyarlayın:

• Son 7 gün: Günlük yedekler (yakın geçmişe 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 (iş veya kurtarma gereksinimi varsa).

Bunlar seyrek saklama katmanı örnekleridir; saatlik veya dakikalık RPO için gereken daha sık kopyaları ayrıca tutun. Belirlediğiniz geçmişe dönüş penceresi boyunca temel yedekleri ve onlara bağlı artımlı yedek/log zincirini birlikte koruyun; saklama kuralları kurtarma için gerekli parçaları erken silmemelidir.

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) erişimi kısıtlanmış, canlı sistemden izole bir staging ortamında tam geri yükleme testi yapın; gerçek ödeme ve bildirim gibi dış etkileri devre dışı bırakın.
• Veritabanı + dosya + DNS + SSL + uygulama konfigürasyonlarının birlikte çalıştığını doğrulayın.
• Kesintinin fark edilmesi, müdahale, geri yükleme ve hizmetin doğrulanması dahil toplam kurtarma süresini ölçün; ölçülen sürenin RTO hedefinizle uyumunu değerlendirin.

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 artabilir,
• Yeni modüller, mikrositeler ve alt servisler eklenebilir,
• İş gereksinimleri (SLA’lar, müşteri beklentileri) değişebilir.

Bu yüzden:

• Yedekleme işlerinin başarısını ve yerel/uzak kullanılabilir kurtarma noktalarının yaşını izleyin; başarısızlıkta veya RPO sınırına yaklaşan gecikmede alarm üretin.
• Yılda en az bir kez RPO/RTO hedeflerinizi tekrar gözden geçirin.
• Yeni devreye alınan her özelliğin yedekleme kapsamını değerlendirin; gerekli veri ve bağımlılıkları plana ekleyin.

Sık yapılan hatalar ve yedekleme planlama prensipleri

Yanlış varsayımlar

Kaçınılması gereken varsayımlar ve uygulamalar şunlar:

• “Hosting firması mutlaka yedekliyordur” varsayımı: Seçtiğiniz planın yedekleme kapsamını, sıklığını, saklama süresini ve geri yükleme koşullarını RPO/RTO hedeflerinizle karşılaştırın.
• “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 yükleneceği de planlanmalıdır.
• Yedek ve canlı verinin aynı diskte saklanması: Disk arızasında hem üretim hem yedek aynı anda kaybolabilir.
• Hiç test restore yapılmaması: İlk geri yükleme denemesini gerçek bir kesintiye bırakmak, sorunların en kritik anda ortaya çıkması riskini artırır.

Yedekleme planında temel prensipler

Paylaşımlı hosting, VPS/dedicated veya colocation kullanırken yedekleme planınızı şu prensiplerle değerlendirebilirsiniz:

• Önce iş hedefi: “Ne kadar veri kaybı / ne kadar kesinti” sorusuna yerel arıza ve bölgesel felaket için net cevap vermeden yedekleme aracı seçmeyin.
• Kopyaları ayırmak: Canlı veri dahil üç kopyayı planlayın; en az bir yedeği farklı lokasyonda tutun. Ortam çeşitliliğini, depolama katmanını ve bağımsız hata alanlarını ayrı değerlendirin; yalnızca object storage etiketiyle klasik fiziksel çeşitliliğin sağlandığını varsaymayın.
• Uygulama‑tutarlılık: Özellikle veritabanı yoğun e‑ticaret ve SaaS iş yüklerinde, snapshot ve log bazlı yedek yapıları kullanırken uygulama‑tutarlılık gereksinimlerini belirleyin ve tutarlı geri dönüşü testlerle doğrulayın.
• Testi zorunlu görmek: Yılda en az bir kez tam geri dönüş tatbikatı planlayın; iş yükünün kritikliğine ve değişiklik sıklığına göre test aralığını kısaltın.

İster basit bir blog, ister kompleks bir SaaS ürünü olsun; taşıma veya ilk kurulum öncesinde yedekleri kimin alacağını, alarmları kimin izleyeceğini ve geri yüklemeyi kimin başlatacağını yazılı olarak belirleyin.

Ö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 getirmek ve bunu destekleyecek 3‑2‑1 odaklı bir mimari kurmak önemlidir. Ancak bu tasarım tek başına başarılı kurtarma garantisi vermez; geri yükleme testleriyle hedeflerin karşılanabildiğini doğrulamak gerekir.

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:

• Yerel arıza ve bölgesel felaket için RPO/RTO hedefleriniz yazılı mı; uzak kopya ve gerekli log zinciri bu hedeflere uygun mu?
• Belirlediğiniz test aralığında (örneğin son üç ay içinde) tam geri yükleme testi yaptınız mı; kurtarma noktasını ve toplam süreyi hedeflerle karşılaştırdınız mı?
• Canlı veri dahil üç kopyanız ve farklı lokasyonda en az bir yedeğiniz var mı? Seçtiğiniz 3‑2‑1 yorumuna göre ortam çeşitliliğini ve hata alanı ayrımını doğruladınız mı?
• Veritabanı yedekleriniz uygulama‑tutarlı mı; dosyalar ve diğer bağımlılıklarla birlikte geri dönüşü doğruladınız mı?

Bu sorulardan birine bile “emin değilim” diyorsanız, yedekleme stratejinizi gözden geçirmenin tam zamanı. Eksik veya belirsiz kalan maddeler için sorumlu kişi, hedef tarih ve doğrulama adımı belirleyerek bütçenize ve risk iştahınıza uygun yedekleme ve felaket kurtarma planınızı güncelleyin.