Yedekler İçin Sıcak, Soğuk ve Arşiv Depolama Stratejisi: NVMe, SATA ve Object Storage Nasıl Birlikte Kullanılır?

Yedekleme tarafında asıl zor olan, “kaç kopyam var?” sorusundan çok “hangi yedeğe kaç saniyede ulaşabiliyorum ve bu bana kaça mal oluyor?” sorusudur. Aynı altyapıda hem çok hızlı geri dönüş yapabilen, hem de aylarca hatta yıllarca saklanabilen yedekler tutmak istiyorsanız; sıcak, soğuk ve arşiv depolama katmanlarını bilinçli şekilde kurgulamanız gerekir. İşte burada NVMe, SATA ve Object Storage doğru rolü üstlendiğinde hem maliyet hem de kurtarma süreleri tarafında ciddi kazanımlar elde edersiniz.

Bu yazıda, DCHost altyapısında gerçek projelerde uyguladığımız sıcak–soğuk–arşiv yedekleme stratejisini parçalara bölerek anlatacağız. NVMe diskleri nerede kullanmalıyım, SATA tabanlı yedek sunucular ne işe yarar, Object Storage tam olarak hangi katmanda devreye girmeli, 3‑2‑1 kuralını bu mimarinin neresine oturtabilirim gibi sorulara net, uygulamaya dönük cevaplar bulacaksınız. Ayrıca RPO/RTO hedeflerinizi depolama katmanlarıyla nasıl hizalayacağınızı, hangi iş yükü için hangi sıklıkta yedek almanız gerektiğini ve bu yedekleri DCHost üzerinde pratik olarak nasıl konumlandırabileceğinizi adım adım ele alacağız.

Yedeklerde Sıcak, Soğuk ve Arşiv Ne Demek?

Önce kavramları netleştirelim. Aynı verinin birden fazla kopyasını tutabilirsiniz; ancak her kopyanın erişim hızı, saklama süresi ve maliyeti farklı olur. Sıcak, soğuk ve arşiv ayrımı tam olarak bunu ifade eder.

Sıcak Yedek (Hot Backup)

Sıcak yedek; en hızlı erişmek istediğiniz, genellikle son saatler veya son birkaç günle sınırlı, performans açısından güçlü depolamada tuttuğunuz yedeklerdir. Özellikleri:

• RTO (geri dönüş süresi) hedefi çok düşüktür; dakikalar mertebesi.
• Genellikle NVMe SSD gibi yüksek IOPS sağlayan disklerde tutulur.
• Daha kısa saklama süresi vardır (örneğin 24 saat – 7 gün).
• Çoğu zaman aynı fiziksel sunucuda veya aynı veri merkezindeki ayrı bir hızlı depolamada bulunur.

Soğuk Yedek (Cold Backup)

Soğuk yedek; erişim hızının çok kritik olmadığı ama saklama süresinin daha uzun tutulduğu yedek katmanıdır.

• RTO hedefi genellikle saatler mertebesindedir.
• SATA SSD/HDD gibi daha uygun maliyetli ama NVMe kadar hızlı olmayan disklerde saklanır.
• Günlük veya haftalık periyotlarla alınır; saklama süresi haftalar – aylar olabilir.
• Çoğu zaman ayrı bir yedek sunucuda veya aynı veri merkezinde farklı bir depolama havuzunda konumlandırılır.

Arşiv Yedek (Archive Backup)

Arşiv; nadiren erişilen ama hukuki, regülasyon veya kurumsal gereksinimler sebebiyle uzun süre saklanan yedeklerdir.

• RTO hedefi daha yüksektir; saatler, hatta bazı durumlarda bir iş günü kabul edilebilir.
• Genellikle Object Storage üzerinde, daha ucuz ve ölçeklenebilir katmanlarda saklanır.
• Saklama süresi aylar – yıllar olabilir.
• KVKK/GDPR, denetim, yasal saklama zorunlulukları veya uzun vadeli analitik ihtiyaçları için kullanılır.

Sıcak–soğuk–arşiv ayrımını, RPO/RTO hedeflerini anlatırken detaylandırdığımız yedekleme stratejisi planlama rehberiyle birlikte düşünmek önemli. Çünkü hangi katmanda ne kadar veri tutacağınızı aslında bu iki metrik belirler.

Depolama Katmanları: NVMe, SATA ve Object Storage’ın Rolü

