Silinen dosyalar geri getirilebilir mi? Disk, SSD ve telefonda gerçekçi ihtimaller

Bu soru iki farklı ihtiyaçtan gelir: kaybolan bir fotoğrafı ya da belgeyi geri istemek, ya da bir dosyanın silinip silinmediğini ve ne zaman silindiğini göstermek. İlkinde içerik, ikincisinde iz önemlidir. Bu yazı ikisini de ortam ortam ele alır. Bilgisayarda silinen dosyanın hangi kayıtlarla tespit edildiğini ayrıntılı olarak bilgisayar incelemesi sayfasında anlattık.

Bir dosya silinince gerçekte ne olur?

Silme çoğu zaman içeriği değil, içeriğe giden yolu kaldırır. Dosya sistemi dosyanın kaydını boş olarak işaretler ve kapladığı alanı yeni yazılara açar; içerik, o alan yeniden kullanılana kadar diskte durur.

NTFS'te bu kayıt Ana Dosya Tablosu'dur ($MFT). Microsoft'a göre silinen dosyanın MFT girdisi boş olarak işaretlenir ve yeniden kullanılabilir. Girdi yeniden kullanılana kadar dosyanın adı, boyutu ve zamanları, çok küçük dosyalarda içeriğin kendisi orada okunabilir.

Çöp kutusuna taşımak ise silme değildir; dosya yalnızca başka bir klasöre gider. Windows'ta Shift+Delete ile silinen dosya Geri Dönüşüm Kutusu'na hiç uğramaz.

Sonrası ortama göre ayrılır. Sabit disk boşalan alanı kendiliğinden temizlemez. SSD ve telefon belleği ise flash bellektir ve boşalan alanı kendisi yönetir. Asıl fark burada doğar.

Önce çöp kutusuna bakın: hangisi ne kadar bekler?

Kurtarma programından önce bakılacak yer, işletim sisteminin ya da uygulamanın kendi çöp kutusudur. Süreler değişebildiği için kendi cihazınızda doğrulayın.

Eski bilgiler sizi yanıltmasın: Google Fotoğraflar'ın yardım sayfası bugün yedeklenmiş öğeler için de 30 gün yazıyor. Google ve Apple, çöp kutusundan da silinen ya da süresi dolan öğenin geri alınamayacağını açıkça belirtiyor.

Hangi ortamda kurtarma ihtimali ne?

İçeriğin geri gelme ihtimalini ortam, silmenin biçimi ve o andan sonra ne kadar yazma yapıldığı belirler.

SSD'de silinen dosya neden çoğu zaman geri gelmez?

Çünkü dosya sistemi boşalan alanı TRIM komutuyla sürücüye bildirir ve sürücü o alanı bundan sonra boş kabul eder. Microsoft'a göre NTFS'te TRIM, yönetici kapatmadıkça varsayılan olarak açıktır; durumu fsutil behavior query DisableDeleteNotify komutu gösterir (0 açık demektir). Sürücü bu blokları çöp toplama (garbage collection) sırasında siler. Pek çok SSD, TRIM edilmiş bir bloğu fiziksel olarak silmeden önce bile, okunduğunda eski veriyi değil sıfır döndürür. Standart araçlarla yapılan kurtarmanın SSD'de boş çıkması bu yüzdendir.

Bu, NIST'in Eylül 2025'te yayımladığı SP 800-88 Rev. 2 ile çelişmez. NIST, flash bellekte yedek hücreler ve aşınma dengeleme (wear leveling) nedeniyle eski verinin bir kısmının sürücüde kalabileceğini, bu yüzden üzerine yazmanın SSD'yi güvenle temizlemeye yetmediğini yazar. İki bilgi farklı sorulara cevap verir: veri hücrede kalabilir ama sürücü onu normal arayüzden vermez. Ona ulaşmak üretici düzeyinde araç ister ve sonucu belirsizdir.

Yine de SSD'de her şeyi baştan kayıp saymayız. TRIM kapatılmış olabilir, sürücü TRIM desteği bildirmiyor olabilir, dosya silinmeden önce başka bir diske, yedeğe ya da buluta kopyalanmış olabilir. İlk sorumuz silmenin ne zaman, hangi sistemde ve nasıl yapıldığıdır.

Format atılan diskten veri kurtarılır mı?

Bunu en çok biçimlendirmenin türü belirler. Microsoft'un KB 941961 sayılı makalesine göre Windows Vista ve sonraki sürümlerde tam biçimlendirme varsayılan olarak diskin tamamına sıfır yazar; Windows XP ve öncesi yazmıyordu. Hızlı biçimlendirme (format /q ya da Gezgin ve Disk Yönetimi'ndeki hızlı biçimlendirme seçeneği) ise dosya sistemini yeniden kurar, eski içeriği yerinde bırakır. Sabit diskte hızlı biçimlendirmeden sonra dosyaların büyük kısmı, içerikteki dosya imzalarını arayan dosya oyma (carving) yöntemiyle bulunabilir. Oyma dosya adını ve klasör yapısını getirmez; adlar ancak eski dosya sistemi kayıtları kısmen duruyorsa bulunur.

“Üzerine bir kez yazılmış veri laboratuvarda geri getirilir” inancı da güncel değil. NIST SP 800-88 Rev. 2, üzerine yazmanın en gelişmiş laboratuvar tekniklerine karşı bile kurtarmayı genellikle engellediğini ve çok geçişli silme yöntemlerine gerek olmadığını açıkça belirtir. Tam biçimlendirilmiş bir HDD'den içerik beklemeyiz.

Telefonda silinen fotoğraflar geri gelir mi?

Çöp kutusu süresi dolduysa, güncel bir telefonun belleğinden geri getirmek genellikle mümkün değildir. Bunun iki nedeni var:

• Şifreleme. iPhone'da Veri Koruma her dosya için ayrı bir anahtar üretir; bu anahtar bir sınıf anahtarıyla sarmalanıp dosyanın meta verisinde saklanır. Dosyanın kaydı gidince anahtarı da gider; bellekte şifreli bloklar kalsa bile çözülemez. Android 10 ve sonrasıyla çıkan yeni cihazlarda tam disk şifrelemesine izin verilmez, dosya tabanlı şifreleme (FBE) kullanılır.
• TRIM. Telefon belleği de flash bellektir. Android'in depolama hizmeti, cihaz boştayken yaptığı bakımda dosya sistemine fstrim uygular.

Bu yüzden bilgisayarda işe yarayan “ham bellekten dosya oyma” yaklaşımı güncel telefonlarda sonuç vermez. Silinen içerik telefonun belleğinde değil, başka yerlerde aranır:

• Yedekler. Silmeden önce alınmış bir bilgisayar yedeği ya da iCloud Yedeklemesi. Apple'a göre iCloud Fotoğrafları açıksa fotoğraflar zaten iCloud'a eşitlendiği için iCloud Yedeklemesi'ne girmez; Mesajlar iCloud'da açıksa mesajlar da girmez.
• Başka yerdeki kopyalar. Fotoğraf bir sohbet uygulamasıyla gönderildiyse karşı tarafta, paylaşılan bir albümde ya da ayrı bir bulut hesabında kopyası olabilir.
• Uygulama veri tabanları. Mesajlaşma uygulamaları veriyi SQLite veri tabanlarında tutar. Silinen satır, serbest sayfalarda ya da veri tabanının yanındaki -wal dosyasında bir süre kalabilir. SQLite'ın belgelerine göre bu izi bırakmak istemeyen uygulama secure_delete ayarını açar ya da silmeden sonra VACUUM çalıştırır. Android'in sistemle gelen SQLite kütüphanesi bu ayar açık derlenir; böyle bir veri tabanında silinen içerik sıfırlanır ve iz daha çok WAL dosyasında aranır. Ayrıntı: mobil cihaz ve uygulama incelemesi.
• Önbellekler. Uygulamaların görsel önbelleğinde silinmiş bir fotoğrafın küçük resmi kalabilir.

Silindiğini fark ettiğinizde ilk ne yapmalı?

1. Cihazı ya da diski kullanmayı bırakın. HDD'de her yeni yazma, silinen içeriğin bir kısmının üzerine gelebilir. İndirme, güncelleme ve program kurma da yazmadır.
2. Önce zarar vermeyen yerlere bakın. Çöp kutusu, Son Silinenler, bulut hesabının çöp kutusu, eski yedekler. Süresi dolmak üzere olanı ilk kurtarın.
3. Kurtarma programını aynı diske kurmayın. Kurtarılan dosyaları da aynı diske kaydetmeyin. Silinen dosya sistem diskindeyse bilgisayarı kapatın; disk başka bir bilgisayara salt okunur bağlanmalı ya da imajı alınmalıdır.
4. Kanıt değeri varsa önce imaj. Diskin birebir kopyası alınır, hash değeri kaydedilir, kurtarma kopya üzerinde denenir. Neden böyle yapıldığını hash değeri ve dijital delil bütünlüğü yazısında anlattık.
5. SSD'de beklentiyi doğru kurun. TRIM silme anında gönderildiği için kullanmayı bırakmak içeriği çoğu zaman geri getirmez; ama dosya sistemindeki izleri korur.
6. Telefonda sıfırlamayın, büyük güncellemeyi erteleyin. Silmeden önce alınmış eski bir yedek varsa ona dokunmayın, yenisini ayrı bir yere alın.

Silinen dosya bir uyuşmazlığın konusuysa hangi materyalin nasıl korunacağı dijital delil nasıl korunur rehberinde.

İçerik gitse de silinen dosyanın izi kalabilir

Adli incelemede çoğu zaman sorulan, dosyanın içeriği değil varlığıdır: bu belge bu bilgisayarda var mıydı, ne zaman silindi? İçerik kurtarılamasa bile şu kayıtlar bunu gösterebilir:

$MFT

Girdi yeniden kullanılana kadar dosyanın adı, üst klasörü ve zamanları.

$LogFile ve $UsnJrnl

NTFS'in işlem günlüğü ($LogFile) son meta veri değişikliklerini tutar, boyutu sınırlı olduğu için geçmişi kısadır. Değişiklik günlüğü ($UsnJrnl) silmeyi USN_REASON_FILE_DELETE nedeniyle kaydeder. İkisi de içerik tutmaz.

Geri Dönüşüm Kutusu

$I dosyası orijinal yolu, boyutu ve kutuya atılma zamanını tutar; kutu boşaltılsa da HDD'de kalıntısı bulunabilir.

LNK dosyaları ve Jump Lists

Kısayol dosyası, açılan dosyanın yolunu, zamanlarını ve bulunduğu birimin seri numarasını taşır; hedef silinse de kısayol kalır.

Küçük resim önbelleği

thumbcache_*.db dosyaları, Gezgin'in önizleme ürettiği görsellerin küçük kopyalarını tutar. Önizleme üretildiğini gösterir; kimin baktığını tek başına göstermez.

SQLite WAL

Bir mesajın ya da kaydın silinmeden önceki hâli, checkpoint öncesinde yakalanan -wal dosyasında durabilir.

Raporda bu izleri “dosya şu tarihte şu yolda bulunuyordu” düzeyinde yazarız, yorumu bulgudan ayırırız. Hiçbir izin bulunamaması ise dosyanın hiç var olmadığını göstermez; SSD ve telefon incelemelerinde bu cümleyi ayrıca yazarız.