Acronis Disaster Recovery

Acronis Disaster Recovery, korunan iş yüklerinin Acronis Cloud'da çalışmaya hazır kopyalarını tutan ve bir kesinti anında bu kopyaları bulutta ayağa kaldıran bir Acronis Cyber Protect Cloud eklentisidir. Yedeklemeden farkı şudur: yedek veriyi saklar, felaket kurtarma ise hizmeti ayakta tutar. Üretim failover'ı, üretime dokunmayan test failover'ı, runbook ile sıralı devreye alma ve site-to-site VPN seçenekleri tek konsoldan yönetilir.

Hedefler resmî olarak da tanımlıdır: Acronis'in Advanced Disaster Recovery veri sayfası, RunVM motoru sayesinde 15 dakikanın altında RPO ve RTO hedefini açıkça belirtir (Acronis Advanced Disaster Recovery veri sayfası, 2022). Bu rakam bir garanti değil, mimarinin hedeflediği çalışma noktasıdır; gerçekleşen değer replikasyon sıklığına, iş yükü büyüklüğüne, hat kapasitesine ve runbook tasarımına bağlıdır.

Bu yatırımın gerekçesi, kesintinin ne kadar uzadığını gösteren verilerde saklı. IBM Cost of a Data Breach Report 2025'e göre kuruluşların %65'i ihlalden hâlâ tam olarak toparlanamamıştır; tam toparlandığını söyleyenlerin %76'sında süreç 100 günü, %26'sında 150 günü aşmış, yalnızca %2'si 50 günün altında toparlanabilmiştir (IBM & Ponemon, 2025). Aynı rapor küresel ortalama veri ihlali maliyetini 4,44 milyon USD olarak veriyor (2024'te 4,88 milyon USD); şantaj ve fidye yazılımı olaylarının ortalama maliyeti ise saldırgan tarafından ifşa edildiğinde 5,08 milyon USD.

Felaket kurtarma bu nedenle yalnızca deprem veya yangın senaryosunun değil, fidye yazılımının da konusudur. Acronis'in H2 2025 Cyberthreats Report'una göre 2025'in ikinci yarısında dünya genelinde 7.600'den fazla fidye yazılımı kurbanı kamuya açıklandı; en aktif gruplar Qilin (962 kurban), Akira (726) ve Cl0p (517) oldu (Acronis Cyberthreats Report H2 2025). Sora Yazılım olarak Acronis çözüm ailesi içinde felaket kurtarma projelerini kapsam belirleme, runbook tasarımı, tatbikat ve yönetilen işletme aşamalarıyla birlikte yürütüyoruz.

Acronis Disaster Recovery ile klasik yedekleme arasındaki fark nedir?

Kısa cevap: yedeklemede veri saklanır ve kurtarma talep edildiğinde geri yazılır; felaket kurtarmada ise iş yükünün çalışmaya hazır bir kopyası bulutta bekler ve failover komutuyla devreye alınır. Yedekleme RPO'yu, felaket kurtarma ise ağırlıklı olarak RTO'yu iyileştirir. İkisi birbirinin alternatifi değildir; Disaster Recovery zaten aktif bir Acronis Cyber Protect aboneliğinin ve alınmış yedeklerin üzerine kurulur.

Arada bir ara katman daha vardır: Instant Restore. İşletim sistemi içeren disk seviyesindeki bir yedekten sanal makine doğrudan başlatılır; makine çalışırken diskleri yedekten emüle edilir ve yalnızca oluşan değişiklikler için depolama alanı gerekir. Acronis, bu geçici makinenin en fazla üç gün tutulup ardından silinmesini veya kalıcı bir sanal makineye dönüştürülmesini önerir (Acronis Cyber Protect Cloud kullanıcı kılavuzu). Instant Restore kendi hipervizör kaynağınızı kullanır; Disaster Recovery ise kaynağı Acronis Cloud'dan sağlar, dolayısıyla üretim sahasının tamamen erişilemez olduğu senaryolarda çalışan tek seçenek odur.