Şimdi de disk tiplerine bakalım: NVMe, SATA SSD/HDD ve Object Storage aslında aynı soruna üç farklı açıdan yaklaşan çözümler. Bunları tek başına değil, birlikte çalışacak katmanlar olarak tasarlamak gerekiyor.

NVMe: Sıcak Yedeklerin Evi

NVMe SSD’ler, SATA’ya göre çok daha yüksek IOPS ve düşük gecikme süreleri sunar. Bu yüzden:

• Veritabanı sunucuları
• Yoğun PHP uygulamaları (WordPress, Laravel, Magento vb.)
• Log yoğun, gerçek zamanlı uygulamalar

gibi iş yüklerinde zaten tercih sebebidir. Ancak burada sadece canlı veri için değil, sıcak yedekler için de kritik rol oynar.

Örneğin bir NVMe VPS üzerinde çalışan WooCommerce siteniz var. DCHost üzerinde bu sunucuya alınan saatlik snapshot’lar veya anlık dosya/veritabanı yedekleri yine NVMe üzerinde tutulduğunda, geri dönüş süreleri dramatik şekilde kısalır. Böylece hem veri kaybınız (RPO) düşük, hem de geri yükleme süreniz (RTO) dakikalar mertebesinde kalır.

Disk tipi hakkında daha derin teknik karşılaştırma görmek isterseniz, NVMe SSD, SATA SSD ve HDD karşılaştırması rehberimizde ayrıntılı benchmark ve kullanım senaryolarını anlattık.

SATA SSD/HDD: Soğuk Yedek Sunucuları

SATA SSD/HDD katmanı, NVMe kadar hızlı değildir; ama fiyat/kapasite oranı çok daha iyidir. Tam da bu nedenle:

• Günlük veya haftalık tam yedekler
• Uzun saklama süreli ama yine de veri merkezine yakın olması istenen kopyalar
• Ransomware senaryolarında ilk başvurulan offline veya erişimi kısıtlı depolar

için idealdir.

DCHost tarafında tipik bir senaryoda, NVMe üzerinde çalışan üretim VPS’inizden her gece alınan tam yedekler ve gün içinde alınan artımlı yedekler ayrı bir SATA tabanlı yedekleme sunucusuna aktarılır. Böylece üretim diskleri üzerindeki I/O yükü azalırken, olası bir donanım arızasında NVMe katmanını tamamen kaybetseniz bile, aynı veri merkezinde bulunan daha büyük kapasiteli SATA havuzundan geri dönüş yapabilirsiniz.

Object Storage: Arşiv ve Uzak Kopya

Object Storage, blok veya dosya depolamadan farklı olarak verileri nesne olarak saklayan ve HTTP/S3 benzeri protokollerle erişilen bir yapıdır. Yedekleme tarafında özellikle şu avantajları sunar:

• Sınırsıza yakın ölçeklenebilirlik: Kapasite sınırını düşünmeden büyüyebilirsiniz.
• Farklı sıcaklık katmanları: Sıcak (standard), soğuk (infrequent access) ve arşiv katmanları.
• Versiyonlama ve silme koruması: Ransomware senaryolarında hayati.
• Coğrafi esneklik: Farklı veri merkezinde kopya tutma imkanı.

DCHost altyapısında S3 uyumlu Object Storage kullandığınızda, soğuk yedek sunucularınızdan veya doğrudan VPS/cPanel hesaplarınızdan şifreli ve artımlı yedekleri uzak bir lokasyona gönderebilirsiniz. Object Storage tarafındaki lifecycle policy (yaşam döngüsü politikaları) ile, örneğin 30 günden eski nesneleri daha ucuz arşiv katmanına taşıtabilir, 365 günden eski nesneleri otomatik sildirebilirsiniz. Bu konuyu Object Storage maliyet optimizasyonu rehberimizde detaylı şekilde anlattık.

Neden Katmanlı Yedekleme Mimarisi Kurmalısınız?

Sadece “günlük yedek alıyorum” demek, günümüz senaryolarında maalesef yeterli değil. Fidye yazılımları, insan hataları, yazılım bug’ları ve donanım arızaları, her biri farklı türde yedeğe ihtiyaç duyuyor. Katmanlı mimarinin size sağladığı başlıca faydalar şunlar:

3‑2‑1 Kuralını Gerçekçi Şekilde Uygulamak

Yedeklemede altın standartlardan biri 3‑2‑1 kuralıdır:

