Veeam VBK Dosyası Kurtarma

Bozulan, Silinen ve Şifrelenen Veeam Yedek Dosyalarından Veri Kurtarma

Veeam yedek dosyaları sunucu çökmesi, disk arızası, RAID yapısının bozulması, dosya sistemi hatası, eksik kopyalama, yanlışlıkla silme veya yetkisiz müdahale sonucunda kullanılamaz hale gelebilir. VBK dosyası klasörde görünmesine rağmen Veeam tarafından açılamayabilir, içe aktarılamayabilir veya geri yükleme işlemi sırasında hata verebilir. Sorun her zaman yalnızca VBK dosyasıyla sınırlı kalmaz. Aynı yedek zincirindeki VIB, VRB ve VBM dosyaları ile VMware, Hyper-V, SQL Server, Exchange, Active Directory, PostgreSQL ve Oracle sistemlerine ait kritik veriler de zarar görebilir. Bu tür olaylarda yalnızca görünen dosya üzerinde işlem yapılması yeterli değildir. Yedeklerin bulunduğu sunucu, repository alanı, RAID sistemi, NAS cihazı, dosya sistemi, yedek zinciri ve kaynak diskler birlikte değerlendirilmelidir.

Veeam Yedek Dosyalarının Açılamamasına Neden Olan Sorunlar

Veeam yedeklerinin bozulması her zaman yedekleme yazılımından kaynaklanmaz. Çoğu olayda asıl sorun, yedeklerin bulunduğu depolama alanında veya sunucu sisteminde meydana gelir. Yedekleme sunucusunun ani şekilde kapanması, elektrik kesintisi, işletim sisteminin çökmesi veya yedekleme tamamlanmadan bağlantının kesilmesi sonucunda VBK dosyası yarım kalabilir. Dosya normal boyutta görünse bile son bölümü yazılmamış, metadata alanları eksik oluşmuş veya bazı veri blokları hatalı kaydedilmiş olabilir.

Hard disklerde meydana gelen bad sector sorunları, SSD arızaları, RAID kontrolcüsü problemleri ve NAS depolama havuzunun bozulması da yedek dosyalarının okunmasını engelleyebilir. Yüksek boyutlu VBK dosyaları disk üzerinde geniş bir alana yayıldığından yalnızca birkaç kritik sektörün okunamaması bile dosyanın tamamen açılamamasına yol açabilir. Dosya sistemi hataları, yanlış biçimlendirme, eksik kopyalama, depolama alanının dolması, silinen dosyaların üzerine yeni veri yazılması ve yedek zincirindeki dosyalardan birinin kaybolması da sık karşılaşılan sorunlar arasındadır.

Sunucu Çökmesi Sonucu Bozulan VBK Dosyaları

Veeam yedekleme sunucusunun çökmesi halinde repository alanına erişilemeyebilir. Sunucu işletim sistemi açılmayabilir, RAID kontrolcüsü hata verebilir veya depolama sistemindeki disklerden biri ya da birkaçı arızalanmış olabilir. Özellikle yedekleme devam ederken meydana gelen sunucu çökmesinde VBK veya VIB dosyası tamamlanmadan kalabilir. Dosya klasörde mevcut olsa bile içeriğindeki bazı bölümler oluşmamış olabilir. Bu durumda Veeam dosyayı tanımayabilir veya geri yükleme işlemi belirli bir aşamada durabilir. Sunucunun yeniden çalışır hale getirilmesi veri kurtarma için her zaman gerekli değildir. Disklerin okunabilir durumda olması halinde depolama yapısı farklı bir sistem üzerinde incelenebilir. Kaynak diskler üzerinden RAID yapısı sanal olarak oluşturularak mevcut ve silinen yedek dosyaları araştırılabilir.

Disk Arızası Nedeniyle Okunamayan VBK Dosyaları

Fiziksel arızalı bir diskten standart dosya kopyalama yöntemiyle VBK almaya çalışmak risklidir. Diskin uzun süre okunmaya zorlanması arızanın ilerlemesine, daha önce erişilebilen sektörlerin de okunamaz hale gelmesine neden olabilir. Diskte bağlantı kopması, aşırı yavaşlama, okuma hatası veya mekanik ses bulunuyorsa öncelikle sektör bazlı imaj alınması gerekir. Okunabilen alanlar sağlıklı bir depolama birimine aktarılır ve kurtarma çalışması kaynak disk yerine oluşturulan kopya üzerinde yürütülür. VBK dosyasının büyük kısmı sağlam olsa bile başlangıç bilgilerinin, metadata alanlarının veya gerekli veri bloklarının okunamaması geri yükleme işlemini engelleyebilir. Hasarın konumuna göre dosyanın tamamı yerine sağlam kalan sanal makineler, diskler veya klasörler çıkarılabilir.

RAID Bozulması Sonucu Erişilemeyen Veeam Yedekleri

Veeam repository alanları sıklıkla RAID sistemleri üzerinde tutulur. Disklerden birinin veya birkaçının arızalanması, disk sıralamasının değişmesi, RAID kontrolcüsünün bozulması ya da yanlış yeniden yapılandırma işlemi bütün yedekleme havuzunun erişilemez hale gelmesine neden olabilir. RAID incelemesinde disk sıralaması, RAID seviyesi, stripe boyutu, parity düzeni ve başlangıç alanları belirlenir. RAID yapısı kaynak diskler üzerinde doğrudan yeniden oluşturulmaz. Öncelikle sanal olarak yapılandırılır ve dosya sistemi bu yapı üzerinden incelenir. Yanlış disk sıralamasıyla başlatılan RAID rebuild işlemleri mevcut yedeklerin bulunduğu alanların üzerine yeni parity verileri yazabilir. Bu nedenle arızalı sistem üzerinde deneme yapılmadan önce disklerin mevcut durumunun korunması önemlidir.