Bu ayrım satın alma kararını da netleştirir. Yalnızca veri kaybına karşı korunmak isteyen kurumlar için Acronis Cyber Backup tarafındaki yedekleme çekirdeği yeterlidir. Kesinti süresinin doğrudan ciro veya hizmet kaybına dönüştüğü iş yüklerinde ise failover yeteneği gerekir. Uygulamada kurumlar iş yüklerini sınıflandırır: kritik olanlar Disaster Recovery kapsamına alınır, kalanlar yedekleme ve Instant Restore ile korunur.

RTO ve RPO hedefleri gerçekte ne kadar ve neye bağlı?

Kısa cevap: resmî hedef 15 dakikanın altında RPO ve RTO'dur (Acronis Advanced Disaster Recovery veri sayfası, 2022), ancak bu değer üç değişkene bağlıdır. Birincisi replikasyon sıklığı: kurtarma noktası ne kadar sık güncellenirse RPO o kadar daralır. İkincisi runbook tasarımı: kaç sunucunun, hangi sırayla ve hangi bağımlılıklarla ayağa kalkacağı RTO'yu belirler. Üçüncüsü ağ: kullanıcıların ve entegre sistemlerin buluttaki kopyaya nasıl erişeceği çözülmemişse sunucular çalışsa bile hizmet ayakta sayılmaz.

Bu nedenle hedef belirleme çalışmasını iş yükü bazında yapıyoruz. Her uygulama için üç soruya yazılı cevap arıyoruz: kaç dakikalık veri kaybı kabul edilebilir, hizmet kaç dakika içinde ayağa kalkmalı ve bu süre boyunca hangi manuel iş akışı devreye girecek. Piyasada zaman zaman "15 dakika ile 1 saat arası RPO" biçiminde bir üst sınır dolaşıma girse de Acronis'in resmî veri sayfasında böyle bir üst sınır yer almaz; belirtilen tek hedef 15 dakikanın altıdır. Bu nedenle hedefi bir vaat gibi değil, tatbikatla doğrulanması gereken çalışma noktası olarak ele alıyoruz.

Bir başka önemli nokta, failover'ın hangi kurtarma noktasına yapılacağıdır. Advanced Disaster Recovery paketinin resmî olarak eklediği yetenekler arasında "zararlı yazılım içermeyen kurtarma noktasına failover" da bulunur. Fidye yazılımı senaryosunda bu belirleyicidir: en güncel kurtarma noktası, saldırganın zaten sistemde olduğu bir ana denk gelebilir. Bu kontrolün etkin çalışması için yedeklerin taranması gerekir; bu yetenek Acronis Advanced Security + EDR eklentisiyle gelir. Ayrıca Eylül 2024'ten itibaren tüm Acronis-hosted depolamalarda 14 gün saklama süreli Governance modu değiştirilemez depolama varsayılan olarak etkindir (Acronis Cyber Protect 16 Web Help), yani failover yapılacak kurtarma noktasının silinmeye karşı bir direnci vardır.

Bulutta failover nasıl çalışır ve ağ bağlantısı nasıl kurulur?

Kısa cevap: korunan iş yükünün yedeği Acronis Cloud'a replike edilir, failover komutuyla bu kopya bulutta bir sanal makine olarak başlatılır ve kurumun ağı ile bulut arasındaki bağlantı üzerinden hizmet verir. Ağ tarafında iki temel model vardır: güvenli bir VPN tüneliyle yerel ağın buluta genişletilmesi veya VPN cihazı kurulmadan çalışan cloud-only mod. Resmî dokümantasyona göre en fazla 23 yerel ağ, güvenli VPN tüneli üzerinden buluta genişletilebilir (Acronis Cyber Protect Cloud kullanıcı kılavuzu).

Ağ modelinin seçimi uygulama mimarisine bağlıdır. Buluttaki sunucuların üretim ağıyla aynı IP bloğunda görünmesi gereken, sabit IP'ye bağlı entegrasyonları olan ortamlarda site-to-site VPN tercih edilir. Yalnızca birkaç bağımsız sunucunun ayağa kalkması yeterliyse cloud-only mod hem daha hızlı kurulur hem daha az bileşen gerektirir. Kurum tarafındaki tünel sonlandırma noktası genellikle mevcut güvenlik duvarıdır; Fortinet FortiGate gibi bir cihazla IPsec tüneli kuruluyorsa yönlendirme, NAT ve DNS kurallarının failover senaryosunda nasıl davranacağı önceden test edilmelidir.