• Verinizin en az 3 kopyası olsun.
• Bu kopyalar en az 2 farklı depolama medyasında bulunsun.
• Kopyalardan en az 1 tanesi saha dışında (offsite) tutulmuş olsun.

Sıcak–soğuk–arşiv mimarisi ile bu kuralı doğal olarak uygulamış olursunuz:

• Sıcak yedek: NVMe üzerinde, üretime çok yakın.
• Soğuk yedek: Ayrı SATA tabanlı yedek sunucusunda.
• Arşiv yedek: Farklı bir bölgede veya veri merkezinde Object Storage üzerinde.

Bu katmanlı yaklaşımın fidye yazılımlara karşı nasıl güç kattığını ransomware’a dayanıklı yedekleme stratejisi rehberimizde adım adım ele alıyoruz.

Maliyet – Performans Dengesini Kurmak

Tüm yedeklerinizi NVMe üzerinde tutmak teoride harika ama pratiğe döktüğünüzde bütçeyi çok kısa sürede patlatır. Buna karşılık tüm yedeklerinizi sadece ucuz ama yavaş bir depoda tutmak da gerçek bir kesinti anında işinize yaramaz.

Katmanlı mimari ile:

• En kritik ve “hemen geri dönmem gereken” veriyi NVMe üzerinde, az sayıda versiyonla saklayıp RTO’yu düşürürsünüz.
• Daha az kritik veya daha eski yedekleri SATA tabanlı depoda daha uzun süre ve daha ucuza tutarsınız.
• Yasal veya kurumsal gereksinimler için gereken uzun süreli arşivleri Object Storage üzerinde otomatik lifecycle ve düşük maliyetle yönetirsiniz.

Riskleri Ayrıştırmak

Farklı depolama katmanları aynı anda çökmez. Tek bir NVMe diskin bozulmasıyla hem canlı veriyi hem de tüm yedekleri kaybetmek çok kötü bir senaryodur, ama hala birçok işletme bu riski göze alıyor. Oysa:

• Canlı veri NVMe’de,
• Günlük tam yedekler SATA tabanlı yedek sunucuda,
• Haftalık/aylık arşivler Object Storage üzerinde başka bir lokasyonda

olduğunda, tek nokta arızalarını gerçek anlamda bertaraf etmiş olursunuz.

DCHost Üzerinde Tipik Bir Sıcak–Soğuk–Arşiv Mimarisi

Gelin, DCHost tarafında sıkça kurduğumuz örnek bir mimari üzerinden gidelim. Senaryomuz şöyle olsun:

• Bir adet NVMe VPS üzerinde çalışan WooCommerce + blog (WordPress).
• Ayrı bir VPS’te çalışan CRM/ERP (örneğin Odoo veya ERPNext).
• cPanel üzerinde barınan birkaç kurumsal web sitesi.

Bu yapıyı hem performanslı hem de güvenli şekilde yedeklemek için aşağıdaki katmanları tasarlıyoruz.

Sıcak Katman: NVMe Üzerinde Anlık Yedekler

• Saatlik veritabanı dump’ları: MySQL/PostgreSQL için mysqldump veya benzeri araçlarla.
• Dosya sistemi snapshot’ları: LVM/ZFS veya hypervisor snapshot’ları.
• Kısa saklama süresi: 24 saat – 72 saat.

Buradaki amaç, son bir deploy hatası, yanlış SQL sorgusu, bir eklenti güncellemesi veya küçük çaplı veri bozulmasında en fazla birkaç saatlik veri kaybıyla hızlıca geri dönebilmektir.

Örneğin WooCommerce siparişlerinde yanlışlıkla tablo silindiniz; son 1 saatlik verinizi kaybetmek, son 24 saati kaybetmekten çok daha kabul edilebilir. Sıcak katmandaki NVMe yedeği ile birkaç dakika içinde geri yükleme yapabilirsiniz.

Soğuk Katman: Ayrı Yedek VPS/Dedicated Üzerinde SATA Havuzu

• Her gece tam dosya ve veritabanı yedekleri.
• Gün içinde 3–4 saatte bir artımlı (incremental) yedekler.
• Saklama süresi: 14–30 gün.

Bu katmanda genellikle rsync, Borg, Restic gibi araçlarla NVMe sunuculardan SATA tabanlı yedek sunucusuna veri çekilir. Böylece NVMe üzerindeki sıcak snapshot’lar silinmiş olsa bile, en az son 14–30 güne ait yedeği ayrı bir fiziksel sunucu üzerinde tutmuş olursunuz.