NAS Üzerinde Bozulan veya Silinen Veeam Yedekleri

Veeam yedekleri Synology, QNAP ve benzeri NAS cihazlarında tutulabilir. NAS cihazının açılmaması, disk grubunun dağılması, depolama havuzunun bozulması veya dosya sisteminin zarar görmesi sonucunda yedek klasörlerine erişilemeyebilir. Bazı durumlarda NAS cihazı çalışır görünür ancak repository klasörleri boş olabilir. Dosyalar görünmesine rağmen içerikleri okunamayabilir veya dosya boyutları hatalı görüntülenebilir. NAS diskleri ayrı ayrı incelenerek kullanılan RAID ve dosya sistemi yapısı belirlenir. Ardından mevcut ve silinen Veeam yedek dosyaları araştırılır. NAS üzerinde yeni havuz oluşturulması, disk grubunun yeniden kurulması veya yeni yedek alınması silinen dosyaların bulunduğu alanların üzerine veri yazılmasına neden olabilir.

Eksik veya Bozulan Veeam Yedek Zincirleri

Veeam yedek zincirinde tam yedeği içeren VBK dosyasına bağlı birden fazla VIB veya VRB dosyası bulunabilir. Zincirin ortasındaki bir dosyanın silinmesi, bozulması veya okunamaması sonraki geri yükleme noktalarının da kullanılamamasına yol açabilir. Dosyalar klasörde mevcut olsa bile gerekli ara geri yükleme noktası eksik olduğunda güncel yedeğe ulaşılamayabilir.  İnceleme sırasında mevcut bütün VBK, VIB, VRB ve VBM dosyaları tarih, boyut ve içerik yapısına göre karşılaştırılır. Eksik dosyaya ait dosya sistemi kayıtları ve veri blokları kaynak repository üzerinde aranır. Yedek zincirinin tamamı yeniden çalışır hale getirilemese bile bozulmadan önceki son sağlam geri yükleme noktasına ulaşılabilir. Bazı durumlarda yalnızca belirli bir sanal makine, sanal disk, veri tabanı veya klasör kurtarılabilir.

Silinen veya Bozulan VBM Dosyaları

VBM dosyasının silinmesi veya bozulması halinde Veeam mevcut yedek zincirini otomatik olarak tanıyamayabilir. VBK ve VIB dosyaları sağlam olsa bile yedekler konsolda görünmeyebilir veya içe aktarma sırasında hata oluşabilir. VBM dosyası bulunamadığında mevcut VBK dosyaları üzerinden içe aktarma denenebilir. Ancak VBK dosyasında da bozulma bulunuyorsa standart içe aktarma işlemi yeterli olmayabilir. Bu durumda dosyanın iç yapısı, veri blokları ve yedek içerisindeki sanal diskler ayrıca incelenir. Kaynak repository mevcutsa silinen VBM dosyasına ait dosya sistemi kayıtları ve veri alanları da araştırılabilir.

BCO Veeam Yapılandırma Yedeğinin Silinmesi veya Bozulması

Veeam sunucusuna ait yapılandırma yedekleri BCO uzantılı dosyalarda saklanabilir. Bu dosyalar yedekleme görevleri, repository tanımları ve Veeam yapılandırmasıyla ilgili bilgiler içerebilir. BCO dosyasının kaybolması VBK içerisindeki yedek verilerini doğrudan yok etmez. Ancak Veeam altyapısının önceki görevleri, bağlantıları ve yapılandırmasıyla birlikte yeniden kurulmasını zorlaştırabilir. Bozulan veya silinen BCO dosyaları kaynak repository üzerinde aranabilir. BCO dosyası bulunamasa bile mevcut VBK, VIB, VRB ve VBM dosyaları üzerinden ayrı bir kurtarma ve içe aktarma çalışması yapılabilir.

Dosya Boyutu Normal Görünen Ancak Açılmayan VBK Dosyaları

Bir VBK dosyasının doğru boyutta görünmesi, dosya içerisindeki bütün verilerin sağlam olduğu anlamına gelmez. Dosya sistemi üzerinde 2 TB görünen bir yedek dosyasının belirli bölümleri sıfır değerleriyle doldurulmuş, tekrar eden veri blokları oluşmuş veya dosyanın son kısmı eksik kalmış olabilir. Bazı depolama sorunlarında dosya adı, tarihi ve boyutu korunur ancak disk üzerindeki gerçek veri alanları okunamaz durumdadır. Dosya klasörde görünmeye devam ederken Veeam tarafından açılamaz. İnceleme sırasında dosyanın başlangıç, orta ve son bölümleri kontrol edilir. Tekrarlayan, sıfırlanmış, eksik, şifrelenmiş veya okunamayan alanlar belirlenir. Hasar dosyanın yalnızca belirli bir bölümündeyse sağlam kalan veriler üzerinden kurtarma çalışması yapılabilir.

Sıfırlanan VBK Dosyalarından Veri Kurtarma

Bazı olaylarda VBK dosyasının tamamı veya belirli bölümleri sıfır değerleriyle doldurulabilir. Bu durum depolama sistemi hatası, yanlış yazma işlemi, yazılım problemi veya bilinçli müdahale sonucunda oluşabilir. Üzerine gerçekten sıfır yazılmış bir veri bloğunun önceki içeriği aynı alan üzerinden geri getirilemez. Ancak dosyanın tamamının mı yoksa yalnızca belirli bölümlerinin mi sıfırlandığı kontrol edilmelidir. VBK dosyasının bir kısmı sağlam kalmışsa bu alanlardan sanal disk, veri tabanı veya kullanıcı dosyaları çıkarılabilir. Ayrıca kaynak repository üzerinde silinen eski VBK dosyaları, önceki tam yedekler, geçici dosyalar, snapshot alanları ve kullanılmayan disk bölümleri araştırılır.