Advanced Disaster Recovery paketinin resmî veri sayfasına göre standart Cyber Protect Cloud korumasında dosya, imaj ve uygulama yedeği, Instant Restore ile yerel kurtarma, test failover ve yalnızca-bulut VPN bağlantısı bulunur; paket bunun üzerine Acronis Cloud'a üretim ve test failover'ı, VPN'siz dağıtım seçeneği, IPsec çok-siteli VPN ile L2 site-to-site OpenVPN, çoklu runbook şablonları, özel DNS yapılandırması, DHCP sunucuları için felaket kurtarma ve zararlı yazılım içermeyen kurtarma noktasına failover ekler.

Tablodaki ayrım Acronis'in kendi Advanced Disaster Recovery veri sayfasındaki "zaten var olan" ve "paketin eklediği" listelerine dayanır (Acronis Advanced Disaster Recovery veri sayfası, 2022). Uygulamada en çok gözden kaçan kalem DNS'tir: buluttaki kopya ayağa kalksa bile isim çözümlemesi eski adresi göstermeye devam ediyorsa hizmet kullanıcıya ulaşmaz. Bu yüzden özel DNS yapılandırması ve TTL değerleri runbook tasarımının ayrılmaz parçasıdır.

Test failover ve felaket kurtarma tatbikatı nasıl yapılır?

Kısa cevap: test failover, üretim ortamına dokunmadan izole bir ağda buluttaki kopyaların çalıştırılmasıdır. Amaç sunucuların açılıp açılmadığını değil, hizmetin uçtan uca verilebildiğini görmektir: uygulama açılıyor mu, veritabanına bağlanıyor mu, kullanıcı oturum açabiliyor mu, entegrasyonlar cevap veriyor mu. Resmî veri sayfası test failover'ı Cyber Protect Cloud'un içerdiği yetenekler arasında listeler; Acronis Cloud'a üretim ve test failover'ı ile aylık veya haftalık zamanlanabilen otomatik test failover ise Advanced Disaster Recovery paketiyle gelir.

Tatbikatı anlamlı kılan, senaryonun gerçekçi olmasıdır. Kullandığımız yapı şudur: önce bir başlangıç senaryosu yazılır (örneğin ana veri merkezine erişimin tamamen kesilmesi), sonra runbook bu senaryoya göre çalıştırılır, ardından her adım için ölçülen süre ile hedeflenen süre karşılaştırılır ve son olarak sapmalar bir düzeltme listesine dönüştürülür. Tatbikat raporu iş birimlerine sunulur; çünkü RTO hedefini teknik ekip değil, iş sahibi belirler.

Tatbikat sıklığını belirleyen pratik bir kısıt da lisans tarafından gelir. Disaster Recovery aboneliği belirli miktarda compute point içerir ve failover ile test failover bu havuzdan tüketir; resmî lisans bilgi bankasına göre iş yükü başına bir yıllık abonelik 2.000 compute point içerir ve 2.000 puan yaklaşık olarak yılda iki haftalık failover veya test kullanımına karşılık gelir (Acronis Destek KB 73387, 2026). Bu, yılda birkaç kez ciddi bir tatbikat yapmak için rahat bir bütçedir; ancak sürekli açık bırakılan test ortamları için tasarlanmamıştır.

Tatbikat kapsamına yalnızca sunucuları değil, insanları da almak gerekir. Kimin failover kararını vereceği, kimin iletişim yürüteceği, hangi tedarikçilerin bilgilendirileceği ve failback (üretime geri dönüş) kararının hangi kriterle alınacağı yazılı olmalıdır. Bu tarafı olgunlaştırmak isteyen kurumlarda otomasyon, izleme ve altyapı standardizasyonu konularında DevOps ve altyapı hizmetlerimiz devreye girer.

Acronis Disaster Recovery nasıl lisanslanır ve ön koşulları nelerdir?