Bu yapıyı özellikle cPanel/VPS yedeklerinizin otomatikleştirilmesi için rclone, restic ve Cron ile otomatik yedek alma rehberimizde pratik komutlarla gösteriyoruz. Aynı mantığı SATA tabanlı yedek sunucusuna da uygulayabilirsiniz.

Arşiv Katmanı: S3 Uyumlu Object Storage

• Haftalık veya 15 günlük tam yedek arşivleri.
• Aylık veya üç aylık snapshot/immuutable arşivler.
• Saklama süresi: 6–24 ay (KVKK/GDPR ve şirket politikasına göre).

Soğuk katmandaki yedek sunucudan Object Storage’a ek şifreleme katmanı ile (örneğin restic/borg’un kendi şifrelemesi + TLS) veri gönderirsiniz. Burada Object Storage’ın lifecycle özelliklerinden faydalanarak:

• İlk 30 gün “sıcak” katmanda (daha hızlı erişim, biraz daha yüksek maliyet),
• 30–180 gün arası “infrequent access” (daha ucuz, nadir erişim),
• 180 günden sonrakiler “arşiv” veya silinmiş

gibi bir politika kurgulayabilirsiniz.

Bu yaklaşımın maliyet tarafını optimize etmek için, tekrar hatırlatmakta fayda var: Object Storage maliyet optimizasyonu yazımızda lifecycle politikalarının gerçek senaryolarda nasıl kurgulanacağını örneklerle paylaştık.

Farklı İş Yükleri İçin Örnek Yedekleme Senaryoları

Her projenin RPO/RTO hedefi farklıdır. DCHost tarafında sık gördüğümüz üç senaryo üzerinden sıcak–soğuk–arşiv mimarisini uyarlayalım.

1) WordPress Blog ve Kurumsal Site

Tipik özellikler:

• İçerik güncellemeleri günlük veya haftalık.
• Veri hacmi nispeten düşük (10–20 GB).
• RTO hedefi birkaç saat kabul edilebilir.

Önerilen strateji:

• Sıcak: NVMe üzerinde günlük veritabanı dump’ı + 2–3 gürlük saklama.
• Soğuk: SATA yedek sunucusunda her gece tam yedek + 30 günlük saklama.
• Arşiv: Object Storage üzerinde aylık tam yedek + 12 ay saklama.

WordPress özelinde otomatik yedekleme ve geri yükleme senaryolarını merak ediyorsanız, WordPress yedekleme stratejileri rehberimiz bu yapıyı daha ayrıntılı ele alıyor.

2) WooCommerce ve E‑Ticaret Siteleri

Burada iş daha kritik, çünkü sipariş ve ödeme verisi var.

• Veri sürekli güncelleniyor.
• Veri kaybına tolerans çok düşük (RPO dakikalar – 1 saat).
• RTO da mümkünse 1 saatten az olmalı.

Önerilen strateji:

• Sıcak: NVMe üzerinde 15–30 dakikada bir veritabanı dump’ı veya binlog temelli replika yedekleri + 24–48 saat saklama.
• Soğuk: Günlük tam yedekler + 4 saatte bir artımlı yedek; SATA yedek sunucuda 30–60 gün saklama.
• Arşiv: Haftalık tam yedekler, Object Storage üzerinde 12–24 ay saklama (KVKK/GDPR ve muhasebe süreçlerine göre).

WooCommerce için kapasite planlama ve veritabanı tuning tarafını doğru yapmak, yedek geri yükleme sürelerinde de fark yaratır. Bunun için WooCommerce kapasite planlama rehberimize de göz atabilirsiniz.

3) SaaS Uygulamaları ve Çok Kiracılı Mimari

SaaS tarafında genellikle aşağıdaki durumlarla karşılaşıyoruz:

• Birden fazla müşteri (tenant) aynı veritabanında veya şemada.
• Veri hacmi yüksek, sürekli yazma var.
• Regülasyonlara göre müşteri verisini uzun süre saklama zorunluluğu.

Önerilen strateji:

• Sıcak: NVMe üzerinde replika + point‑in‑time recovery (PITR) için WAL/binlog arşivleme; son 24–72 saat.
• Soğuk: Günlük tam yedekler, ayrı VPS veya dedicated yedek sunucusunda 60–90 gün saklama.
• Arşiv: Haftalık/aylık tam yedekler, Object Storage üzerinde 1–5 yıl saklama (müşteri sözleşmelerine göre).