Yanlışlıkla Silinen VBK Dosyalarının Kurtarılması

VBK dosyası silindiğinde veri her zaman disk üzerinden anında kaldırılmaz. Dosya sistemindeki kayıt silinir ve dosyanın kullandığı alanlar yeni veriler için kullanılabilir olarak işaretlenir. Silme işleminden sonra repository üzerinde yeni yedek alınmamış ve ilgili alanların üzerine veri yazılmamışsa dosyanın tamamı veya bir bölümü kurtarılabilir. Yeni bir tam yedek oluşturulması, silinen VBK dosyasına ait blokların üzerine yazılmasına neden olabilir. Bu nedenle silme işlemi fark edildiğinde Veeam görevleri durdurulmalı ve repository alanı kullanılmamalıdır. SSD tabanlı repository sistemlerinde TRIM işlemi silinen veri bloklarının temizlenmesini hızlandırabilir. Hard disk tabanlı sistemlerde üzerine yazılmamış veri alanlarının bulunma olasılığı daha yüksek olabilir.

Eksik veya Yarım Kopyalanmış VBK Dosyaları

VBK dosyası başka bir diske, NAS cihazına veya uzak sunucuya kopyalanırken aktarım yarıda kesilebilir. Dosya hedef klasörde görünmesine rağmen içeriğin tamamı kopyalanmamış olabilir. Bu tür dosyalarda içe aktarma hatası, bütünlük hatası veya dosyanın beklenmedik şekilde sona erdiğini belirten uyarılar görülebilir. Eksik kopyanın yanında kaynak depolama alanı da incelenmelidir. Kaynak disk üzerinde dosyanın tam veya daha sağlam bir kopyası bulunabilir. Aynı dosyaya ait birden fazla kopya varsa bütün kopyalar korunmalıdır. Bir kopyada bozuk olan veri alanı diğer kopyada sağlam olabilir.

Ransomware ve Fidye Yazılımı Sonucu Zarar Gören Yedek Dosyaları

Fidye yazılımı saldırılarında yalnızca kullanıcıların günlük olarak kullandığı Word, Excel, PDF, fotoğraf ve proje dosyaları hedef alınmaz. Saldırganların temel amaçlarından biri, kurumun yedekten geri dönüş yapmasını engellemektir. Bu nedenle saldırı sırasında yedekleme sunucuları, Veeam repository alanları, NAS cihazları, RAID sistemleri, sanal sunucular ve veri tabanı yedekleri de hedef alınabilir. Sunucuya yönetici yetkisiyle erişim sağlayan saldırgan, aktif dosyaları şifrelemeden önce yedekleme servislerini durdurabilir, geri yükleme noktalarını silebilir ve yedeklerin bulunduğu depolama alanlarını kontrol edebilir. Bazı olaylarda yedek dosyaları doğrudan şifrelenirken bazı olaylarda dosyalar silinir, içerikleri değiştirilir veya belirli bölümleri sıfır değerleriyle doldurulur. Amaç, şirketin çalışan sistemlerini ve yedeklerini aynı anda kullanılamaz hale getirerek fidye talep etmektir. Saldırgan şifre çözme anahtarını sağlayacağını veya silinen verileri geri getireceğini iddia edebilir. Ancak ödeme yapılması dosyaların eksiksiz biçimde geri döneceğini garanti etmez.

Saldırganlar Yedekleme Sistemine Nasıl Erişir?

Fidye yazılımı saldırılarında yedekleme sistemine erişim çoğu zaman doğrudan yedek dosyasına yapılan tek bir işlemden ibaret değildir. Saldırgan önce sunucuda yetki elde edebilir, ardından ağ üzerindeki diğer sistemleri araştırabilir.

Elde edilen kullanıcı adı ve parolalarla Veeam sunucusuna, Windows sunucularına, NAS cihazlarına, sanallaştırma ortamına veya uzak masaüstü bağlantılarına erişilebilir.

Yönetici yetkileri ele geçirildiğinde yedekleme görevleri durdurulabilir, repository klasörleri görüntülenebilir ve geri yükleme noktalarına müdahale edilebilir.

Bazı saldırılarda zararlı yazılım yedek dosyalarını otomatik olarak bulur. Bazı saldırılarda ise saldırgan sisteme uzaktan bağlanarak hangi dosyaların ve depolama alanlarının önemli olduğunu manuel olarak belirler.

Büyük boyutlu VBK, VMDK, VHDX, MDF ve BAK dosyaları bu nedenle özellikle hedef alınabilir.

Saldırganlar ayrıca Windows gölge kopyalarını ve sistem geri yükleme noktalarını silebilir. Böylece yalnızca Veeam yedekleri değil, işletim sistemi üzerinden yapılabilecek geri dönüş seçenekleri de ortadan kaldırılmaya çalışılır.

Fidye Yazılımı Yedek Dosyalarına Nasıl Zarar Verir?

Her saldırıda aynı yöntem kullanılmaz. Yedek dosyası tamamen şifrelenebilir, kısmen değiştirilebilir, silinebilir veya dosyanın belirli alanları bozularak standart programlarla açılması engellenebilir.

• Dosyanın tamamının şifrelenmesi
• Dosyanın başlangıç bölümünün şifrelenmesi
• Metadata alanlarının değiştirilmesi
• Dosyanın belirli veri bloklarının bozulması
• Orijinal dosyanın silinerek şifreli kopya oluşturulması
• Dosya adının veya uzantısının değiştirilmesi
• Dosyanın sıfır değerleriyle doldurulması
• Yedek zincirindeki tek bir dosyanın silinmesi
• Repository klasörünün tamamen kaldırılması
• Dosya sistemi kayıtlarının bozulması
• RAID veya depolama havuzunun yeniden yapılandırılması
• Snapshot ve checkpoint dosyalarının silinmesi

