BOYUT DEĞİŞTİRİLİYOR
BOYUT 00 // BAŞLANGIÇ

Bir sunucu düşün.
İçinde şirketin tüm faturaları.
Yarın sabah açılmazsa?

Bu yolculukta tek bir dosyayı takip edeceğiz: muhasebe sunucusu SRV-MUHASEBE içindeki fatura_2026.pdf. Onu üretim ortamından alıp, Veeam evreninin bütün boyutlarından geçirip, bir felaketin içinden sağ çıkaracağız. Sonunda yedeklemenin nasıl çalıştığını uçtan uca anlamış olacaksın.

GÖREV: fatura_2026.pdf'yi ölümsüz kıl. ARAÇ: Veeam Backup & Replication. SÜRE: 7 boyut.
BOYUT 01 // ÜRETİM ORTAMI

Her şey bir snapshot ile başlar.

Veeam çalışan bir VM'i asla durdurmaz. Bunun yerine hypervisor'a (vSphere/Hyper-V) "bu VM'in şu anki halinin fotoğrafını çek" der. Ama fotoğraftan önce kritik bir adım var: Application-Aware Processing. VM içine geçici bir runtime process gönderilir, Windows VSS tetiklenir; SQL, Exchange, Active Directory gibi uygulamalar disklerini tutarlı duruma getirir. Böylece yedekten dönen veritabanı "bozuk" değil, tertemiz uyanır.

SRV-MUHASEBE
📄 fatura_2026.pdf
durum: çalışıyor · kullanıcılar aktif
1 · Guest process enjekte edildi (VIX/WMI)
2 · VSS writer'lar donduruldu (freeze)
3 · Hypervisor snapshot alındı (<1 sn)
4 · VSS çözüldü (thaw) — kullanıcılar hiçbir şey fark etmedi
5 · Veeam artık donmuş kopyadan okuyor
Snapshot bir yedek değildir — sadece "değişiklikleri şimdilik başka dosyaya yaz" komutudur. Veeam okumayı bitirir bitirmez snapshot silinir (consolidate). Snapshot'ı günlerce açık bırakmak üretim diskini şişirir; Veeam bu yüzden işi biter bitmez temizler.
// önce snapshot almalısın
BOYUT 02 // BACKUP PROXY

Veri hangi yoldan akacak?
Rotayı sen seç.

Snapshot hazır. Şimdi Backup Proxy devreye girer: üzerindeki Veeam Data Mover servisi veriyi okur, sıkıştırır, tekilleştirir ve repository'ye yollar (veri kanalı: TCP 2500–3300). Ama önce bir karar var — proxy, VM diskine hangi transport moduyla ulaşacak? Birine tıkla:

▸ DIRECT STORAGE ACCESS

Proxy, üretim depolamasına FC/iSCSI/NFS ile doğrudan bağlanır. ESXi hostlarına ve üretim ağına hiç dokunmaz.

EN HIZLI

▸ VIRTUAL APPLIANCE (HOT-ADD)

Sanal proxy, VM'in disklerini SCSI hot-add ile kendine takar ve hypervisor I/O yığınından okur.

HIZLI · SANAL PROXY

▸ NETWORK (NBD/NBDSSL)

Veri, ESXi yönetim arayüzü üzerinden ağdan çekilir. En yavaşı — ama her ortamda çalışır.

EVRENSEL YEDEK PLAN

Peki neden 1 TB'lık disk dakikalar içinde yedeklenir?

Cevap: Changed Block Tracking (CBT). Hypervisor, son yedekten beri hangi blokların değiştiğini harita olarak tutar. Veeam sadece sorar: "dünden beri ne değişti?" — ve yalnızca o blokları okur. Butona bas, farkı gör:

değişmemiş blok değişen blok (CBT işaretledi) Veeam'in okuduğu
// bir transport modu seç ve CBT demosunu çalıştır
BOYUT 03 // YEDEK ZİNCİRİ