SaaS modelinde müşteri verisi yedekleme ve saklama politikalarını daha önce SaaS uygulamaları için müşteri verisi yedekleme rehberimizde detaylandırmıştık. Orada da sıcak–soğuk–arşiv ayrımının SaaS dünyasında neleri kolaylaştırdığını görebilirsiniz.

DCHost Üzerinde Bu Stratejiyi Nasıl Kurabilirsiniz?

DCHost tarafında tipik kurulum adımlarını özetleyelim. Amacımız, hem teknik ekibiniz için uygulanabilir, hem de yönetilebilir bir mimari sunmak.

1) Canlı Ortam İçin NVMe VPS/Dedicated Tercihi

Öncelikle canlı ortamınızı NVMe diskli bir VPS veya dedicated sunucuya taşımanız, sıcak yedeklerin performansını da doğrudan etkileyecektir. Canlı ortam:

• Web sunucusu (Nginx/Apache/LiteSpeed),
• Veritabanı (MySQL/MariaDB/PostgreSQL),
• Uygulama (WordPress, Laravel, Node.js vb.)

için NVMe’nin sunduğu yüksek IOPS’tan faydalanır. Aynı disk üzerinde kısa ömürlü snapshot veya veritabanı dump’larıyla sıcak katmanı oluşturabilirsiniz.

2) Ayrı Yedekleme Sunucusu (SATA Tabanlı)

İkinci adımda, DCHost üzerinde SATA SSD/HDD içeren bir VPS veya dedicated sunucuyu yedekleme sunucusu olarak konumlandırırsınız. Bu sunucu:

• rsync, restic, Borg, rclone gibi araçlarla canlı sunuculardan veri çeker.
• Günlük tam, gün içi artımlı yedekleri saklar.
• Güvenlik duvarı ve erişim politikalarıyla sadece yedekleme amaçlı erişime açılır.

Burada sık yaptığımız pratiklerden biri, yedek sunucuna direkt SSH erişimini sadece ilgili yönetim IP’lerine açmak, diğer tüm trafiği firewall ile engellemektir. Ayrıca bu sunucunun root erişimini sadece DCHost yönetim ekibi ve sizin belirlediğiniz yetkililere limitli tutmak iyi bir güvenlik önlemidir.

3) S3 Uyumlu Object Storage’a Otomatik Senkronizasyon

Yedek sunucudan Object Storage’a otomatik senkronizasyon için genellikle şu araçları kullanıyoruz:

• rclone: S3 başta olmak üzere birçok uzak depolama için son derece esnek.
• restic/borg: Şifreli, deduplikasyonlu ve artımlı yedekler için.
• Cron: Zamanlama ve rutin işler için.

Örneğin her gece saat 02:00’de, bir önceki günün sıkıştırılmış ve şifrelenmiş yedeğini şu mantıkla Object Storage’a gönderebilirsiniz:

• Yedek sunucuda /backups klasöründe günlük arşivleri tut.
• rclone ile /backups/2024‑09‑01.tar.gz dosyasını s3:dchost‑backups/bucket‑adi/2024/09/ dizinine yükle.
• Object Storage tarafında lifecycle ile 30 günden eski nesneleri daha ucuz katmana taşı.

4) Felaket Kurtarma Provası ve Geri Dönüş Testleri

Teorik olarak her şey güzel görünebilir, ama yedek geri yüklemesi test edilmemişse o yedek tam anlamıyla “var” sayılmaz. Bu yüzden DCHost’ta önerdiğimiz yaklaşım şu:

• Aylık veya üç aylık periyotlarla, yedeklerden test geri yükleme yapılması.
• Üretimden izole bir test VPS’i üzerinde, ilgili yedeğin açılıp uygulamanın ayaklanması.
• Geri dönüş süresinin ölçülmesi (RTO’nun pratikte ne olduğunun görülmesi).

Bu süreci adım adım nasıl yöneteceğinizi, hosting tarafında felaket kurtarma provası rehberimizde örnek senaryolarla anlatıyoruz. Tavsiyemiz: En azından yılda birkaç kez bu provayı gerçekten uygulamanız.

Sık Yapılan Hatalar ve İyileştirme Önerileri

Tüm Yedekleri Aynı Diskte Tutmak