Dosyanın klasörde görünmeye devam etmesi onun sağlam olduğu anlamına gelmez. Örneğin bir VBK dosyası 1 TB boyutunda görünmesine rağmen dosyanın başlangıç alanı veya belirli veri blokları şifrelenmiş olabilir. Bu durumda dosya boyutu normal görünür ancak Veeam tarafından açılamaz.

Fidye Yazılımı Sonucu Zarar Gören VBK Dosyaları

VBK dosyaları tam yedek verisini içerdiği için saldırganlar açısından önemli hedeflerden biridir. VBK dosyasının şifrelenmesi veya silinmesi ona bağlı geri yükleme noktalarının da kullanılamamasına neden olabilir. Bazı saldırılarda VBK dosyasının tamamı şifrelenmez. Dosya çok büyük olduğu için yalnızca başlangıç bölümü, metadata alanı veya belirli aralıklarla seçilen veri blokları değiştirilebilir. Bu yöntem dosyanın kısa sürede kullanılamaz hale getirilmesini sağlar. VBK dosyasının yalnızca bazı bölümleri zarar görmüşse sağlam kalan alanlardan veri çıkarılması mümkün olabilir. Dosya içerisindeki bütün sanal makineler aynı ölçüde etkilenmemiş olabilir. Bir sanal diske ait bloklar hasarlı durumdayken başka bir sanal makinenin verileri okunabilir durumda kalabilir. Mevcut VBK dosyası tamamen açılamasa bile içerisindeki VMDK, VHDX veya veri tabanı dosyalarına ait sağlam bloklar ayrıca araştırılabilir.

VIB ve VRB Dosyalarının Silinmesi veya Şifrelenmesi

Veeam yedek zincirinde VBK dosyasına bağlı VIB veya VRB dosyaları bulunabilir. Bu dosyalar belirli tarihler arasında değişen veri bloklarını içerir. Saldırgan yedek zincirinin tamamını silmek yerine zincirin ortasındaki tek bir VIB dosyasına müdahale edebilir. Aradaki dosyanın kaybolması, daha sonraki geri yükleme noktalarının da açılamamasına neden olabilir. Örneğin tam yedeğin ardından oluşturulmuş altı VIB dosyası bulunuyorsa ve üçüncü VIB dosyası silinmişse dördüncü, beşinci ve altıncı dosyalar klasörde mevcut olsa bile ilgili zincir kullanılamayabilir. Bu durumda mevcut dosyalar tarih, boyut ve veri yapısına göre incelenir. Eksik VIB veya VRB dosyasına ait dosya sistemi kayıtları repository üzerinde aranır. Bozuk dosyanın tamamı kurtarılamasa bile önceki sağlam geri yükleme noktasına ulaşılması mümkün olabilir.

VBM Dosyasının Silinmesi veya Değiştirilmesi

VBM dosyası yedek zinciri, geri yükleme noktaları ve yedeklenen sistemlerle ilgili bilgiler içerir. Saldırgan VBM dosyasını silerek veya içeriğini bozarak yedeklerin Veeam konsolunda görünmesini engelleyebilir. VBK ve VIB dosyaları sağlam durumda olsa bile VBM dosyasının eksik olması yedek zincirinin otomatik olarak tanınmamasına neden olabilir. Ancak VBM dosyasının kaybolması, yedek içerisindeki gerçek verilerin de silindiği anlamına gelmez. Bu tür olaylarda mevcut VBK dosyaları üzerinden içe aktarma denenebilir. Yedek dosyalarının iç yapıları ve birbirleriyle bağlantıları ayrıca kontrol edilir. Kaynak repository mevcutsa silinen VBM dosyasına ait veri blokları da araştırılabilir.

BCO Yapılandırma Yedeklerinin Hedef Alınması

BCO dosyaları Veeam yapılandırma yedeklerini içerebilir. Yedekleme görevleri, repository tanımları ve sistem yapılandırmasıyla ilgili bilgilerin yeniden kurulmasında kullanılabilir. Saldırgan BCO dosyasını silerek veya şifreleyerek Veeam altyapısının eski yapılandırmasıyla yeniden kurulmasını zorlaştırabilir. BCO dosyasının kaybolması VBK içerisindeki asıl veriyi doğrudan silmez ancak kurtarma ve yeniden kurulum sürecini uzatabilir. BCO dosyası bulunamıyorsa mevcut VBK, VIB, VRB ve VBM dosyaları yine ayrı olarak incelenebilir.

VMware Sanal Makine Dosyalarının Kurtarılması

Veeam yedeklerinin içerisinde VMware sanal makinelerine ait disk, snapshot ve yapılandırma dosyaları bulunabilir. VBK dosyasının tamamı açılamasa bile bu dosyalara ait veri bloklarının bir bölümü sağlam kalabilir.

VMDK ve -flat.vmdk Dosyaları : VMware sistemlerinde küçük boyutlu VMDK dosyası sanal diskin tanımlayıcı bilgilerini içerebilir. Sanal makinenin gerçek disk verileri çoğu zaman -flat.vmdk dosyasında bulunur. VMDK descriptor dosyasının silinmesi veya bozulması sanal diskin açılmasını engelleyebilir. Ancak -flat.vmdk dosyası sağlam durumdaysa disk geometrisi ve diğer bilgiler değerlendirilerek sanal disk yapısı yeniden oluşturulabilir. Sanal makinenin yeniden çalıştırılması mümkün olmasa bile kullanıcı klasörleri, veri tabanları ve uygulama dosyaları ayrı olarak çıkarılabilir.