Kısa cevap: eklenti iş yükü başına lisanslanır, aktif bir Acronis Cyber Protect aboneliği ve bulut dağıtımı gerektirir. Abonelik süresine bağlı olarak belirli bir compute point havuzu içerir: iş yükü başına bir yıllık abonelik 2.000, üç yıllık 6.000, beş yıllık 10.000 compute point verir ve felaket kurtarma depolaması sınırsızdır (Acronis Destek KB 73387, 2026).

Bulut dağıtımı koşulu teknik bir ayrıntı değil, mimari bir kısıttır. Acronis'in resmî dokümantasyonunda hizmet olarak felaket kurtarma, yalnızca bulut dağıtımında bulunan yetenekler listesinde yer alır; aynı listede Microsoft 365 ve Google Workspace cloud-to-cloud yedekleme, public cloud'a yedekleme, EDR, Cyber Scripting, uzak masaüstü ve donanım envanteri de bulunur (Acronis Cyber Protect 16 Web Help). Dolayısıyla yalnızca Acronis Cyber Protect 16 ile şirket içi bir yönetim sunucusu işletiyorsanız, felaket kurtarma için Acronis Cyber Protect Cloud tarafına geçmeniz veya hibrit bir model kurgulamanız gerekir.

Şirket içi ve bulut yönetiminin hangi yetenekleri kapsadığı Acronis'in karşılaştırma bilgi bankasında kalem kalem listelenir; tape hedefi, Acronis Storage Node, PXE sunucusu ve Forensic Mode gibi bazı yetenekler yalnızca şirket içi tarafta, EDR ve DLP Device Control gibi bazıları ise yalnızca bulut tarafında bulunur (Acronis Destek KB 73376, 2025). Hibrit tasarımlarda hangi iş yükünün hangi konsoldan yönetileceğine bu tabloyu esas alarak karar veriyoruz. Fiyat yerine kapsam konuşmayı tercih ediyoruz: iş yükü sayısı, hedeflenen RTO ve tatbikat sıklığı netleştikten sonra teklif hazırlıyoruz.

İş sürekliliği planı hangi verilere ve hangi kararlara dayanmalı?

Kısa cevap: teknoloji seçiminden önce iş etki analizi gelir. Hangi süreçlerin kaç saat durabileceği, bu duruşun saatlik maliyeti, sürecin bağlı olduğu uygulamalar ve bu uygulamaların birbirine bağımlılık sırası belirlenmeden RTO ve RPO hedefleri rastgele sayılardan ibaret kalır. Felaket kurtarma projelerinde en sık gördüğümüz hata, tüm sunuculara aynı hedefin verilmesi ve bunun sonucunda hem maliyetin hem karmaşıklığın gereksiz yükselmesidir.

Tehdit tarafındaki veri de planın gerekçesini oluşturur. Verizon 2025 Data Breach Investigations Report, 139 ülkeden 22.052 güvenlik olayını ve 12.195 doğrulanmış veri ihlalini inceledi; fidye yazılımı incelenen ihlallerin %44'ünde bulundu ve KOBİ ihlallerinin %88'inde görülürken büyük kuruluşlarda bu oran %39'da kaldı. Medyan fidye ödemesi 115.000 USD'ye gerilerken kurban kuruluşların %64'ü fidye ödemedi (Verizon DBIR 2025). Fidye ödememenin uygulanabilir bir seçenek olması, doğrudan geri dönülebilir bir kopyanın ve çalışan bir kurtarma planının varlığına bağlıdır.

Planın teknik omurgasında üç kontrol birlikte durur. Değiştirilemez depolama, yedeğin silinmesini engelleyerek geri dönülecek noktayı korur. Şifreleme, kopyanın okunmasını engeller: Acronis yedek şifrelemesinde AES algoritması Galois/Counter (GCM) modunda ve rastgele üretilmiş 256-bit anahtarla çalışır; anahtar, parolanın SHA-2 (256-bit) özeti kullanılarak AES-256 ile şifrelenir ve parola diskte veya yedeklerde hiçbir yerde saklanmaz (Acronis Cyber Protect 16 Web Help). Üçüncü kontrol failover'dır ve hizmetin sürekliliğini sağlar. Bu üçlünün eksik bir ayağı, diğer ikisinin değerini düşürür.