fatura_2026.pdf artık bir zincirin içinde yaşıyor.

Proxy'nin gönderdiği veri, repository'de dosyalara yazılır: Pazar günü tam yedek .VBK, hafta içi her gece değişenler .VIB (increment), zincirin haritası ise .VBM metadata dosyası. Restore anında Veeam bu zinciri okuyarak istediğin günü yeniden inşa eder. Kendin dene — birkaç gece yedek al:

▸ FOREVER FORWARD INCREMENTAL

Tek full + sonsuz increment. Saklama dolunca en eski VIB, VBK'ya merge edilir — az yer, az I/O. (Az önce yaptığın buydu.)

▸ REVERSE INCREMENTAL

En güncel nokta daima tam VBK'dır; eski haller .VRB dosyalarına geriye yazılır. En hızlı restore, ama yedek sırasında 3x I/O.

▸ SYNTHETIC FULL

Periyodik yeni full, üretimden değil mevcut zincirden repository üzerinde sentezlenir. Üretim hiç yorulmaz.

// en az 3 gece yedek al ve bir merge yap
BOYUT 04 // SCALE-OUT REPOSITORY

Yedek yaşlandıkça katman değiştirir.
Zamanı sen kaydır.

SOBR, birden çok depolamayı tek mantıksal havuzda birleştirir ve yedeklerin yaşam döngüsünü otomatik yönetir. Aşağıdaki kaydırıcıyla fatura_2026.pdf'nin yedeğini yaşlandır — hangi katmana süzüldüğünü izle:

BUGÜN30 GÜN90 GÜN1 YIL+
// yedek 0 günlük — Performance tier'da, anlık restore'a hazır

◉ PERFORMANCE TIER

Hızlı blok depolama. Günlük operasyonel restore'lar buradan saniyeler içinde döner.

YEDEK BURADA

◎ CAPACITY TIER

S3 uyumlu obje depolama. Move/copy politikasıyla yedekler otomatik buraya taşınır — site dışı kopya (3-2-1'in "1"i) kendiliğinden oluşur.

YEDEK BURADA

◌ ARCHIVE TIER

S3 Glacier / Azure Archive. En eski yedekler donmuş uzayda, en düşük maliyetle yıllarca saklanır.

YEDEK BURADA
İpucu: Capacity tier'da copy modu yedek daha Performance'tayken kopyasını buluta koyar (anında site dışı koruma); move modu ise belirlenen yaştan sonra taşıyıp yerel alanı boşaltır. İkisi birlikte de kullanılabilir.
BOYUT 05 // KARA DELİK

Saat 03:12. Ağa bir ransomware sızdı.
Önce yedekleri arıyor.

Modern saldırıların ilk hedefi üretim değil, yedeklerdir — çünkü yedeği olmayan kurban fidyeyi öder. Aşağıda iki repository var: sıradan bir Windows paylaşımı ve bir Hardened Repository (Linux + XFS immutability: yedekler belirlenen süre boyunca root bile olsa silinemez/değiştirilemez). Saldırıyı başlat, farkı gör:

SIRADAN REPOSITORY (SMB)

fatura.vbkpzt.vibsalı.vibçar.vibharita.vbm

HARDENED REPOSITORY ⛨

fatura.vbkpzt.vibsalı.vibçar.vibharita.vbm
✗ Sıradan repository: tüm yedekler şifrelendi. Kurtarma noktası yok.
✓ Hardened repository: immutability bayrağı yazma/silme isteklerini reddetti. Zincir sapasağlam.

Veeam'in diğer savunma katmanları da devrede: SureBackup yedekleri izole sanal laboratuvarda otomatik açıp doğrular (3-2-1-1-0'daki sıfır hata); v13'teki Threat Hunter yedek verisinde zararlı taraması yapar; inline entropy analizi şifreleme davranışını daha yedek alınırken yakalar; Veeam ONE ise anormal increment büyümesini görüp alarm çalar — şifreli veri sıkışmaz, artımlı yedek aniden şişer, teleskop bunu kaçırmaz.
// önce saldırıyı görmelisin
BOYUT 06 // GERİ DÖNÜŞ