En büyük hatalardan biri, “zaten NVMe çok hızlı” deyip hem canlı veriyi hem de tüm yedekleri aynı disklerde saklamak. Bu durumda:

• Disk arızasında hem canlı veri hem yedekler aynı anda gider.
• Ransomware bulaştığında tek hedef üzerinde tüm kopyalar şifrelenir.

Çözüm: En azından soğuk katmanı fiziksel olarak ayrı bir yedek sunucuya taşımak, arşiv katmanını ise Object Storage’ta konumlandırmak.

Yedek Alıp Geri Dönüş Senaryosunu Tanımlamamak

“Yedek alıyoruz” cümlesi ancak “şu kadar dakikada şu şekilde geri dönüyoruz” diye tamamlandığında anlamlı olur. Özellikle e‑ticaret ve SaaS tarafında:

• Hangi tablo veya dizin bozulduğunda hangi yedekten dönüleceğini,
• DNS/SSL, uygulama konfigürasyonu ve IP taşınması gibi adımların sırasını,
• Kimlerin hangi rolde devreye girdiğini

önceden yazmak gerekir. Buna basit bir DR runbook diyebilirsiniz.

KVKK/GDPR Saklama Sürelerini Göz Ardı Etmek

“Ne kadar çok yedek, o kadar iyi” mantığı artık geçerli değil. KVKK ve GDPR, bazı durumlarda veriyi gereğinden fazla tutmanızı da sorun haline getirebilir. Özellikle:

• Kişisel verilerin tutulduğu loglar,
• E‑posta arşivleri,
• Eski müşteri verileri

için saklama süresini politika olarak tanımlamak ve Object Storage lifecycle kurallarıyla bunu desteklemek önemlidir. Bu konuya özel olarak yedek saklama süresi ve KVKK/GDPR dengesini anlattığımız rehberde değindik.

Yedek Transferi ve Şifrelemeyi İhmal Etmek

Yedek, canlı verinizle aynı hassasiyettedir. Hatta çoğu zaman daha risklidir, çünkü daha az izlenir. Bu nedenle:

• Sunucular arası taşıma mutlaka SSH/TLS üzerinden şifreli yapılmalı.
• Object Storage’a yüklenen arşivler istemci tarafında ek olarak şifrelenmeli (örneğin restic/borg ile).
• Yedek sunuculara erişim sıkı firewall ve VPN/SFTP politikalarıyla sınırlandırılmalı.

Özet ve Sonraki Adım: Yedeklerinizin Katmanlarını Netleştirin

Sıcak, soğuk ve arşiv yedek kavramlarını doğru yerleştirdiğinizde, “yedek var mı?” sorusu yerini çok daha olgun bir soruya bırakır: “Hangi yedeğe, kaç dakikada, ne kadarlık veri kaybıyla dönebiliyoruz ve bu bize kaça mal oluyor?”. DCHost olarak her gün sahada gördüğümüz tablo şu: Sadece günlük yedek alan işletmeler, ilk büyük kesintide hem gelir hem itibar kaybı yaşıyor; oysa katmanlı bir NVMe + SATA + Object Storage stratejisiyle bu risklerin büyük bölümü makul maliyetlerle yönetilebilir.

Bir sonraki adımınız çok karmaşık olmak zorunda değil. Önce mevcut durumunuzu çıkarın: Canlı veriniz hangi diskte? Kaç günde bir tam yedek alıyorsunuz? Offsite kopyanız var mı? Son ne zaman gerçek bir geri yükleme testi yaptınız? Bu sorulara net cevaplar verebiliyorsanız, sıcak–soğuk–arşiv mimarisini kurmak birkaç adımlık bir iş. Veremiyorsanız, önce bu fotoğrafı netleştirip ardından DCHost üzerinde NVMe tabanlı canlı ortam, SATA yedek sunucu ve S3 uyumlu Object Storage üçlüsünü birlikte planlamak en sağlıklı yol olacaktır.

Ekibinizle birlikte yedek stratejinizi gözden geçirmek veya DCHost altyapısında uygulanabilir bir sıcak–soğuk–arşiv planı çıkarmak isterseniz, destek ekibimizle iletişime geçip mevcut sunucu yapınızı anlatmanız yeterli. Beraber, hem maliyet hem de kurtarma süreleri açısından işinizi gerçekten koruyan, pratikte test edilmiş bir mimari tasarlayabiliriz.