-delta.vmdk ve -sesparse.vmdk Dosyaları : VMware snapshot kullanıldığında değişiklikler -delta.vmdk veya -sesparse.vmdk dosyalarında tutulabilir. Ana VMDK dosyası eski durumu taşırken en güncel veriler snapshot disklerinde bulunabilir. Snapshot zincirindeki bir dosyanın silinmesi, descriptor bağlantılarının bozulması veya disk sıralamasının değişmesi sanal makinenin güncel durumunun açılmasını engelleyebilir. Ana disk, delta diskler ve snapshot descriptor dosyaları birlikte incelenmeden birleştirme işlemi yapılmamalıdır. Eksik snapshot dosyası repository veya datastore üzerinde aranabilir. Tam zincir elde edilemese bile ana disk ve sağlam delta dosyalarından belirli tarihlere ait veriler çıkarılabilir.

VMX Dosyaları : VMX dosyası sanal makinenin donanım ve yapılandırma bilgilerini taşır. VMX dosyasının silinmesi sanal makinenin vSphere veya ESXi üzerinde doğrudan açılmasını engelleyebilir. VMX dosyasının bulunmaması disk verilerinin tamamen kaybolduğu anlamına gelmez. VMDK diskleri sağlamsa yeni bir sanal makine yapılandırması oluşturularak diskler ayrıca incelenebilir.

VMSD ve VMSN Dosyaları : VMSD dosyası snapshot zinciri hakkında bilgiler içerebilir. VMSN dosyası ise snapshot alındığı sıradaki sanal makine durumuyla ilişkilidir. Bu dosyaların bozulması veya silinmesi snapshot yönetimini etkileyebilir. Ancak asıl kullanıcı verilerinin durumu, ana VMDK ve snapshot disklerinin sağlamlığına göre ayrıca değerlendirilmelidir.

NVRAM ve CTK Dosyaları : NVRAM dosyaları sanal makinenin BIOS veya UEFI ayarlarıyla ilgili bilgiler taşıyabilir. NVRAM dosyasının kaybolması çoğu durumda sanal disk içerisindeki kullanıcı verilerinin de kaybolduğu anlamına gelmez. CTK dosyaları değişen veri bloklarının takibi için kullanılabilir. Bu dosyaların silinmesi yedekleme ve değişiklik takibi işlemlerini etkileyebilir ancak VMDK içerisindeki kullanıcı verilerini doğrudan ortadan kaldırmaz.

Hyper-V Sanal Makine Dosyalarının Kurtarılması : Hyper-V sistemlerinde VHD, VHDX, AVHDX, VMCX, VMRS ve VMGS dosyaları zarar görebilir.

VHD ve VHDX Dosyaları : VHD ve VHDX dosyaları sanal makinenin disk verilerini içerir. Dosya kısmen bozulmuş olsa bile içerisindeki NTFS, ReFS veya Linux dosya sistemleri ayrıca incelenebilir. Sanal makinenin açılmaması, VHDX içerisindeki bütün verilerin kaybolduğu anlamına gelmez. Sağlam kalan bölümlerden dosya ve klasör seviyesinde kurtarma yapılabilir.

AVHDX Dosyaları : AVHDX dosyaları Hyper-V checkpoint zincirlerinde kullanılan değişken disk dosyalarıdır. Zincirdeki AVHDX dosyalarından birinin silinmesi veya bozulması güncel verilere erişilmesini engelleyebilir. Ana VHDX ve bütün AVHDX dosyalarının kopyaları alınmadan birleştirme yapılmamalıdır. Yanlış sırayla gerçekleştirilen birleştirme işlemi güncel verilerin kaybolmasına neden olabilir.

VMCX Dosyaları : VMCX dosyaları sanal makine yapılandırmasını içerir. Dosyanın silinmesi veya bozulması sanal makinenin Hyper-V yöneticisinde görünmemesine veya açılamamasına neden olabilir. VMCX dosyası bulunmasa bile VHDX dosyaları sağlamsa yeni bir sanal makine oluşturularak diskler ayrıca değerlendirilebilir.

VMRS ve VMGS Dosyaları : VMRS dosyaları sanal makinenin çalışma durumuyla, VMGS dosyaları ise misafir durum bilgileriyle ilişkili olabilir. Bu dosyaların zarar görmesi sanal makinenin kayıtlı durumdan başlatılmasını etkileyebilir. Ancak VMRS veya VMGS dosyasındaki bozulma VHDX içerisindeki kullanıcı verilerinin kesin olarak kaybolduğu anlamına gelmez.

SQL Server Dosyalarının Kurtarılması

Veeam yedeği içerisindeki fiziksel veya sanal sunucuda SQL Server kullanılıyorsa MDF, NDF, LDF, BAK ve TRN dosyaları önemli olabilir.

MDF Dosyaları : MDF dosyası SQL veri tabanının ana veri dosyasıdır. İçerisinde tablolar, indeksler ve diğer veri tabanı nesneleri bulunabilir. MDF dosyasının tamamı sağlam değilse okunabilen veri sayfaları incelenerek tabloların ve kayıtların bir bölümü kurtarılabilir.

NDF Dosyaları : NDF dosyaları veri tabanına bağlı ek veri dosyalarıdır. Büyük veri tabanlarında veriler birden fazla NDF dosyasına dağıtılmış olabilir. NDF dosyalarından birinin eksik veya bozuk olması veri tabanının açılmasını engelleyebilir. Bu nedenle MDF ile birlikte bütün NDF dosyaları korunmalıdır.

LDF Dosyaları : LDF dosyaları SQL Server işlem günlüklerini taşır. LDF dosyası tek başına bütün veri tabanını oluşturmaz ancak bazı olaylarda veri tutarlılığının ve işlem kayıtlarının değerlendirilmesine yardımcı olabilir.

BAK Dosyaları : BAK dosyaları SQL Server veri tabanı yedeklerini içerir. BAK dosyasındaki belirli blokların bozulması standart geri yükleme işleminin hata vermesine neden olabilir. Bozuk BAK dosyasının yanında kaynak diskteki eski kopyalar ve dosyanın sağlam kalan bölümleri de incelenebilir.

