ERP Yazılımları · by Yazılım Koçu2026
BT ALTYAPI · ANA REHBER

Sunucu Sanallaştırma & Yedekleme Çözümü

VMware/Veeam lisans yenileme, alternatif/yerli sanallaştırma-yedekleme çözümüne geçiş, replikasyon ve felaket kurtarma — kesintisiz iş sürekliliği için uçtan uca kurgu.

Kamu ve özel sektörde son yıllarda en çok tekrar eden BT alımı sunucu sanallaştırma ve yedekleme kalemidir: "VMware Yazılımları Lisans Yenileme", "Yedekleme Yazılımı (Veeam) Lisans Yenilemesi", "Sanallaştırma + Yedekleme + Replikasyon". Lisans fiyatlarındaki artış, kurumları alternatif arayışına ve TCO odaklı kararlara itti. Bu sayfa, bu yatırımı planlayan bilgi işlem ekipleri için kapsamı ve seçim kriterlerini anlatır.

Çözüm neyi kapsar?

  • Sanallaştırma: Hipervizör kurulumu/geçişi, VM konsolidasyonu, yüksek erişilebilirlik (HA) ve kaynak yönetimi.
  • Yedekleme: Görüntü/dosya bazlı yedekleme, değiştirilemez (immutable) ve saha-dışı kopya, doğrulama.
  • Replikasyon & Felaket Kurtarma: İkincil sahaya replikasyon, DR planı ve düzenli tatbikat.
  • Lisans & Destek: Yenileme veya alternatif çözüme geçiş, SLA’lı bakım.

VMware/Veeam yenileme mi, alternatife geçiş mi?

KriterMevcut lisans yenilemeAlternatif/yerli çözüme geçiş
İlk maliyetDüşük geçiş, artan lisansGeçiş maliyeti + genelde düşük lisans
RiskDüşük (aynı ortam)Orta (migrasyon + eğitim)
BağımlılıkTek üreticiye bağımlılık sürerBağımlılık azalır
En uygunKısa vadeli, kritik üretimYüksek VM sayısı, TCO odağı

Karar, bir PoC (kanıtlama) ve 3-5 yıllık TCO karşılaştırmasıyla verilmelidir. TCO ≈ lisans + bakım + donanım + operasyon + geçiş maliyeti; alternatif çözümlerde eğitim ve olası uyumluluk kalemleri de eklenir.

İş sürekliliği: RPO, RTO ve 3-2-1

Yedekleme sıklığınızı RPO (kabul edilebilir veri kaybı), felaket kurtarma tasarımınızı RTO (ayağa kalkma süresi) belirler. Verinin 3 kopyası, 2 farklı ortam ve 1 saha-dışı kopya (3-2-1) tutulmalı; fidye yazılımına karşı değiştirilemez (immutable) ve hava boşluklu (air-gapped) yedek şart koşulmalıdır.

Rakamlarla tehdit ve pazar tablosu

Bu yatırımın aciliyeti iki veriyle netleşir. Birincisi tehdit tarafı: Veeam'in 1.300'den fazla kurumla yürüttüğü 2025 Ransomware Trends Raporu'na göre kuruluşların %69'u son bir yılda en az bir fidye yazılımı saldırısı yaşadı; saldırganların %89'u doğrudan yedek depolarını hedef aldı ve saldırıya uğrayanların yalnızca %10'u verisinin %90'ından fazlasını kurtarabildi. Yedekleme kurgusunun değiştirilemez (immutable) kopya olmadan tasarlanması, bu tabloda artık kabul edilebilir bir risk değildir.

İkincisi pazar tarafı: Broadcom'un VMware'i satın almasının ardından yaşanan lisans modeli ve fiyat değişiklikleri, kurumları alternatif değerlendirmeye itti. Gartner'ın öngörüsüne göre mevcut VMware iş yüklerinin %35'i 2028'e kadar alternatif platformlara taşınacak (aktaran Network World, 2025). Bu iki veri birlikte okunduğunda sonuç şudur: sanallaştırma-yedekleme kararı yalnızca bir lisans yenileme kalemi değil; iş sürekliliği mimarisinin ve 3-5 yıllık maliyet stratejisinin yeniden tasarlandığı bir dönüm noktasıdır.

Temsili proje kapsamı

Aşağıdaki kapsam temsilîdir; gerçekleşmiş bir projeyi değil, bu tür bir işin sağlıklı biçimde nasıl aşamalandırılacağını gösterir. Gerçek kapsam, ortam envanterine göre birlikte çıkarılır.

  • 1. Envanter ve keşif: Host, VM, depolama ve ağ envanteri; iş yüklerinin kritiklik sınıflandırması, mevcut lisans ve destek durumunun çıkarılması.
  • 2. Hedef mimari ve TCO: Yenileme / alternatife geçiş / hibrit seçeneklerinin 3-5 yıllık TCO karşılaştırması; RPO/RTO hedeflerinin iş birimleriyle netleştirilmesi.
  • 3. PoC (kanıtlama): Seçilen platformun kurumun kendi iş yükleriyle izole ortamda testi; performans, HA ve yedekleme entegrasyonunun doğrulanması.
  • 4. Migrasyon dalgaları: Test → ikincil → kritik üretim sırasıyla, her VM için geri dönüş planlı, ölçülmüş kesinti pencereli taşıma.
  • 5. Yedekleme ve DR kurgusu: 3-2-1 düzeni, immutable kopya, ikincil sahaya replikasyon ve ilk DR tatbikatının koşulması.
  • 6. Devir ve işletme: Dokümantasyon, yönetici eğitimi, izleme/alarm kurulumu ve SLA'lı destek modeline geçiş.

