Auteur de la discussion
#1
lsof ile Silinmiş Dosyaları Açıkken Keşfetmek ve Kurtarmak
[lsof ile silinmiş dosyaların izini sürmek, özellikle sunucu operasyonlarında sık karşılaşılan bir problemdir. Silinen dosyalar hemen kurtarılamasa da, bazı durumlarda halen açık olan dosya tanıtıcıları üzerinden veri parçalarına ulaşmak mümkün olabilir. Bu yazı, pratik adımlarla hangi durumda neler yapılabileceğini, hangi sınırlar içinde kalınması gerektiğini ve güvenli kurtarma yaklaşımını somut örneklerle anlatır.]
İlk olarak temel mantık: Linux dosya sistemi üzerinde bir dosya silinse bile, o dosyaya referans veren inode ve veri blokları, ilgili süreç tarafından açık kaldığı sürece disk üzerinde yaşamını sürdürebilir. Bu nedenle, lsof gibi araçlar tarafından açılmış dosya tanıtıcılarını (FDs) ve bunların hangi inode’a işaret ettiğini ortaya çıkarabilir. Aşağıdaki adımlar, bu mekanizmayı kullanarak silinmiş görünen ama hâlâ açık olan dosyaları tespit etmeye yöneliktir ve dikkatli bir şekilde uygulanmalıdır.
Bu komut, silinmiş olarak gösterilen dosyaları da dahil olmak üzere, şu anda açık olan tüm dosya trafiğini gösterir. Özellikle TYPE ve SIZE/OFF sütunları üzerinden durum değerlendirmesi yapılabilir. SILDİ yazanlar, link sayısı 0 olduğuna rağmen süreçler tarafından hâlâ erişiliyor anlamına gelebilir.
Burada çıktıda [deleted] ibaresi olan satırlar, dosyanın dosya sistemi tarafından artık var olmamasına rağmen süreç tarafından açık tutulduğunu gösterir. Bu noktada hangi süreçler bu dosyayı hâlâ kullanıyorsa, o süreçlerin davranışlarını değiştirmek gerekebilir (örneğin, yeniden yönlendirme veya kapatma).
Bu bilgi, hangi uygulamanın hangi dosya üzerinden veri yazdığını veya okuduğunu anlamayı kolaylaştırır. Eğer veri kurtarma amaçlıysa, karşılaştırmalı olarak veri akışını takip etmek kritik olabilir.
Son olarak, lsof silinmiş dosyaların hangi durumlarda gerçek kurtarma imkanı sunduğunu ve hangi sınırların bulunduğunu netleştirir: Silinen bir dosya, hiçbir süreç tarafından artık erişilemez hale gelinceye kadar açık kalmıyorsa, kurtarma ihtimali yoktur. Ancak bazı durumlarda, kritik yapılandırma dosyaları veya veri günlükleri hâlâ açıkken, transient olarak elde edilen bilgiler işletme açısından değerli olabilir. Bu nedenle, sistem yöneticileri için lsof ile silinmiş dosyaları keşfetmek, olay müdahalesi ve kapasite planlamasında pratik bir araç olarak kalır. Bu konudaki deneyimlerinizi ve hangi senaryolarda işe yaradığını özelleştirilmiş örneklerle paylaşabilirsiniz.
[lsof ile silinmiş dosyaların izini sürmek, özellikle sunucu operasyonlarında sık karşılaşılan bir problemdir. Silinen dosyalar hemen kurtarılamasa da, bazı durumlarda halen açık olan dosya tanıtıcıları üzerinden veri parçalarına ulaşmak mümkün olabilir. Bu yazı, pratik adımlarla hangi durumda neler yapılabileceğini, hangi sınırlar içinde kalınması gerektiğini ve güvenli kurtarma yaklaşımını somut örneklerle anlatır.]
İlk olarak temel mantık: Linux dosya sistemi üzerinde bir dosya silinse bile, o dosyaya referans veren inode ve veri blokları, ilgili süreç tarafından açık kaldığı sürece disk üzerinde yaşamını sürdürebilir. Bu nedenle, lsof gibi araçlar tarafından açılmış dosya tanıtıcılarını (FDs) ve bunların hangi inode’a işaret ettiğini ortaya çıkarabilir. Aşağıdaki adımlar, bu mekanizmayı kullanarak silinmiş görünen ama hâlâ açık olan dosyaları tespit etmeye yöneliktir ve dikkatli bir şekilde uygulanmalıdır.
- Adım 1: Sistem genelinde açık dosyaları listeleyen temel komut
CODE
1lsof -nP +L1Bu komut, silinmiş olarak gösterilen dosyaları da dahil olmak üzere, şu anda açık olan tüm dosya trafiğini gösterir. Özellikle TYPE ve SIZE/OFF sütunları üzerinden durum değerlendirmesi yapılabilir. SILDİ yazanlar, link sayısı 0 olduğuna rağmen süreçler tarafından hâlâ erişiliyor anlamına gelebilir.
- Adım 2: Silinmiş dosyalara odaklanmak
CODE
1lsof | grep '(deleted)'Burada çıktıda [deleted] ibaresi olan satırlar, dosyanın dosya sistemi tarafından artık var olmamasına rağmen süreç tarafından açık tutulduğunu gösterir. Bu noktada hangi süreçler bu dosyayı hâlâ kullanıyorsa, o süreçlerin davranışlarını değiştirmek gerekebilir (örneğin, yeniden yönlendirme veya kapatma).
- Adım 3: Hangi inode’a bakmak gerektiğini belirlemek
CODE
1lsof -nP | grep '(deleted)' | awk '{print $1" "$2" "$9}'Bu bilgi, hangi uygulamanın hangi dosya üzerinden veri yazdığını veya okuduğunu anlamayı kolaylaştırır. Eğer veri kurtarma amaçlıysa, karşılaştırmalı olarak veri akışını takip etmek kritik olabilir.
- Adım 4: Kurtarma odaklı güvenlik ve operasyonel kaygılar
- Dosya sistemi üzerinde yazma operasyonlarına karşı dikkatli olun. Silinmiş dosyalar üzerinden yeniden yazım, veri bütünlüğünü bozabilir.
- Loglar üzerinden hangi işlemlerin hangi zamanlarda gerçekleştiğini inceleyin. Silinen dosyaların açığı sürece süreçler ve kullanıcı davranışlarıyla ilişkilidir.
- Mümkünse günlük araçlar (örneğin brokerlar veya veritabanı motorları) için silinmiş dosyaların periyodik hatırlatmalarını ve otomatik temizlik politikalarını gözden geçirin.
Son olarak, lsof silinmiş dosyaların hangi durumlarda gerçek kurtarma imkanı sunduğunu ve hangi sınırların bulunduğunu netleştirir: Silinen bir dosya, hiçbir süreç tarafından artık erişilemez hale gelinceye kadar açık kalmıyorsa, kurtarma ihtimali yoktur. Ancak bazı durumlarda, kritik yapılandırma dosyaları veya veri günlükleri hâlâ açıkken, transient olarak elde edilen bilgiler işletme açısından değerli olabilir. Bu nedenle, sistem yöneticileri için lsof ile silinmiş dosyaları keşfetmek, olay müdahalesi ve kapasite planlamasında pratik bir araç olarak kalır. Bu konudaki deneyimlerinizi ve hangi senaryolarda işe yaradığını özelleştirilmiş örneklerle paylaşabilirsiniz.
