Türkiye'de Veri Kurtarma Anatomi: 20 Yıllık Saha Deneyiminin Çıkardığı 12 Ders
DSET'in 2003'ten bu yana 20.000+ TB kurtarılan veri ve 100+ kurumsal müşteri deneyiminden çıkardığı 12 saha dersi. HDD ilk power-on, SSD TRIM sessiz katili, RAID 5 URE matematiği, coğrafya × arıza profili, yedekleme paradoksu, fidye yazılım daimi risk, Apple Silicon Secure Enclave, telefon factory reset, bulut yedek + KVKK, donor parça, hatalar zinciri, veri kurtarma + adli bilişim entegre disiplin.
Türkiye'de Veri Kurtarma Anatomi: 20 Yıllık Saha Deneyiminin Çıkardığı 12 Ders (2003-2026)
Bir laboratuvarın 20 yılı, başka bir laboratuvarın 20 yılına benzemez. 2003'ten bu yana DSET olarak 20.000 TB'ın üzerinde veriyi geri getirdik, 100'ü aşkın kurumsal projeye dokunduk, 1.350'den fazla teknisyen akademimizden mezun oldu ve hâlâ %99.4 başarı oranıyla çalışıyoruz. Bu rakamlar bir reklam değil, bir filtre. Yirmi yılda neyi öğrendiğimizi anlatırken arkasında bu kadar saha olmasının nedeni şu: kurtarma işi laboratuvarda değil, müşterinin telefonu çaldığı anda başlar.
Bu yazıda romantize edilmiş başarı hikâyeleri yok. Kazandığımız kadar kaybettiğimiz vakalar da var, ve kaybettiklerimizden öğrendiklerimiz çoğu zaman daha öğretici. Türkiye coğrafyasının, kullanıcı alışkanlıklarının, tedarik zincirinin ve mevzuatın kesişiminde ortaya çıkan 12 dersi bu yazıda damıtmaya çalıştık. Her ders bir kural değil, bir desen. Saha bize bunu sıkça gösterdi.
Detaylı bir başlangıç noktası arıyorsanız veri kurtarma rehberini okumanızı öneririz, bu makale onun üzerine inşa ediliyor.
Ders 1: HDD'de En Ölümcül An Arızanın Kendisi Değil, Onu İzleyen İlk Power-On'dur
Mekanik diskte kafa bir mikronun altındaki yükseklikte uçar. Yatak (spindle bearing) sıyrık alır, kafa platere değer, ya da firmware bir alanda kilitlenirse disk hâlâ "açılıyor gibi" görünür. Burada gözlemlediğimiz en yıkıcı desen şudur: kullanıcı bir tık sesi, bir gecikme, bir donma fark eder. Sonra ne yapar? Tekrar dener. İki dener. Beş dener.
Backblaze'in çeyrek dönem yayımladığı sürücü istatistikleri (Drive Stats) sektör genelinde HDD arıza eğilimlerini açık şekilde belgeliyor: bir sürücü SMART parametrelerinde anlamlı bir bozulma gösterdiğinde, kalan ömür beklenenden çok daha agresif düşebilir. Sahada gördüğümüz şu: ilk anomaliden sonraki üç power-on, çoğu zaman kurtarılabilir bir vakayı kurtarılamaz hâle getirir. Çünkü kafa platere her temas ettiğinde küçük bir manyetik bölgeyi fiziksel olarak siler. Bu silinme yazılımla geri gelmez.
Müşteriden gelen en sık cümle şu: "Bir kez daha denedim, bu sefer hiç açılmadı." O bir kez, çoğu zaman dosya tablosunun bulunduğu sektörlerin üzerinden geçer. Pratik kural çok basittir, anormal ses ya da davranış varsa cihaz fişten çekilir, bir daha takılmaz, laboratuvara gelir. ISO/IEC 27037 standardının dijital delil edinme prensipleri tam olarak bunu söyler: kaynağı değiştirmemek için minimum etkileşim. Veri kurtarmada da aynı disiplin geçerlidir.
Sahada gözlemlediğimiz bir başka önemli ayrıntı, kullanıcının ses ile arıza ilişkisini doğru kuramamasıdır. Mekanik diskte üç farklı ses kategorisi vardır, ve her biri farklı bir aciliyet düzeyi taşır. Düzenli aralıklı "tık tık tık" sesi tipik olarak kafa parking pozisyonuna dönüp tekrar başlatma denemesidir, ve kafanın preamp ya da servo kalibrasyon bilgisini okuyamadığı anlamına gelir. Yüksek frekanslı "zırlama" sesi spindle motor ya da yatakta sürtünme işaretidir, ve disk dakikalar içinde tamamen durabilir. Yumuşak "kazıma" sesi ise platere temas eden bir kafa ihtimalini akla getirir, ve bu en acil senaryodur, çünkü her saniye fiziksel olarak silinen veri demektir.
Bir başka tehlikeli desen, harici USB diski yeniden takma alışkanlığıdır. Müşteri "bağlantı sorunu olabilir" diye düşünür, kabloyu çıkarıp takar, başka USB porta takar, başka bilgisayara takar. Bu denemelerin her biri spindle'ı tekrar tekrar başlatır, yatağı zorlar, ve eğer içeride bir kafa arızası varsa zarar katlanır. Profesyonel laboratuvar ilk adım olarak diski sökmeden önce PCB üzerinde ön analiz yapar, motor sürücü voltajını ölçer, preamp davranışını gözlemler, ve ancak ondan sonra power vermeyi düşünür. Bu basit fark, çoğu zaman vakayı kurtarılabilir ile kurtarılamaz arasındaki sınırda tutar.
Ders 2: SSD ve NVMe'de TRIM, Sessiz Bir Katildir
HDD'de silinen dosya genellikle metadata seviyesinde kaybolur, fiziksel veri NAND'ın değil platerin üzerindedir ve hâlâ oradadır. SSD'de ise bu denklem tersine döner. TRIM komutu işletim sistemi tarafından bir bloğun "artık kullanılmıyor" olduğunu controller'a bildirir. Controller bunu öğrendiği anda, garbage collection o bloğu fiziksel olarak siler, çünkü NAND'a yazmadan önce silmek zorundadır.
JEDEC'in JESD218 ve JESD219 standartları SSD endurance ve veri saklama davranışlarını tanımlar, ve TRIM'in nasıl çalıştığını şeffaf biçimde dokümante eder. Pratik sonuç: TRIM destekli bir sistemde bir dosyayı sildikten sonra geçen her saniye, kurtarma penceresini fiziksel olarak daraltır. Birkaç dakika içinde controller'ın o blokları temizlemesi olağan bir durumdur.
Sahada gördüğümüz desen, SSD vakalarının HDD vakalarına göre kurtarma penceresinin çok daha kısa olduğudur. Bu yüzden Samsung SSD kurtarma süreçlerinde ilk talimatımız sabit kalır: cihazı kapat, üzerine yazma yapma, bağlanma. PCIe arayüzünde controller'a güç verildiği anda firmware kendi housekeeping rutinlerini çalıştırabilir. NVMe SSD bir USB adaptöre takılıp "bakayım açılıyor mu" denmesi, çoğu zaman kurtarılabilecek son alanı da imha eder.
StorageReview ve Tom's Hardware gibi yayınların yıllık SSD dayanıklılık testleri, modern TLC ve QLC NAND'ın endurance açısından yıllar içinde nasıl kaydığını da gösteriyor. Düşük yazma toleranslı QLC sürücüler, beklenmedik bir power-loss olayında veri saklama açısından daha kırılgan. Bu fiziksel gerçek, kurtarma stratejimizi de şekillendiriyor.
Modern NVMe SSD'lerde bir başka sessiz katil controller firmware bug'larıdır. Üretici firmware'i, bir wear leveling rutininde, bir SLC cache flush sürecinde, ya da bir thermal throttle senaryosunda, beklenmedik bir power-loss ile karşılaştığında metadata tablosunu tutarsız bırakabilir. Sonuç, BIOS'ta hâlâ görünen ancak kapasitesi sıfır olarak okunan bir disktir. Bu durumda kullanıcı diski normal kanaldan kurtarmaya çalışmamalı, çünkü controller'a verilen her komut tutarsız metadata üzerinde yeni bir yazma denemesi yapabilir, ve geri kalan tutarlı blokları da bozabilir.
Saha gözlemimizde, özellikle ucuz markaların DRAM-less SSD modellerinde firmware kaynaklı arıza oranı diğer kategorilerden belirgin biçimde yüksek. DRAM-less mimari, mapping tablosunun host belleğine (HMB) ya da NAND'ın kendisine yansıtılmasını gerektirir, ve bu da power-loss anında daha geniş bir saldırı yüzeyi yaratır. Kritik veri tutulan iş istasyonlarında DRAM cache'li SSD tercih etmek, kurtarma penceresinin pratik genişliğini doğrudan etkiler.
Ders 3: RAID 5 Büyük Disklerde Artık Matematiksel Olarak Yetersiz
20 yıl önce 250 GB diskten kurulan RAID 5 dizileri güvenli bir tercihti. Bugün 16 TB, 20 TB, 22 TB SATA diskten kurulan RAID 5 dizileri, bir disk düştüğünde rebuild sırasında ikinci diskin Unrecoverable Read Error (URE) verme olasılığına karşı matematiksel olarak savunmasızdır.
Enterprise SATA diskler için üreticiler tipik olarak 10^14 ile 10^15 arası bir URE specifikasyonu yayımlar. Hesap basit: dizide kaç bit okumak zorundasınız, ve bu bit sayısı URE eşiğine yaklaştıkça bir hata yakalama olasılığı pratik olarak kaçınılmaz hâle gelir. Yani RAID 5 rebuild'i, büyük disk dizilerinde "muhtemelen başarısız" senaryosuna yaklaşır.
Backblaze'in petabaytlarca veri üzerinden yayımladığı drive stats verisi de bunu pekiştiriyor: bir diskin arızalandığı süreçte sıkça aynı parti, aynı yaş, aynı termal yük altındaki kardeş diskler de stres altındadır. Bir disk düştüyse, ikinci diskin de yakın zamanda düşme olasılığı saha gözlemlerimizde belirgindir.
Pratik tavsiye: dört diskten büyük dizilerde RAID 6 ya da double parity şart, kritik kurumsal dizilerde ek olarak gerçek bir yedek katmanı. RAID 5 veri kurtarma süreçlerinde en sık duyduğumuz cümle "rebuild başlattık, ikinci disk de düştü" oluyor. Bu cümle bir kaza değil, beklenen bir istatistiktir.
Bir başka kritik nokta, controller'ın kendi davranışı. Hardware RAID controller'larda firmware'in dizi yapılandırma metadata'sı, batarya yedekli yazma cache'i ve hot-spare yönetim mantığı vardır. Bu controller arızalandığında, aynı modelin başka bir biriminin de aynı firmware revizyonunda olması, ve dizi metadata'sını okuyabilmesi gerekir. Sahada gördüğümüz desen, eski model RAID controller'ların yedek tedarikinde ciddi gecikmeler yaşanmasıdır. Bu yüzden kurumsal müşterilerimize, kritik dizilerde controller'ın bir yedeğini stokta tutmayı öneririz. Soft RAID çözümlerinin (mdadm, ZFS, Btrfs, Storage Spaces) bu açıdan daha esnek olduğunu belirtmek gerekir, çünkü dizi metadata'sı standart bir formatta diske yazılır ve farklı bir host üzerinde de tekrar inşa edilebilir.
Ders 4: Türkiye Coğrafyası, Arıza Profilini Doğrudan Belirler
Aynı marka ve modelin İzmir'deki bir mağazadan, Erzurum'daki bir ofisten ve Adapazarı'ndaki bir fabrikadan gelen örnekleri arasında farklı arıza desenleri görüyoruz. Bu bir tesadüf değil, fiziktir.
Sahil bölgelerinden, özellikle Antalya, Mersin, İzmir, Trabzon kıyısından gelen mekanik disklerde PCB üzerindeki konnektör bacaklarında ve solder pad'lerde tuzlu hava korozyonunun bıraktığı izler sıkça karşılaştığımız bir desen. Bu sadece HDD'yi değil, NAS cihazlarının arka panellerini, fan rulmanlarını ve PSU kondansatörlerini de etkiliyor. Synology NAS veri kurtarma vakalarında sahil bölgelerinden gelen cihazlarda backplane kontak sorunlarının diğer bölgelere oranla belirgin biçimde daha sık ortaya çıktığını gözlemliyoruz.
İç Anadolu'da farklı bir tablo var. Yaz aylarındaki yüksek gündüz sıcaklığı ve düşük nem kombinasyonu, klimasız ofislerde çalışan masaüstü disklerde termal stres bırakıyor. SSD'lerde NAND retention'ı yüksek sıcaklıkta hızlanan bir bozulma eğrisi gösterir, bu da JEDEC standartlarında açıkça belgelenir.
Deprem bölgelerinde ise mekanik darbe vakaları başlı başına bir kategori. 2023 sonrasında Hatay, Kahramanmaraş ve çevre illerden gelen vakalarda darbe izi taşıyan disklerde head crash sıklığı diğer bölgelerden gelenlere kıyasla farklı bir desen çiziyor. Bu coğrafi farkındalık, Ankara veri kurtarma laboratuvarına gelen vakaları daha geldikleri ilden itibaren farklı bir önceliklendirmeye sokmamıza yol açıyor.
Marmara bölgesinin sanayi yoğun ilçelerinden gelen vakalarda da farklı bir parmak izi var. Yüksek nem, taşıma sırasında titreşim ve organize sanayi sitelerindeki elektrik kalitesi sorunları (sık dalgalanma, gerilim düşmesi, harmonik bozulma) PSU bileşenlerini ve disk PCB'lerini farklı şekilde stres altına sokuyor. Sık karşılaştığımız bir örnek, koruyucu olmadan çalışan masaüstü iş istasyonlarında transient voltaj epizotlarının ardından tek seferde tüm SSD'nin BIOS'tan kaybolması. UPS olmayan ortamda kritik veri tutmak, sahip olduğunuz korunmanın çok altında bir korunma seviyesi anlamına geliyor.
Bu coğrafi profil, kargo lojistiğini de etkiliyor. Sahil illerinden gelen nemli cihazlarda kargonun mühürlü plastik içinde uzun süre kalması durumu daha da kötüleştirebiliyor. Müşterilere ısrarla söylediğimiz, cihazı kuru bir bezle silmek, üzerine herhangi bir ısı kaynağı uygulamamak, ve mümkün olan en hızlı şekilde laboratuvara ulaştırmak. Sebze kurutucu, saç kurutma makinesi, ya da güneşe bırakmak gibi internet yorumlarında dolaşan tavsiyeler, vakayı kurtarılamaz hâle getiren ciddi tehlikelerdir.
Ders 5: Yedekleme Paradoksu, "Yedek Var Sanıyorum" Cümlesi
Yirmi yıllık saha çalışmasının en kalıcı dersi bu olabilir. Bir kurum yedekleme yapmadığını biliyorsa zaten korunma psikolojisi devrededir, riski farkındadır. Asıl tehlikeli olan, "yedek var sanıyorum" diyen kurumdur.
Sıkça karşılaştığımız desen şu: gece yedeği çalışıyor görünüyor, yedekleme yazılımı yeşil tikle başarı bildiriyor, ancak yedeğin restore edilebilir olup olmadığı hiç test edilmiyor. Bir gün ihtiyaç olduğunda bilinmeyen sürpriz şu olabilir, yedek dosyası bozuk, hedef cihazın kapasitesi yetersiz, şifreleme anahtarı kayıp, ya da yedeğe atılan dataset'in son altı ayı boş.
NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response) yedek doğrulama disiplinini açıkça vurgular. Pratikte uyguladığımız ve müşterilerimize önerdiğimiz minimum disiplin, üç soru ile özetlenebilir: yedek nereye gidiyor, yedeğin son restore testi ne zaman yapıldı, ve yedek aynı binadaki başka bir cihazda mı duruyor. Üçüne de net cevap veremeyen kurum, henüz gerçekten yedekleme yapmıyor demektir.
3-2-1 kuralı ezbere bilinen bir formül olsa da uygulanışı çok zayıf. Üç kopya, iki farklı medya, bir kopya farklı lokasyonda. Sahada bu kuralın eksiksiz uygulandığını gördüğümüz kurum oranı, dile getirmek istemediğimiz kadar düşük.
Modern bir genişletme olarak 3-2-1-1-0 kuralı da yaygınlaşıyor. Sonundaki 1 immutable (değiştirilemez) yedeği, 0 ise restore testinde hatasız sonuç almayı temsil ediyor. Immutable yedek özellikle fidye yazılım çağında kritik, çünkü saldırgan yönetici parolasını ele geçirse bile silinemeyen, üzerine yazılamayan yedek katmanı kurumun son güvencesidir. Bulut tarafında object lock destekli S3 storage, ya da on-prem tarafında WORM destekli NAS bu işlevi karşılayabilir.
Bir başka uygulamada gördüğümüz hata, yedeği üreten sistem ile yedeği saklayan sistemin aynı kimlik bilgilerini paylaşmasıdır. Domain admin parolası ele geçirilen bir kurumda, yedek sunucusu da aynı domain'e dahil ise saldırgan yedeği de imha eder. Yedek sunucusunun ayrı bir kimlik dünyasında, ayrı parola yönetimi ve mümkünse ayrı bir ağ segmentinde olması gerekiyor. Bu mimari ayrımı yapmamış kurumların fidye sonrası restore başarı oranı, mimari ayrım yapmış kurumlara göre belirgin biçimde düşük olarak gözlemleniyor.
Ders 6: Fidye Yazılım Belli Bir Yüzde Değil, Sürekli Risk Altındaki Bir Düzlemdir
"Bize fidye gelmez" diyen kurum, henüz gelmemiş olan kurumdur. Bu cümle agresif gelebilir, ancak 2020 sonrasında saha gözlemimiz net: sektör fark etmez, ölçek fark etmez, lokasyon fark etmez. Sahanın 25 kişilik muhasebe ofisi de hedef alındı, 800 endpoint'li üretim tesisi de.
Fidye yazılım veri kurtarma süreçlerinde gözlemlediğimiz desen şudur: saldırı vektörü çoğu zaman RDP, çoğu zaman güncellenmemiş VPN, çoğu zaman zayıf parola. Yani egzotik bir zero-day değil, hijyen meselesi. Saldırgan içeri girdikten sonra fark edilene kadar geçen süre, kurumun çıplak gözle göremediği en büyük zafiyeti.
Bu noktada veri kurtarma ile incident response (olay müdahale) birleşir. ISO/IEC 27037 zincirleme delil disiplini ve NIST SP 800-86 olay müdahale rehberi, fidye yazılım vakalarında veri kurtarma sürecinin aynı zamanda bir adli süreç olarak yürütülmesi gerektiğini açıkça yazar. Disk imajı önce, çalışma kopyası sonra. Ham veri elle tutulmaz, sadece kopyası incelenir.
Fidye ödemenin işe yaramadığı vakalar da görüyoruz. Ödeme yapıldı, decryptor geldi, ama yarısı çalışmadı, yarısı bozuk dosya verdi, ya da decryptor bir backdoor da bıraktı. Bu, ödemenin ne kadar kötü bir strateji olduğunu somut biçimde gösteren bir desen.
Bir başka acı gerçek, çift haraç (double extortion) modelidir. Saldırgan sadece veriyi şifrelemekle kalmaz, önce çalar, sonra şifreler. Yani ödeme yapsanız bile, verinizin yayımlanmaması garantisini almazsınız. Bu noktada KVKK boyutu da devreye girer, çünkü kişisel veri içeren bir veri seti yurt dışı bir leak sitesinde yayımlandığında veri sorumlusu kurumun KVKK Kurul'una bildirim yükümlülüğü vardır. Sahada bu çift baskı altında doğru karar verebilmek için saldırı öncesinde hazırlık şart, saldırı anında değil.
Kurumsal fidye yazılım vakalarında uyguladığımız standart protokol şudur, önce ağ izolasyonu, ardından etkilenen sunucuların disk imajının alınması, sonra imaj üzerinden çalışmaya başlanması, ham veriye dokunmadan. Bu disiplin hem kurtarma şansını korur hem de olası bir hukuki sürecin delil değerini bozmaz. Aceleyle yeniden başlatma, format atma, ya da antivirüs ile tarama denemeleri, vakayı hem teknik hem hukuki açıdan ciddi şekilde sakatlar.
Ders 7: Apple Silicon ve Secure Enclave, Veri Kurtarmanın Yeni Coğrafyası
2020 sonrası Apple Silicon Mac'lerde NAND SoC'ye lehimli ve şifreleme T2 ya da Apple Silicon Secure Enclave üzerinden yönetiliyor. Bu mimari, son kullanıcının veri güvenliği açısından devrim niteliğinde, ancak veri kurtarma açısından yeni bir gerçeklik yarattı.
Önceki nesil MacBook'larda SSD modüler değildi belki, ama şifreleme anahtarı çıkarılabiliyor, alternatif yöntemler işliyordu. Apple Silicon ile birlikte mantıksal silme + Secure Enclave restore = sıfıra geri dönüş anlamına geliyor. Anahtar yok ise NAND'da fiziksel olarak duran veri matematiksel olarak rastgele bit kümesi.
Bunun pratik karşılığı, M1, M2, M3 Mac'lerde "Erase All Content and Settings" komutu bir kez verildiğinde fiziksel kurtarma yolunun kapanmasıdır. Anakart üzerindeki SoC'nin lojik arıza vakalarında bile şifreleme anahtarına ulaşılamadığı senaryolar var. Bu, kullanıcıya iletmemiz gereken çok net bir gerçek. Mac kullanıcılarına ısrarla söylediğimiz tek cümle: iCloud yedeği veya Time Machine, ikisi de olmadan kritik veri Mac diskinde tutulmaz.
Apple Silicon mimarisinde sıkça karşılaştığımız bir başka vaka kategorisi anakart sıvı teması. Kahve, su, ya da herhangi bir sıvı SoC çevresine ulaştığında, kısa devre öncesinde aktif olan veri yolları üzerinden ani gerilim sıçramaları olur, ve Secure Enclave anahtarı tutan bileşen geri dönüşü olmayan bir kalıba girebilir. Bu yüzden sıvı temasına uğramış bir MacBook'ta yapılması gereken tek doğru hareket cihazı kapatıp pili çıkarmadan (modern MacBook'larda kasayı açıp pil konnektörünü çıkarmak gerekir) servise götürmektir. "Pirinçte beklet" gibi internet tavsiyeleri Apple Silicon'da hiçbir koruma sağlamaz, çünkü hasar elektriksel değil, kimyasal olarak da ilerler ve zaman içinde derinleşir.
Ders 8: Telefon Factory Reset, Veri Ölümünün Modern Adı
Aynı şifreleme gerçekliği akıllı telefonlarda da hâkim. iPhone veri kurtarma süreçlerinde gözlemlediğimiz şu: iOS 11 ve sonrası tüm cihazlarda APFS native şifreleme aktif, ve "Tüm İçeriği ve Ayarları Sil" komutu Secure Enclave seviyesinde sınıf anahtarını imha eder. Anahtar yok ise NAND'daki şifreli veri matematiksel olarak okunamaz.
Android tarafında manzara biraz daha karmaşık. File Based Encryption (FBE) yaklaşımı varsayılan, ancak üretici ROM'una, Knox veya benzeri güvenlik katmanına ve Android sürümüne göre şifreleme anahtarı yönetimi değişiyor. Yine de modern Android cihazlarda factory reset'ten sonra veri kurtarma penceresi son derece dar.
Pratik tavsiye, sıkça duyduğumuz "telefonum donmuştu, factory reset attım, fotoğraflarım gitti" cümlesinin önüne geçmek için çok basit: factory reset asla bir sorun giderme adımı olarak ilk denenecek şey değildir. Önce yedek, sonra yedek, sonra yedek, ve ancak ondan sonra reset. Format sonrası fotoğraf kurtarma vakaları artık çoğunlukla telefon kaynaklı geliyor, ve modern cihazlarda format öncesi durumun yedeklenmesi tek gerçek korunmadır.
Ders 9: Bulutta Sanılan Yedek ve KVKK Veri Aktarım Gerçeği
"Bulutta zaten var" cümlesi bir başka tehlikeli sanı. Sync klasörü yedek değildir. Sync klasöründe yapılan değişiklik, silinme dahil, bulut tarafında yansıtılır. Bir ransomware tüm dosyaları şifrelediğinde, sync klasörü bunu sadıkça buluta aktarır. Versioning özelliği varsa kurtarma şansı doğar, ancak bu da sınırlı bir süre penceresi içindir.
Kurumsal SaaS hizmetlerinde de durum farklı değil. Microsoft 365, Google Workspace, ve diğer büyük platformların hizmet sözleşmeleri verinin yedeklenmesinden müşterinin sorumlu olduğunu açıkça yazar. Yani Microsoft sizin OneDrive'ınızdaki tek kopyayı yedeklemekle yükümlü değildir, bu sorumluluk müşteridedir.
Bu noktada KVKK uyum boyutu da devreye giriyor. Bulut sağlayıcısının veri merkezi nerede, kişisel veri yurt dışına aktarılıyor mu, aktarım için yasal dayanak var mı. KVKK'nın yurt dışına veri aktarımı rejimi 2024 değişiklikleriyle birlikte standart sözleşme hükümleri ve bağlayıcı kurumsal kurallar gibi araçları öne çıkarttı. Bir veri kurtarma vakası, aynı zamanda bir KVKK incelemesi olabilir, çünkü laboratuvara gelen disk içinde işlenen kişisel veri bulundurabilir. Bu yüzden 2003'ten bu yana, kurumsal vakalarımızda gizlilik ve veri işleme sözleşmesi standart adımdır.
Ders 10: Donor Parça, Stratejik Bir Kıtlık Meselesidir
Mekanik disk kurtarmada bir aşamada donor disk ihtiyacı doğar. Bu, aynı model, aynı firmware ailesi, aynı PCB revizyonu, hatta aynı kafa parti numarasıyla eşleşen bir kardeş diskten parça transferini gerektiren bir adımdır.
Yirmi yılda öğrendiğimiz şu, donor diski o vaka geldiğinde bulmaya çalışırsanız geç kalırsınız. Bazı modellerin donor stoğu Türkiye'de yok, Avrupa'da bile sınırlı. ACE Laboratory (acelaboratory.com) gibi profesyonel toolset sağlayıcılarının firmware database'leri ve donor compatibility tabloları bu süreci hızlandırır, ancak fiziksel parçanın kendisi her vakada özel.
Bu yüzden DSET olarak yıllar içinde sektörün belirli modellerinde proaktif donor stoğu tutuyoruz. Müşteriye fark etmeden çalışan bu altyapı, vaka geldiğinde haftalarla ölçülecek bir beklemeyi günlere indiriyor. Bu görünmeyen yatırım, başarı oranını ayakta tutan görünmez bir katman.
Aynı şey controller chip'leri için, PCB ROM bileşenleri için, motor sürücüleri için de geçerli. Tedarik zinciri sorunları, yarı iletken kıtlığının ardından bazı parçalarda ciddi gecikmeler yarattı, ve bu hâlâ bazı vakalarda hissediliyor.
PCB transferi de kafa transferi kadar hassas bir konu. Saha gözleminde "ben yandı sandım, başka PCB taktım, hâlâ açılmıyor" diyerek gelen vakalarda sıklıkla görüyoruz ki ROM chip transferi yapılmamış. Modern HDD PCB'leri serial numarasına ve kafa konfigürasyonuna özel bir ROM içeriği taşır, ve bu içerik PCB üzerinde 8 bacaklı küçük bir SOIC chip'tedir. Doğru transfer yapılmazsa platerde duran veri okunamaz, çünkü preamp parametreleri ve servo kalibrasyon tablosu uyumsuz olur. Bu detay, profesyonel kurtarma laboratuvarını amatör müdahaleden ayıran en somut farklardan biridir.
Ders 11: Bir Veri Kaybı Tek Hata Değil, Hatalar Zincirinin Sonucudur
Sıkça başvurulan kök neden analizi disiplini, havacılıkta "swiss cheese model" olarak bilinir. Birden çok savunma katmanı vardır, her katmanda küçük delikler bulunabilir, ama olay ancak deliklerin hizalandığı anda yaşanır. Veri kaybı da böyledir.
Tek bir hata ile veri kaybı yaşanması nadirdir. Genellikle zincir şöyle ilerler: SMART uyarısı görmezden gelindi, sonra yedekleme yazılımı bir aydır hata veriyordu ama izlenmiyordu, sonra IT sorumlusu izindeydi, sonra geçici çözüm olarak farklı bir cihaza kopya yapılmıştı, sonra o cihaz da arızalandı. Beş katman birden çöktü, ve veri kayboldu.
NIST SP 800-86 ve ISO/IEC 27037'nin ortak vurgusu, olay sonrası post mortem disiplinidir. DSET olarak kurumsal vakalarda kurtarma sonrası bir rapor sunarız, ve bu raporda kök neden zinciri çıkarılır. Tek bir delik kapatmak yetmez, zincirdeki diğer delikleri de işaretlemek gerekir. Aksi takdirde aynı kurum altı ay sonra benzer bir vaka ile geri gelir, deneyimliyoruz.
Bu post mortem disiplini içinde gözlemlediğimiz en yaygın eksiklik, izleme sistemlerinin alarmlarına gerçek anlamda yanıt verilmemesidir. SMART uyarıları çoğu izleme sisteminde aktif, ancak alarm gelen mailbox'a kimse bakmıyor. Yedekleme yazılımı başarısız sonuç bildiriyor, ama dashboard'a giren kimse yok. Bir veri kaybı vakası yaşandığında çoğu zaman aylar önce sistemde sinyaller vardı, ama bu sinyaller insan eylemine dönüşmedi. Otomasyon kadar, otomasyonun çıktısının operasyonel hayata bağlanması da önemli, ve bu insan disiplinidir, teknoloji değil.
Ders 12: Veri Kurtarma ve Adli Bilişim, Artık Tek Bir Disiplindir
İki bin küsür yılların başında veri kurtarma laboratuvarları ve adli bilişim laboratuvarları büyük ölçüde ayrı dünyalardı. Birincisi "veriyi geri getir", ikincisi "veriyi mahkemeye sun". 2020'lerde bu ayrım pratik olarak silinmiş durumda.
Bir fidye yazılım vakası, hem veri kurtarmadır hem adli bilişimdir. Bir çalışan kötü niyetli ayrıldı vakası, hem disk imajıdır hem hukuki delil zinciridir. KVKK kapsamında bir veri ihlali bildirimi, hem teknik bir kurtarma görevidir hem KVKK Kurul'una sunulacak bir teknik rapordur.
ISO/IEC 27037 dijital delil edinme, koruma ve aktarma standardı bugün veri kurtarma laboratuvarlarının da uyması gereken bir çerçeve. Çünkü kurtarılan verinin gelecekte bir hukuki süreçte kullanılma ihtimali her zaman var. DSET'in yaklaşımı şu, her kurumsal vaka adli bilişim disipliniyle başlatılır, gerekirse delil değeri korunur, gerekmezse normal kurtarma akışına devam edilir. Bu yaklaşım, müşterinin sonradan delil değerini kaybetme riskini ortadan kaldırır.
Bu birleşik disiplinin Türkiye'deki en somut göstergesi, KVKK kapsamında veri ihlali bildirimine konu olabilecek vakaların sıklaşmasıdır. Kişisel veri içeren bir veri kaybı yaşanmışsa, kurumun teknik raporlama ve adli zincirleme delil disiplinine ihtiyacı doğar. Laboratuvarın hazırladığı rapor, sadece "veri kurtarıldı" ifadesinden ibaret olamaz, neyin nasıl bulunduğu, hangi yöntemle imaj alındığı, hash değerlerinin nasıl korunduğu, ve raporun hangi adli standartlara uygun yazıldığı da net olmalıdır. Bu olgun rapor disiplini, kurumun KVKK Kurul önündeki pozisyonunu doğrudan güçlendirir.
Adli bilişim bileşeni bireysel vakalarda da hayat kurtaran sonuçlar verebiliyor. Boşanma davalarında, miras anlaşmazlıklarında, ya da bir aile üyesinin vefatı sonrası kişisel arşivin geri kazanılmasında, kurtarılan verinin hukuki delil değeri taşıyabilmesi için zincirleme delil disiplini şart. Bu nedenle DSET bireysel vakalarda da, müşteri talep etmese bile, asgari delil disiplinini uygular. Eğer ileride hukuki bir süreç doğarsa, rapor o günkü hâliyle mahkemeye sunulabilir bir nitelik taşır.
Yirmi Yılda Değişen ve Değişmeyen Disiplinler
Yirmi yıl önce laboratuvarımıza gelen tipik bir vaka, 80 GB ya da 160 GB bir IDE diskti, üzerinde Word belgeleri ve sayısal fotoğraflar vardı, ve müşteri çoğunlukla bireyseldi. Bugün gelen tipik bir vaka, ya 8 TB üzeri kapasiteli bir NAS disk takımıdır, ya bir NVMe SSD'dir, ya bir akıllı telefondur, ya da fidye yazılım vurmuş bir kurumsal dizidir.
Değişmeyen şey, müşterinin yaşadığı duygu. Yıl 2003 olsun, yıl 2026 olsun, veri kaybı yaşayan insanın yüzündeki ifade aynı. Bir doktora tezi, bir aile albümü, bir şirketin yedi yıllık muhasebe arşivi, ya da bir mimarın üç yıllık proje portföyü olsun, bu verinin kaybı duygu olarak başka hiçbir kayba benzemez. Bu yüzden 20 yıldır birinci kuralımız aynı kaldı: vakayı sadece bir teknik problem olarak değil, sahibinin yaşamındaki bir kayıp olarak ele almak.
Değişen şey ise, çözüm araç setinin agresif biçimde genişlemesi. 2003'te tek bir PC3000 lisansı yetiyordu, bugün laboratuvarımızda HDD, SSD, mobile, monolithic flash, RAID, NAS, NVMe için ayrılmış aletler ve yazılım stack'leri var. Eğitim de paralel olarak büyüdü, 1.350'den fazla akademimiz mezunu, Türkiye'nin farklı kurumlarında bu disiplini yayan teknisyenler olarak çalışıyor.
Yirmi Yılın Toplamı, Tek Bir Cümlede
Veri kurtarma laboratuvarı bir geri dönüşüm tesisi değil, bir kritik bakım disiplinidir. Bir hayat kurtarma odasına ne kadar yakınsa, bir reklam ajansından o kadar uzaktır. Yirmi yıllık birikim bize öğretti ki ekipman alınır, yazılım lisanslanır, donor stok tutulur, ama gerçekten fark yaratan tek şey, vakanın geldiği saniye verilen kararlardır. Doğru karar, çoğu zaman "cihaza dokunma, ara" kadar basittir.
20.000 TB'ın üzerinde kurtarılmış veri, 100'ü aşkın kurumsal müşteri ve 1.350'den fazla akademimiz mezunu, bu disiplinin Türkiye'de var olabileceğinin kanıtı. %99.4 başarı oranı, abartılı bir slogan değil, yukarıda anlatılan 12 dersi içselleştirmiş bir laboratuvarın doğal çıktısı.
Verinizi Henüz Riskte Değilken Düşünün
Veri kayıp anı, mantıklı karar verilemeyen anlardan biridir. Panik vardır, telaş vardır, sorumluluk endişesi vardır. O an gelmeden önce bir kez bizi tanıyın, prosedürlerimizi inceleyin, soru sorun. Bu görüşmenin maliyeti sıfır, sağladığı zihinsel hazırlık ise yıllarca biriken bir verinin tamamına eşit.
DSET veri kurtarma laboratuvarı, Hacettepe Teknokent Ankara adresinde 2003'ten bu yana hizmet veriyor. Türkiye'nin her ilinden kurumsal ve bireysel vaka kabul ediyoruz, kurumsal vakalar için yerinde teknik ziyaret yapıyoruz, ve gizlilik sözleşmesi standart adım olarak imzalanıyor.
Bir vakanızı görüşmek, ikinci görüş almak, ya da kurumunuzun yedekleme disiplinini gözden geçirmek için bize ulaşın. Telefon hattımız +90 536 662 38 09, ve ekibimiz işin başında olduğu sürece çalan her telefona aynı 20 yıllık disiplinle cevap veriyor.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.