Bugün KOBİ’lerden e-ticaret firmalarına, ajanslardan kurumsal markalara kadar herkesin ortak kaygısı aynıdır. Sistem durmasın, veri kaybı yaşanmasın ve olası bir sorun durumunda hızlıca geri dönüş sağlanabilsin.
Sipariş akışının durması, ödeme hataları, CRM/ERP kesintileri veya bir fidye yazılımı saldırısı ciddi sonuçlar doğurur. Bu tür durumlar hem ciroyu hem de marka itibarını doğrudan etkiler. Bu nedenle veri güvenliği artık yalnızca IT ekibinin konusu değildir. Pazarlama yöneticileri, e-ticaret ekipleri ve üst yönetim de bu konuyu doğrudan gündemine almak zorundadır.
Bu rehberde şunları netleştireceğiz:
- Replikasyon nedir, hangi senaryoda gerçekten işe yarar?
- Yedekleme nedir, ne zaman “olmazsa olmaz” hale gelir?
- RPO/RTO gibi hedefler kararınızı nasıl değiştirir?
- KOBİ ve e‑ticaret için pratik karar şablonu nedir?
- Makdos altyapısı ile bu iki yaklaşım birlikte nasıl kurgulanır?
Replikasyon Nedir? Ne İşe Yarar?
Replikasyon, verinin (ya da sistemin) bir kopyasının başka bir ortamda eş zamanlı veya yakın eş zamanlı tutulmasıdır. Amaç, birincil ortamda sorun çıktığında hizmeti diğer kopyadan sürdürebilmektir. Böylece iş sürekliliği korunur ve sistemin her zaman ulaşılabilir olması sağlanır.
Örneğin e-ticaret veritabanınız ya da uygulama sunucunuz tek bir makinede çalışıyorsa ciddi bir risk oluşur. Bu sunucuda yaşanacak bir donanım arızası veya veri merkezi kesintisi tüm hizmeti durdurabilir. Replikasyon yapısı, bu durumu tek nokta arızası olmaktan çıkarır. Sorun oluştuğunda ikinci kopya devreye girer (failover) ve hizmet kesintisiz şekilde devam eder.
Makdos’un “Veri Merkezi Replikasyonu Nedir?” başlıklı içeriği, konuyu detaylı şekilde ele alır. Özellikle çoklu lokasyon yapılarında ve felaket senaryolarında replikasyonun neden kritik olduğunu açıklar.
Replikasyonun Hedefi: Kesintisiz hizmet ve sürekli erişim
Replikasyon, “veriyi kaybetmeyeyim” kadar “hizmetim durmasın” ihtiyacına da yanıt verir. Bu yüzden replikasyon projelerinde çoğu zaman şu hedefler konuşulur:
- Kesinti süresini azaltmak (downtime’ı düşürmek)
- Kritik servisler için hızlı devreye alma (failover)
- Kullanıcıya yakın lokasyondan servis vererek performansı artırmak
- Felaket kurtarma (Disaster Recovery) planının bir parçası olarak yedek lokasyon oluşturmak
Senkron, asenkron ve near-sync replikasyon
Replikasyon denince “her şey anlık kopyalanıyor” algısı oluşur. Gerçekte ise üç temel yaklaşım vardır:
- Senkron replikasyon: Yazma işlemi, birincil ve ikincil tarafta aynı anda tamamlanır. Veri kaybı hedefi çok düşüktür; ancak gecikme (latency) ve bant genişliği gereksinimi artar.
- Asenkron replikasyon: Önce birincil tarafta yazma tamamlanır, sonra değişiklikler karşı tarafa aktarılır. Performans daha esnektir; fakat kabul edilebilir veri kaybı süresi (RPO) senkrona göre daha yüksek olabilir.
- Near-sync (yakın senkron): Tam senkron kadar katı kurallara sahip değildir. Ancak asenkron modele göre daha sık veri aktarımı yapar ve arada bir denge sunar.
Blok / dosya / uygulama-veritabanı seviyesinde replikasyon
Replikasyon, sistemin hangi katmanında yapıldığına göre de ayrışır:
- Blok seviyesinde replikasyon: Disk blokları kopyalanır. Depolama veya sunucu seviyesinde uygulanır.
- Dosya seviyesinde replikasyon: Dosya sistemindeki değişiklikler eşitlenir.
- Uygulama / veritabanı replikasyonu: Örneğin bir veritabanının replika node’u ile çalışılır. Veri tutarlılığı, gecikme ve “okuma/yazma” rolleri daha net yönetilir.
Bu seçimi belirleyen şey; uygulamanızın yapısı, yazma yoğunluğu, veri tutarlılığı ihtiyacı ve hedeflediğiniz RPO/RTO değerleridir.
Yedekleme Nedir? Ne Zaman Hayati Hale Gelir?
Yedekleme, verinin belirli aralıklarla alınan kopyalarının, gerektiğinde geri dönülebilecek şekilde saklanmasıdır. Yedeklemenin temel amacı kesintisiz çalışma sağlamak değildir. Asıl hedef; yanlışlıkla silme, veri bozulması, fidye yazılımı veya insan hatası gibi durumlarda sistemi geri yükleyebilmektir.
Kısacası: Replikasyon bir “çalışır kopya” üretir; yedekleme ise “arşivlenmiş geri dönüş noktaları” üretir.
Makdos’un “Web Hosting’de Yedeklemenin Önemi” başlıklı yazısı, veri kaybı senaryolarını detaylı şekilde açıklar. Ayrıca yedekleme olmadığında geri dönüşün neden zorlaştığını pratik örneklerle gösterir.
Tam, artımlı ve diferansiyel yedekleme
Yedekleme tasarımında üç temel yaklaşım öne çıkar:
- Tam (full) yedek: Her şeyin komple kopyası alınır. Geri dönüş kolaydır; depolama maliyeti ve süresi daha yüksektir.
- Artımlı (incremental) yedek: Son yedekten bu yana değişen veriler alınır. Depolama verimlidir; geri dönüş zinciri yönetimi önemlidir.
- Diferansiyel (differential) yedek: Son tam yedekten bu yana değişen veriler alınır. Artımlıya göre daha büyük; ancak geri dönüş süreci daha basit olabilir.
Snapshot nedir? Yedekleme ile karıştırılan noktalar
Snapshot (anlık görüntü), çoğu zaman yedekleme gibi düşünülür. Snapshot; disk/volume üzerinde belirli bir andaki durumu hızlıca “işaretleyen” bir mekanizmadır.
Ancak her snapshot otomatik olarak ayrı bir ortamda, izole, uzun süre saklanan bir yedek anlamına gelmez. Bu nedenle snapshot’ı genellikle hızlı bir geri dönüş noktası olarak düşünmek gerekir. Yedekleme ise felaket ve en kötü senaryolara karşı dayanıklı bir arşiv olarak görülmelidir.
Retention (saklama) ve versiyonlama: “geri dönebilme” farkı
Yedekleme stratejisinde sadece “yedek aldık” demek yetmez. Şu sorular yanıtlanmalı:
- Yedekleri kaç gün/hafta/ay saklayacağız (retention)?
- Kaç farklı “geri dönüş noktası” tutacağız (versiyonlama)?
- Yedekler nerede duracak (offsite / farklı lokasyon)?
- Yedeklerden geri dönüş testini ne sıklıkla yapacağız?
Bu soruların cevapları, yedeklemenin gerçekten işe yarayıp yaramadığını belirler.
Replikasyon ile Yedekleme Arasındaki Temel Farklar
En kritik farkı tek cümlede özetleyelim:
- Replikasyon: Hizmeti ayakta tutmaya, kesintiyi azaltmaya odaklanır.
- Yedekleme: Veri kaybı ve hatalı değişikliklerde geri dönmeye odaklanır.
Aşağıdaki tablo karar vermeyi kolaylaştırır:
En sık yapılan yanlış: “Replikasyon varsa yedek gereksiz”
Bu yaklaşım, pratikte en pahalı hatalardan biridir. Çünkü replikasyon yalnızca doğru veriyi değil, hatalı veriyi de kopyalar. Yanlışlıkla silinen bir kayıt, bozulmuş bir dosya ya da şifrelenmiş veri aynı hızla diğer tarafa aktarılabilir. Bu nedenle replikasyon kurduysanız bile bağımsız yedekleme politikası şarttır.
KOBİ’ler ve E-Ticaret İçin Hangi Senaryoda Hangisi Gerekli?
Replikasyon mu, yedekleme mi sorusunun doğru cevabı çoğu zaman “ihtiyaca göre ikisi birlikte”dir. Ama bütçe ve öncelikler sınırlı olabilir. Aşağıdaki senaryolar, KOBİ ve e‑ticaret ekipleri için pratik bir çerçeve sunar.
E-ticarette kampanya dönemleri: trafik artışı + ödeme akışı riski
E‑ticarette kesinti, doğrudan gelir kaybıdır. Kampanya günlerinde (yüksek trafik) şu kombinasyon öne çıkar:
- Replikasyon: Uygulama katmanında veya veritabanında hızlı failover ile kesintiyi azaltır.
- Yedekleme: Sipariş/veri tutarlılığında bir bozulma olursa “sağlıklı noktaya” dönmeyi sağlar.
Bu noktada “bulut sunucu” mimarisi ve esnek kaynak yönetimi kritik hale gelir. Makdos’un bulut sunucu rehberi, esneklik ve yedeklilik perspektifiyle iyi bir başlangıçtır.
İlgili yazı: Bulut Sunucu Nedir ve Neden Önemlidir?
Ajanslar için: çoklu müşteri projelerinde standart koruma seti
Ajanslar genelde aynı altyapıda birçok proje barındırır. Bu durumda tek bir sorun birçok müşteriyi etkileyebilir. Önerilen minimum set:
- Günlük otomatik yedekleme + haftalık “uzun saklama” kopyası
- Kritik müşteriler için replikasyon (en azından veritabanı seviyesinde)
- Kurtarma testleri: Ayda bir “random bir projeyi geri yükleme” provası
Kurumsal uygulamalar (ERP/CRM): kesinti maliyeti ve itibar etkisi
Kurumsal tarafta kesintinin maliyeti sadece satış değil; operasyonun durmasıdır. ERP/CRM gibi sistemlerde genellikle:
- RTO hedefi düşükse replikasyon ihtiyacı artar.
- Sözleşmesel taahhütler, SLA’lar ve KVKK gibi yükümlülükler devreye girdiğinde risk artar. Bu durumda offsite yedekleme ve net bir kurtarma planı çok daha kritik hale gelir.
RPO ve RTO Nedir? Doğru Hedef Nasıl Belirlenir?
Bu iki kavram, replikasyon ve yedekleme stratejinizin “nedenini” sayıya döker:
- RTO (Recovery Time Objective): Bir kesintiden sonra sistemin tekrar çalışır hale gelmesi için kabul edilebilir maksimum süre.
- RPO (Recovery Point Objective): Kesinti anında kabul edilebilir en yüksek veri kaybı süresidir. Yani son geri dönüş noktası ile kesinti arasındaki zamanı ifade eder.
AWS’nin felaket kurtarma kaynaklarında RTO ve RPO bu şekilde tanımlanır. Tanımları resmi içeriklerinde açıkça görebilirsiniz.
AWS – Disaster Recovery Nedir?
RPO’yu basitçe hesaplama mantığı (örnek)
- RPO = 4 saat ise, “en kötü senaryoda 4 saatlik veriyi yeniden üretebilecek misiniz?” sorusunu yanıtlıyorsunuz demektir.
- E‑ticarette 4 saatlik sipariş kaybı çoğu senaryoda kabul edilemez. Bu durumda yedekleme sıklığı artırılır ve/veya replikasyon devreye alınır.
RTO’yu basitçe hesaplama mantığı (örnek)
- RTO = 1 saat ise, “kesinti yaşarsak 1 saat içinde tekrar hizmet vermeliyiz” diyorsunuz demektir.
- KOBİ’lerde bu hedef, operasyonun yapısına göre değişir. Bazı sistemlerde 1 saatlik veri kaybı tolere edilebilir. Ancak ödeme veya checkout süreçlerinde bu süre kabul edilemez.
RPO/RTO hedefini 10 dakikada belirleme
- Kritik sistemleri listeleyin (Web sitesi, ödeme, CRM/ERP, e‑posta, dosya paylaşımı)
- RTO hedefi koyun (Örn. ödeme sistemi 15 dk, web 30 dk, CRM 4 saat)
- RPO hedefi koyun (Örn. sipariş 5 dk, ürün/stok 15 dk, içerik 24 saat)
- Her sistem için “1 saat durursa ne kaybederim?” sorusunu yanıtlayın (ciro, operasyon, itibar)
- Hedefler küçüldükçe maliyetin artacağını kabul edin ve “en kritik 2 sistem”e öncelik verin
- Ayda 1 kez “geri yükleme testi” planlayın (test restore)
- Hedefleri sağlayacak mimariyi (replikasyon + yedekleme) teknik ekiple netleştirin
Neden ISO 22301 gibi standartlar bu konuyu destekler?
İş sürekliliği (business continuity) yaklaşımında; riskleri tanımlamak, hedefleri koymak ve süreçleri düzenli test etmek kritik kabul edilir. ISO 22301 de tam olarak bu çerçevede, kurumların iş sürekliliği yönetim sistemi (BCMS) kurmasına yönelik bir standarttır.
ISO 22301:2019 – Business Continuity
Replikasyonun Tek Başına Yetmediği Riskler
Replikasyon güçlü bir iş sürekliliği aracıdır; ancak bazı risklerde tek başına yeterli değildir.
Fidye yazılımı: “kötü verinin” de replike olması riski
Fidye yazılımı bulaştığında dosyalar şifrelenir. Eğer replikasyon aktifse, bu şifreli veri diğer tarafa da aktarılabilir. Yani replikasyon, kesintiye karşı güçlü olsa da “hatalı/zararlı değişiklik” senaryosunda sizi tek başına korumaz.
Replikasyon, hatayı da hızla çoğaltır. Yanlış silme, bozulma veya şifreleme gibi olaylarda “sağlıklı bir geri dönüş noktası” için bağımsız yedek gerekir.
İnsan hatası / yanlış silme: replikasyonda geri dönüş zorluğu
Bir kullanıcı yanlışlıkla bir klasörü sildiğinde veya yanlış bir SQL sorgusu çalıştırdığında, bu değişiklik de replike olabilir. Yedekleme burada “zaman makinesi” işlevi görür.
Yedekler tek bir lokasyonda tutuluyorsa risk artar. Ayrıca aynı erişim yetkileri kullanılıyorsa, fidye yazılımı saldırısında yedekler de etkilenebilir. Offsite ve erişim izolasyonu, yedeklemenin “sigorta” kısmıdır.
Bu risklere karşı: immutable yedek, versiyonlama, ayrık ortam
Bu aşamada ek güvenlik önlemleri gerekir. Bu aşamada değiştirilemez yedekler kullanılmalıdır. Burada değiştirilemez yedek, ayrı kullanıcı yetkisi ve offline ya da farklı hesap kullanımı şarttır. En kritik pratik ise şudur: yedeklerin geri dönebildiğini test etmek (restore test).
Sağlam Bir Yedekleme Stratejisi İçin Pratik Kontrol Listesi
Teoride herkes yedek alır. Pratikte en sık yapılan hatalar bellidir. Yedek alınır ama geri yükleme test edilmez; yedekler aynı lokasyonda tutulur ve düzenli olarak izlenmez. Aşağıdaki kontrol listesi, sahada işe yarayan bir çerçevedir.
3-2-1 yaklaşımı ve offsite yedek mantığı
3-2-1 kuralı, veri korumada en bilinen prensiplerden biridir:
- Verinizden 3 kopya (orijinal + 2 kopya)
- 2 farklı ortam (ör. lokal disk + bulut depolama)
- 1 kopya offsite (farklı lokasyon/ağ ayrımı)
Bu yaklaşımın mantığını 3-2-1 kuralını anlatan teknik kaynaklarda net şekilde görebilirsiniz.
Şifreleme, erişim yetkileri ve kurtarma testi (test restore)
- Yedekleri şifreleyin (en azından at-rest encryption)
- Yedek kullanıcılarını ayrı tutun (ayrı rol/ayrı kimlik doğrulama)
- Haftalık/aylık “restore testi” yapın ve sonucu kayıt altına alın
- “Kim yedek aldı?” yerine “hangi tarihe dönebiliyorum?” sorusunu sorun
Otomasyon ve izleme: “yedek alındı mı?” değil “dönebiliyor muyuz?”
İyi yedekleme; raporlama, alarm ve otomasyon ister. Yedekleme başarısız olduğunda anında bildirim, depolama dolmadan uyarı, periyodik geri yükleme testleri gibi adımlar, stratejinin olgunluğunu gösterir.
Makdos ile İş Sürekliliği: Replikasyon + Yedekleme Nasıl Kurgulanır?
Replikasyon ve yedekleme, güçlü bir altyapı ile birleştiğinde gerçek anlamda iş sürekliliğine dönüşür. Makdos tarafında bu yaklaşımın temelinde; çoklu veri merkezi kurgusu, yedekli network ve 7/24 operasyonel destek yer alır. Makdos’un bulut tarafında “üç ayrı veri merkezi” vurgusu, çoklu lokasyon dayanıklılığı açısından önemlidir.
Bulut/Sanal/Fiziksel sunucularda doğru mimari yaklaşım
- Bulut Sunucu: Dağıtık mimariler, replikasyon senaryolarını daha erişilebilir hale getirir. Makdos’un bulut sunucu yaklaşımı; güvenlik, yedeklilik ve yedekleme opsiyonlarıyla birlikte konumlanır. Bulut Sunucu Kiralama
- Sanal Sunucu: Tek bir VM üzerinde koşan sistemlerde dahi doğru yedekleme politikası ile hızlı geri dönüş sağlanır. Makdos’un sanal sunucu hizmetinde %99,8 uptime ve yedekli network altyapısı öne çıkar. Ayrıca 20 Gbit uplink bağlantı gibi unsurlar, stabil erişim hedefi açısından güçlü göstergelerdir. Sanal Sunucu Kiralama
- Fiziksel Sunucu: Yüksek I/O isteyen veritabanları veya kurumsal uygulamalar için dedicated altyapıda replikasyon + yedekleme mimarisi planlanır. Fiziksel sunucularda Tier III, yedekli network ve 7/24 izleme gibi unsurlar öne çıkar. Fiziksel Sunucu Kiralama
Operasyonel olgunluk: destek, otomasyon ve sürecin kolay yönetilmesi
Süreklilik sadece teknolojiyle değil operasyonla da ilgilidir. Makdos, içeriklerinde 8 yılı aşkın deneyime ve 25 kişilik uzman ekibe sahip olduğunu vurgular. Ayrıca altyapının yerli bir CRM yazılımı ile yönetildiğini ve çoklu veri merkezi yaklaşımının benimsendiğini belirtir.
Makdos’un mobil uygulama özelliği de dikkat çeker. Özellikle KOBİ’ler için anlık takip ve hızlı aksiyon alma konusunda önemli bir kolaylık sağlar.
Makdos müşterileri için: hızlı aksiyon planı
“Benim için doğru kombinasyon ne?” Bu soruya hızlı yanıt almak için şu adımları izleyin:
- Kritik sistemlerinizi belirleyin. RPO/RTO hedeflerinizi 1 sayfalık bir liste halinde yazın.
- Mevcut yedekleme sıklığınızı ve yedeklerin nerede tutulduğunu netleştirin
- Replikasyonun gerçekten gerekli olduğu 1–2 sistemi belirleyin (çoğu senaryoda veritabanı + uygulama)
- Kurtarma testini (restore) aylık takvime bağlayın
- Planınızı netleştirmek için Makdos ekibine ulaşın: İletişim
Sonuç: Hangi Kombinasyon Sizin İçin Doğru?
Replikasyon ve yedekleme, birbirinin alternatifi değil; doğru tasarlanırsa birbirini tamamlayan iki parçadır. Replikasyon, kesintileri azaltır ve iş sürekliliğini güçlendirir. Yedekleme ise hatalı değişikliklerde, siber saldırılarda ve veri bozulmalarında “geri dönüş” sağlar.
Eğer kesinti maliyetiniz yüksekse ve RTO hedefiniz düşükse, replikasyon yatırımı anlam kazanır. Veri kaybı ve hatalı işlemler sizin için ciddi bir riskse, önce yedekleme süreçlerinizi sağlamlaştırın. Bu temel oturmadan yalnızca replikasyona güvenmek doğru olmaz.
Replikasyon + yedekleme stratejinizi, iş hedeflerinize göre birlikte kurgulayalım. İhtiyacınıza uygun bulut sunucu veya sanal sunucu altyapısını Makdos’ta hızlıca başlatın. Ardından yedeklilik planınızı açık ve yazılı hale getirin.