TRN Dosyaları : TRN dosyaları SQL Server işlem günlüğü yedeklerinde kullanılır. Tam ve farklı yedeklerle birlikte uygun sırada kullanıldığında veri tabanının belirli bir zamana kadar geri yüklenmesine yardımcı olabilir. TRN zincirindeki bir dosyanın silinmesi veya bozulması daha sonraki işlem günlüğü yedeklerinin kullanılmasını etkileyebilir. VBK veya sanal disk tamamen açılamasa bile MDF, NDF, LDF, BAK ve TRN dosyaları sağlam kalan disk alanlarından çıkarılarak ayrıca incelenebilir.

Exchange Server Verilerinin Kurtarılması

Exchange Server bulunan yedeklerde EDB veri tabanı, işlem günlükleri ve checkpoint dosyaları önemli olabilir. EDB dosyasının tek başına bulunması her zaman yeterli değildir. Veri tabanının tutarlı duruma getirilebilmesi için ilgili işlem günlükleri ve checkpoint bilgileri de gerekli olabilir. VBK veya VMDK dosyasındaki bozulma nedeniyle Exchange sunucusu açılmasa bile EDB ve günlük dosyaları ayrı olarak çıkarılabilir. Uygun durumda bir recovery database oluşturularak posta kutularındaki verilere ulaşılması denenebilir.

Active Directory Verilerinin Kurtarılması

Domain Controller bulunan sunucularda Ntds.dit, Active Directory işlem günlükleri, kayıt defteri ve SYSVOL klasörü önemli veriler arasındadır. Ntds.dit dosyasının tek başına kopyalanması her zaman çalışan bir Domain Controller elde etmek için yeterli değildir. Active Directory kurtarma işlemlerinde sistem durumu, SYSVOL ve diğer bileşenlerin birlikte değerlendirilmesi gerekir. Sanal sunucu çalıştırılamasa bile Ntds.dit, SYSVOL ve ilgili dosyalar sanal disk içerisinden çıkarılabilir. Ancak Domain Controller’ın yeniden devreye alınması yalnızca dosya kurtarmanın dışında Active Directory uyumlu bir geri yükleme süreci gerektirir.

PostgreSQL Verilerinin Kurtarılması

PostgreSQL sunucularında veri dizini, yapılandırma dosyaları ve pg_wal altında bulunan WAL kayıtları önemlidir. WAL kayıtları veri tabanı değişikliklerinin izlenmesi ve uygun bir temel yedekle birlikte belirli bir zamana dönüş işlemlerinde kullanılabilir. Yedek içerisindeki PostgreSQL sunucusu açılamıyorsa veri dizini ve WAL dosyaları sanal diskten çıkarılarak ayrıca değerlendirilebilir.

Oracle Veri Tabanı Dosyalarının Kurtarılması

Oracle sistemlerinde datafile dosyaları, control file, online redo log, archived redo log ve yapılandırma dosyaları kurtarma açısından önemlidir. Control file veri tabanındaki datafile ve redo log yapıları hakkında bilgiler taşır. Online ve archived redo log dosyaları ise veri tabanı üzerinde yapılan değişikliklerin kurtarma sırasında uygulanmasında kullanılabilir. VBK veya sanal disk tamamen açılamasa bile Oracle veri dosyaları ve log alanları sağlam kalan bölümlerden çıkarılarak ayrıca incelenebilir.

VBLOB ve Diğer Veeam Dosyalarının Zarar Görmesi

NAS, dosya paylaşımı ve yapılandırılmamış veri yedeklerinde VBLOB dosyaları görülebilir. Bu dosyaların silinmesi veya şifrelenmesi yedeklenen veri bloklarının kullanılamamasına neden olabilir. SQL ve Oracle log yedeklemelerinde VLB, VSM, VLM veya VOM gibi dosyalarla karşılaşılabilir. Bazı Veeam eklentilerinde VAB ve VASM dosyaları da bulunabilir. Saldırganlar bu dosyaların işlevini bilmeden bütün repository klasörünü şifreleyebilir. Sonuç olarak yalnızca VBK değil, ona bağlı uygulama ve metadata dosyaları da etkilenir. Kurtarma sırasında bütün dosyaların aynı klasör yapısı ve tarih bilgileriyle birlikte korunması gerekir.

Veeam Şifrelemesi ile Fidye Yazılımı Şifrelemesi Arasındaki Fark

Veeam tarafından parola kullanılarak şifrelenen bir yedek ile sonradan fidye yazılımı tarafından şifrelenen bir VBK dosyası aynı durum değildir. Veeam şifrelemesinde yedek oluşturulduğu sırada belirlenen parola ve Veeam’in kendi şifreleme yapısıyla korunur. Parolanın unutulması halinde dosya yapısı sağlam olabilir ancak içeriğe erişim için gerekli parola bulunmaz. Fidye yazılımı müdahalesinde ise daha önce oluşturulmuş VBK veya diğer yedek dosyalarının belirli bölümleri sonradan değiştirilir. Dosyanın orijinal veri blokları şifrelenebilir, üzerine yeni veri yazılabilir veya dosya silinerek şifreli bir kopyası bırakılabilir. Bu iki durum farklı yöntemlerle incelenir. Öncelikle dosyanın Veeam şifrelemesiyle mi oluşturulduğu yoksa sonradan harici bir müdahaleye mi uğradığı belirlenmelidir.

Dosyalar Şifrelenip Sonra Silinir mi?