Planın yazılı çıktısı da somut olmalıdır: iş yükü envanteri ve kritiklik sınıfları, iş yükü başına RTO/RPO hedefi, runbook adımları ve sıralaması, ağ ve DNS değişiklik planı, karar ve iletişim sorumlulukları, tatbikat takvimi ile failback prosedürü. Bu belgeyi projeyle birlikte üretiyor ve her tatbikat sonrasında güncelliyoruz.

KVKK, veri yerleşimi ve Türkiye bağlamında nelere dikkat etmeli?

Kısa cevap: KVKK belirli bir ürün zorunlu kılmaz ama kesinti sonrası hızlı faaliyete geçmeyi açıkça bekler. Kişisel Verileri Koruma Kurumu'nun Kişisel Veri Güvenliği Rehberi'nin "Kişisel Verilerin Yedeklenmesi" bölümü; verilerin zarar görmesi, yok olması veya çalınması hâlinde veri sorumlusunun yedeklenen verileri kullanarak en kısa sürede faaliyete geçmesi gerektiğini, fidye yazılımlarına karşı veri yedekleme stratejileri geliştirilmesinin önerildiğini, yedeklenen kişisel verilere yalnızca sistem yöneticisinin erişebilmesi ve veri seti yedeklerinin mutlaka ağ dışında tutulması gerektiğini belirtir (KVKK Kişisel Veri Güvenliği Rehberi).

"En kısa sürede faaliyete geçme" ifadesinin ölçülebilir karşılığı RTO hedefidir; "ağ dışında tutma" ifadesinin karşılığı ise buluttaki kopyadır. Felaket kurtarma bu iki maddeyi aynı anda karşılayan tek kontroldür. Buna karşılık verinin ve failover kaynağının fiziksel olarak nerede bulunacağı ayrı bir sorudur. Acronis'in resmî veri merkezi listesinde "Acronis Cloud DC" başlığı altında İstanbul da yer alır; liste Amerika, Avrupa ve Orta Doğu, Asya-Pasifik ile Afrika bölgelerine yayılmıştır ve Acronis ayrıca Google Cloud Platform ile Microsoft Azure lokasyonlarını listeler (Acronis Cyber Cloud Data Centers). Hangi bölgenin sizin kiracınıza atanabileceğini ve felaket kurtarma hizmetinin o bölgede sunulup sunulmadığını proje başında Acronis ile birlikte teyit ediyoruz.

Düzenlemeye tabi sektörlerde ek bir hazırlık daha gerekir: tatbikat kayıtlarının denetlenebilir olması. Test failover sonuçlarının, ölçülen sürelerin ve düzeltici aksiyonların raporlanması, denetim sorularına "planımız var" yerine "planımızı şu tarihte çalıştırdık ve şu süreyi ölçtük" cevabını vermenizi sağlar. Bu, felaket kurtarma yatırımının en somut geri dönüşlerinden biridir.

Buluttaki kopyanın kendisinin de korunması gerektiğini hatırlatmakta fayda var. Failover sonrası çalışan sunucular üretim iş yükü hâline geldiği için uç nokta ve sunucu güvenliği kontrollerinin orada da geçerli olması beklenir; Trend Micro Deep Security gibi sunucu odaklı koruma çözümleri kullanan kurumlarda failover senaryosunun bu ürünün lisans ve politika tarafında nasıl davranacağı önceden planlanmalıdır. Yama ve envanter yönetimini de aynı konsolda toplamak isteyen kurumlarda Acronis Advanced Management eklentisini birlikte değerlendiriyoruz.

Kritik iş yüklerinizin listesini, kabul edilebilir kesinti sürelerinizi ve mevcut Acronis kurulumunuzu paylaşın; Acronis Disaster Recovery kapsamının hangi iş yüklerini içermesi gerektiğini, hangi ağ modelinin uygun olduğunu ve tatbikat takvimini birlikte belirleyelim. Kapsam, runbook tasarımı ve devreye alma adımlarını içeren bir teklif hazırlayalım. İletişim sayfamızdan bize ulaşın — Türkçe teknik destek, felaket kurtarma tatbikatı ve kurulum sonrası işletme desteği dâhil çalışıyoruz.