Sabah 08:00. Patron kapıda:
"fatura_2026.pdf nerede?"

Üretim sunucusu şifrelendi ama Hardened Repository'deki zincir sağlam. Şimdi kritik soru: nasıl geri döneceksin? Veeam sana tek yol değil, senaryoya göre seçenek sunar. Birini seç:

▸ INSTANT RECOVERY

VM, yedek dosyasının içinden doğrudan çalıştırılır — Mount Service (TCP 9401) yedeği datastore gibi sunar. Dakikalar içinde ayaktasın; arka planda Storage vMotion ile üretime taşınır.

RTO: DAKİKALAR

▸ FILE-LEVEL RESTORE

Tüm VM'e gerek yok — yedek mount edilir, dosya gezgininden sadece fatura_2026.pdf çekilir. Guest Catalog indeksi sayesinde dosya aramayla saniyede bulunur.

TEK DOSYA

▸ FULL VM RESTORE

VM komple, istenen restore point'ten yeniden inşa edilir. En temiz dönüş — biraz daha uzun sürer, saldırı sonrası genelde antivirüs taramalı Secure Restore ile yapılır.

TAM YENİDEN İNŞA
// bir restore yöntemi seç
BOYUT 07 // KOMUTA MERKEZİ

Yolculuk tamam. İşte evrenin tam haritası.

fatura_2026.pdf kurtarıldı. Şimdi büyük resmi bağlayalım — tüm bu boyutları kim izler, kim yönetir?

▸ ENTERPRISE MANAGER

Birden çok VBR sunucusunu tek web konsolundan yönetir (TCP 9443). Federe katalog aramasıyla tüm sitelerdeki dosyalar tek sorguda bulunur; self-service portal ile kullanıcılar kendi dosyalarını kendileri kurtarır — gece 3'te kimse aranmaz.

▸ VEEAM ONE

İzleme ve raporlama teleskopu: SLA raporları, kapasite planlama, koruma boşluğu analizi ve az önce gördüğün ransomware anomali alarmları.

▸ v13 ÇAĞI

Güncel sürüm v13: Linux tabanlı sertleştirilmiş Software Appliance, tarayıcıdan Web UI, gRPC iletişimi, BLAKE3 hashing, Kerberos önceliği, Threat Hunter ve Veeam Intelligence AI asistanı.

BOYUT 01 — App-aware VSS + snapshot: tutarlı, kesintisiz fotoğraf
BOYUT 02 — Proxy + transport modu + CBT: sadece değişen bloklar akar
BOYUT 03 — VBK/VIB/VBM zinciri: her gece yeni bir zaman noktası
BOYUT 04 — SOBR: yaşlanan yedek Performance → Capacity → Archive'a süzülür
BOYUT 05 — Hardened repo + SureBackup + Threat Hunter: kara deliğe geçit yok
BOYUT 06 — Instant / file-level / full restore: senaryona göre dönüş
SONUÇ3-2-1-1-0: 3 kopya · 2 ortam · 1 site dışı · 1 immutable · 0 doğrulama hatası
SERVİSGÖREVPORT
Veeam Backup ServiceJob motoru & koordinasyon (VBR)TCP 9392
Guest Catalog ServiceDosya indeksleme kataloğuTCP 9393
Mount ServiceInstant recovery / dosya restore mountTCP 9401
Installer ServiceBileşen dağıtımı (tüm yönetilen sunucular)TCP 6160
Transport ServiceProxy/repository bileşen iletişimiTCP 6162
Data Mover kanallarıAsıl yedek veri akışıTCP 2500–3300
Enterprise ManagerWeb UI & REST APITCP 9443
PostgreSQLConfiguration DB (v12+ varsayılan)TCP 5432