Bazı fidye yazılımları orijinal dosyayı doğrudan şifreler. Bu durumda dosyanın aynı adı veya değiştirilmiş bir uzantısı klasörde kalabilir. Bazı zararlı yazılımlar ise dosyanın şifreli bir kopyasını oluşturur ve ardından orijinal dosyayı siler. Orijinal dosyaya ait veri bloklarının üzerine yeni veri yazılmamışsa kaynak disk üzerinde eski dosyanın tamamı veya parçaları bulunabilir. Bazı saldırılarda yedek dosyaları doğrudan silinir ve yerine fidye notu bırakılır. Bazı olaylarda ise dosyalar silinmeden önce belirli bölümleri sıfırlanır veya rastgele verilerle doldurulur. Bu nedenle yalnızca klasörde görünen dosyalar değil, silinen dosya kayıtları ve kullanılmayan disk alanları da incelenmelidir.

Saldırganlar Logları ve İzleri Siler mi?

Saldırganlar yaptıkları işlemleri gizlemek amacıyla Windows olay günlüklerini, Veeam loglarını ve güvenlik kayıtlarını silebilir. Ayrıca çalıştırdıkları komut dosyalarını ve uzaktan erişim araçlarını kaldırabilirler. Ancak logların silinmiş olması bütün izlerin tamamen yok olduğu anlamına gelmez. Dosya sistemi kayıtları, Prefetch verileri, zamanlanmış görevler, yeni oluşturulmuş kullanıcı hesapları, uzak bağlantı kayıtları ve ağ cihazı logları olay hakkında bilgi sağlayabilir. Veri kurtarma çalışması ile olay incelemesi birbirinden farklı olsa da logların korunması saldırının nasıl gerçekleştiğinin anlaşılması açısından önemlidir.

Object Storage ve Değiştirilemez Yedeklerin Kontrol Edilmesi

Ana Veeam sunucusu ve yerel repository zarar görmüş olsa bile farklı depolama alanlarında sağlam kopyalar bulunabilir. S3 uyumlu object storage, Scale-out Backup Repository, capacity tier, archive tier veya başka lokasyondaki yedek kopyaları kontrol edilmelidir. Değiştirilemezlik özelliği etkin olan yedekler belirlenen süre boyunca silinmeye veya değiştirilmeye karşı korunmuş olabilir. Saldırgan ana sunucuda yönetici yetkisi elde etmiş olsa bile immutable repository üzerindeki bazı geri yükleme noktaları sağlam kalabilir. Bu nedenle veri kurtarma işlemine başlamadan önce bütün repository, object storage ve yedek kopya alanları kontrol edilmelidir.

Veeam Health Check ve Backup Validator Hataları

Veeam Health Check veya Backup Validator işlemleri sırasında hata alınması, yedek içerisindeki bütün verilerin kesin olarak kaybolduğu anlamına gelmez. Hata belirli bir geri yükleme noktasını, sanal makineyi veya disk içerisindeki bazı veri bloklarını etkiliyor olabilir. Son geri yükleme noktasını oluşturan veri blokları yalnızca son VIB dosyasında bulunmayabilir. İlgili veriler VBK ve önceki artımlı dosyalar dahil olmak üzere zincirdeki birden fazla dosyaya dağılmış olabilir. İnceleme sırasında bozulmanın tam yedek dosyasında mı, artımlı dosyada mı yoksa belirli bir sanal diske ait bloklarda mı bulunduğu belirlenmeye çalışılır.

Son Sağlam Geri Yükleme Noktasının Belirlenmesi

En güncel geri yükleme noktasının bozuk olması, önceki bütün yedeklerin de kullanılamaz olduğu anlamına gelmez. Yedek zincirindeki dosyalar ayrı ayrı kontrol edilerek bozulmadan önceki son sağlam geri yükleme noktası belirlenebilir. Örneğin son iki VIB dosyası zarar görmüş olsa bile daha önceki bir tarihe ait geri yükleme noktası kullanılabilir durumda olabilir. Her olayda VBK dosyasının tamamen onarılması gerekli veya mümkün olmayabilir. Öncelikli ihtiyaç duyulan verilerin sağlam alanlardan çıkarılması daha güvenli bir yöntem olabilir.

• Yedek zincirinin tamamı yeniden kullanılabilir hale getirilebilir.
• Bozulmadan önceki son sağlam geri yükleme noktasına ulaşılabilir.
• Yalnızca belirli bir sanal makine çıkarılabilir.
• VMDK, VHD veya VHDX sanal diski kurtarılabilir.
• SQL, Exchange, PostgreSQL veya Oracle veri tabanı dosyaları çıkarılabilir.
• Dosya ve klasör seviyesinde kurtarma yapılabilir.

Bozuk VBK Dosyasının Tamamen Onarılması Her Zaman Gerekli Değildir

Her olayda amaç VBK dosyasını yeniden Veeam üzerinden açılabilir hale getirmek değildir. Dosyanın hasar durumuna göre ihtiyaç duyulan verilerin doğrudan çıkarılması daha uygulanabilir olabilir. Sanal makinenin tekrar çalıştırılması mümkün olmasa bile iş açısından önemli veri tabanları ve dosyalar ayrı olarak kurtarılabilir. VBK dosyasının tamamı kurtarılamasa bile şu verilerin bir bölümü sağlam kalabilir

• VMware VMDK sanal diskleri
• Hyper-V VHD veya VHDX sanal diskleri
• SQL MDF, NDF, LDF, BAK ve TRN dosyaları
• Exchange EDB veri tabanları
• Active Directory Ntds.dit ve SYSVOL verileri
• PostgreSQL veri dizini ve WAL dosyaları
• Oracle datafile ve redo log dosyaları
• Muhasebe ve ERP programı verileri
• Paylaşımlı sunucu klasörleri
• Kullanıcı belgeleri ve proje dosyaları

Veeam Yedek Dosyası Kurtarma Süreci