Teknik şartnamede dikkat edilecekler

  • Lisans modeli (çekirdek/soket/VM), kapsanan host/VM sayısı açıkça yazılmalı.
  • RPO/RTO hedefleri, replikasyon ve DR tatbikatı zorunlu madde olmalı.
  • Immutable + offsite yedek, fidye yazılımı koruması istenmeli.
  • Yerli/alternatif çözümlerde mevcut ortamla uyumluluk ve veri/yapılandırma dışa aktarımı (lock-in önlemi) garanti edilmeli.
  • SLA (yanıt/çözüm süreleri), kurulum, migrasyon ve eğitim kapsamı net olmalı.

Mevcut sanallaştırma ve yedekleme ortamınızı birlikte inceleyip, TCO karşılaştırması ve size özel bir yol haritası çıkaralım. Aşağıdaki formdan ihtiyacınızı iletmeniz yeterli.

SIK SORULAN SORULAR

Merak edilenler

VMware/Veeam lisans maliyetleri arttı; nasıl bir yol izlemeliyim?

Üç seçenek vardır: (1) mevcut lisansı yenilemek, (2) alternatif/yerli sanallaştırma-yedekleme çözümüne geçmek, (3) hibrit kurgu. Karar; sanal makine (VM) sayısı, iş sürekliliği hedefleri (RPO/RTO), personel yetkinliği ve 3-5 yıllık toplam sahip olma maliyeti (TCO) karşılaştırmasıyla verilmelidir. Migrasyon öncesi mutlaka bir kanıtlama (PoC) önerilir.

RPO ve RTO ne demek, neden önemli?

RPO (Recovery Point Objective) bir kesintide kabul edilebilir maksimum VERİ kaybı süresidir; RTO (Recovery Time Objective) sistemin yeniden ayağa kalkması için hedeflenen SÜREDİR. Yedekleme sıklığınızı RPO, felaket kurtarma tasarımınızı RTO belirler. Örneğin RPO 1 saat / RTO 4 saat gibi hedefler şartnamede net yazılmalıdır.

3-2-1 yedekleme kuralı nedir?

Verinin en az 3 kopyası, 2 farklı ortam (ör. disk + nesne depolama/teyp) ve 1 kopya saha dışında (offsite/offline) tutulur. Fidye yazılımına karşı değiştirilemez (immutable) yedek ve hava boşluklu (air-gapped) kopya bugün kritik önerilerdir.

Sanallaştırma maliyetini hangi faktörler belirler?

VM ve fiziksel ana makine (host) sayısı, çekirdek/soket bazlı lisans modeli, yedeklenecek veri hacmi, replikasyon/felaket kurtarma ihtiyacı ve destek/SLA kapsamı. Sabit liste fiyatı yerine mevcut ortam envanterine dayalı bir TCO çıkarımı öneririz.

Proxmox, Hyper-V, OpenStack gibi alternatifler nasıl değerlendirilmeli?

Dört eksende karşılaştırın: (1) Uyumluluk — mevcut depolama, ağ ve yedekleme araçlarınızla çalışıyor mu, V2V geçiş araçları olgun mu? (2) Operasyon — ekibinizin yetkinliği ve yönetim aracının olgunluğu; canlı taşıma (live migration), HA ve yedekleme entegrasyonu üretim seviyesinde mi? (3) Destek — ticari destek paketi, yerel iş ortağı ve SLA seçeneği var mı, yoksa yalnızca topluluk desteği mi? (4) TCO — lisans, donanım, eğitim ve geçiş maliyetinin 3-5 yıllık toplamı. Karar mutlaka kendi iş yükünüzle yapılan bir PoC ile doğrulanmalı; başka kurumun sonucu sizin ortamınızı temsil etmez.

Migrasyon sırasında kesinti olur mu, nasıl azaltılır?

Doğru planlanan geçişte kesinti, sunucu başına dakikalar mertebesine indirilebilir. Standart yöntem şudur: VM diski çalışırken hedef platforma kopyalanır (ön senkron), kesim (cutover) anında yalnızca son değişiklikler aktarılır ve makine hedefte açılır. Kritik sistemler için geçiş, düşük trafikli bakım pencerelerine dalgalar hâlinde planlanır; her dalgada önce test/geliştirme, sonra ikincil, en son kritik üretim taşınır. Her VM için geri dönüş (rollback) planı hazırlanır: hedefte doğrulama başarısızsa kaynak makine yeniden açılır. Kesintisiz olacağı iddiası değil, ölçülmüş kesinti penceresi taahhüdü isteyin.

Yedekten dönüş (restore) testleri ne sıklıkla yapılmalı?

Yedek almak ile geri dönebilmek farklı şeylerdir; test edilmemiş yedek, varsayımdan ibarettir. İyi pratik üç katmanlıdır: yedekleme yazılımının otomatik doğrulaması (bütünlük ve açılabilirlik kontrolü) her yedekte çalışmalı; kritik sistemler için izole ortamda gerçek geri dönüş testi düzenli aralıklarla — yaygın uygulama ayda bir veya çeyrekte bir — yapılmalı; tam felaket kurtarma tatbikatı ise senaryolu biçimde yılda en az bir kez koşulmalıdır. Test sonuçları (dönüş süresi, veri kaybı) ölçülüp RPO/RTO hedefleriyle karşılaştırılmalı ve sapmalar iyileştirme planına bağlanmalıdır.

SONRAKİ ADIM

Süreçleriniz kutuya sığmıyorsa, size özel ERP geliştirelim.

İhtiyacınızı yazın; süreçlerinizi analiz eder, size özel ERP mi yoksa mevcut ERP’nizin özelleştirmesi mi gerektiğini birlikte belirler, 1 iş günü içinde döneriz. Hazır paket değil — kaynak kodu sizin.

Talep Oluştur