İlk aşamada mevcut VBK, VIB, VRB, VBM ve BCO dosyaları kontrol edilir. Dosyaların tarihleri, boyutları, fiziksel durumları ve birbirleriyle bağlantıları değerlendirilir. Yedeklerin bulunduğu disk veya sunucuda fiziksel arıza varsa sektör bazlı imaj alınır. RAID veya NAS yapısı bulunuyorsa diskler sanal olarak birleştirilir. Dosya sistemi üzerinde mevcut ve silinen Veeam yedek dosyaları araştırılır. VBK dosyasının başlangıç alanları, metadata bölümleri ve veri blokları kontrol edilir. Dosya standart yöntemlerle açılamıyorsa içerisindeki VMware veya Hyper-V sanal disk yapıları araştırılır. VMDK, VHD ve VHDX bölümleri ayrıştırılarak içerisindeki dosya sistemleri incelenir. SQL, Exchange, Active Directory, PostgreSQL ve Oracle verileri ihtiyaç durumuna göre ayrı olarak çıkarılır. Kurtarılan dosyalar kaynak diskten farklı ve sağlıklı bir depolama birimine aktarılır. Orijinal disk ve yedek dosyaları üzerinde doğrudan değişiklik yapılmaz. İnceleme ve kurtarma işlemleri mümkün olduğunca alınan kopyalar üzerinden gerçekleştirilir.

VBK Dosyası Bozulduğunda Yapılmaması Gerekenler

Bozuk veya silinen yedeklerin bulunduğu repository üzerinde yeni yedek alınmamalıdır. Yeni oluşturulan VBK ve VIB dosyaları silinen eski yedeklere ait veri bloklarının üzerine yazabilir. Kaynak disk üzerinde CHKDSK veya dosya sistemi onarımı çalıştırılmamalıdır. RAID sistemi kontrolcü üzerinden yeniden oluşturulmamalı ve disk sıralaması değiştirilmemelidir. Bozuk VBK dosyası farklı programlarla tekrar tekrar değiştirilmemelidir. Herhangi bir onarım işleminden önce dosyanın birebir kopyası alınmalıdır. VMDK snapshot veya Hyper-V checkpoint dosyaları yedekleri alınmadan birleştirilmemelidir. Yanlış birleştirme işlemleri güncel verilerin kaybolmasına neden olabilir. Ransomware saldırısından etkilenen repository üzerinde yeni dosya oluşturulmamalı ve yeni yedekleme görevi başlatılmamalıdır. Saldırının devam etme ihtimaline karşı etkilenen sistemlerin ağ bağlantıları kontrollü biçimde kesilmeli ancak log ve deliller korunmalıdır. Fiziksel arızalı diskler standart yöntemlerle uzun süre çalıştırılmamalıdır. Diskte ses, bağlantı kopması veya aşırı yavaşlama bulunuyorsa sistem kapatılmalıdır.

Ransomware Sonrası Kurtarma Başarısı Neye Bağlıdır?

Kurtarma sonucu saldırının kullandığı yönteme göre değişir. Dosyanın tamamının mı yoksa belirli bölümlerinin mi şifrelendiği önemlidir. Silinen dosyaların üzerine yeni veri yazılması kurtarma ihtimalini azaltır. Repository üzerinde yeni yedek alınması eski VBK dosyalarının bulunduğu alanları değiştirebilir. Kaynak disklerin fiziksel durumu, RAID yapısının sağlamlığı ve yedek zincirindeki diğer dosyaların mevcut olması da sonucu etkiler. Object storage veya immutable repository üzerinde sağlam yedek bulunması geri dönüş sürecini kolaylaştırabilir. Dosya incelenmeden kesin kurtarma oranı verilmesi doğru değildir. Ön inceleme sonucunda şifrelenmiş, silinmiş ve sağlam kalan alanlar belirlenebilir.

Profesyonel Veeam ve VBK Dosyası Kurtarma Hizmeti

Acil Veri Kurtarma olarak sunucu çökmesi, disk arızası, RAID bozulması, eksik yedek zinciri, yanlışlıkla silme ve yetkisiz müdahale sonucunda kullanılamaz hale gelen Veeam yedek dosyaları üzerinde teknik inceleme gerçekleştiriyoruz. İnceleme yalnızca VBK dosyasını açmayı denemekle sınırlı değildir. Kaynak diskler, RAID yapısı, NAS cihazı, dosya sistemi, yedek zinciri, sanal makine diskleri ve veri tabanı dosyaları birlikte değerlendirilir. Veeam VBK Dosyası Kurtarma çalışma kapsamında Veeam tarafından açılamayan VBK dosyaları, eksik VIB ve VRB dosyaları, silinen VBM ve BCO dosyaları, zarar gören VMDK ve VHDX sanal diskleri, bozuk snapshot zincirleri ve veri tabanı dosyaları incelenebilir. Ransomware saldırısı sonucunda şifrelenen, silinen veya içeriği değiştirilen yedekler için kaynak repository üzerindeki eski kopyalar, silinen dosya kayıtları, sağlam veri blokları, object storage alanları ve önceki yedek zincirleri araştırılabilir.

İnceleme kapsamında VBK, VIB, VRB, VBM, BCO, VMDK, -flat.vmdk,-delta.vmdk, -sesparse.vmdk, VHD, VHDX, AVHDX, MDF, NDF, LDF, BAK, TRN, EDB ve diğer önemli sunucu dosyaları değerlendirilebilir. Dosyanın tamamının çalışır hale getirilemediği durumlarda sağlam kalan sanal diskler, veri tabanları, kullanıcı klasörleri ve kurumsal dosyalar ayrı olarak kurtarılabilir. Kurtarma sonucu; dosyanın ne kadarının zarar gördüğüne, kaynak disklerin durumuna, silinen alanların üzerine veri yazılıp yazılmadığına ve aynı yedek zincirindeki diğer dosyaların mevcut olup olmadığına göre değişir.