Linux altında kaldırılmış bir dosyayı nasıl kurtarırım?


65

Kazara, rmsilmek istemediğim bir dosyayı kullandım . Linux altında geri alabilmemin bir yolu var mı?


@Nav, rm"tehlikeli" bir UNIX / Linux komutudur (okundu $ man rm). Çok dikkatli kullanın . Bununla birlikte, emin olduğunuz dosyaları silmek için hızlı bir yoldur. Modern Linux ve Unix Masaüstü Ortamları bir "Çöp Kutusu" çözümü sunar; böylece kullanıcı yanlışlıkla silinen dosyaları kolayca kurtarabilir.
Jose Elera,


Bunun yerine "rm-çöp" fayda yararlanabileceğinizi gelecekte dosyaları geri almak istiyorsanız, "rm" kullanmayın: github.com/nateshmbhat/rm-trash
Natesh bhat

Yanıtlar:


51

Metin dosyalarını kurtarmak için genel adımlar aşağıda verilmektedir.

  1. Kullanıcıya sistemin tek bir kullanıcı modunda çalıştığını söylemek için ilk önce wall komutunu kullanın:

    # wall
    System is going down to .... please save your work.
    

    Mesaj göndermek için CTRL + D tuşlarına basın.

  2. Ardından, sistemi tek bir kullanıcı moduna almak için init 1 komutunu kullanın:

    # init 1
    
  3. Dosyaları kurtarmak için grep (geleneksel UNIX yolu) kullanma

    Aşağıdaki grep sözdizimini kullanın:

    grep -b 'search-text' /dev/partition > file.txt
    

    VEYA

    grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txt
    

    Nerede,

    -i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character.
    -a : Process a binary file as if it were text
    -B Print number lines/size of leading context before matching lines.
    -A: Print number lines/size of trailing context after matching lines.
    

    / Dev / sda1'deki "nixCraft" sözcüğü ile başlayan metin dosyasını kurtarmak için aşağıdaki komutu deneyebilirsiniz:

    # grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt
    
  4. Sonra file.txt görmek için vi kullanın.

    Bu yöntem SADECE silinmiş dosya metin dosyası ise faydalıdır. Eğer ext2 dosya sistemini kullanıyorsanız recover komutunu deneyin.

Http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html adresinde bulundu.



1
Bu yöntem, metin dosyaları için harikalar yaratıyor, teşekkürler! Bundan hoşlandığım şey, dosya sisteminin günlüğüne (extundelete gibi) dayanmadığı, ancak aslında sürücünün tamamının ham baytlarını taradığı. Bu komut dosyanızı bulamazsa, hiçbir şey olmaz.
Benjamin B.

1
@Quinma bu yöntem olabilir yerine koşma ... sadece küçük değişiklikler içeren uzaktan çalışma init 1, el hariç her sistem cinleri öldürmek sshd. Ayrıca bu noktada, dosyaların geçici verilerin üzerine yazılmasını önlemek için tüm dosya sistemlerini (RO) yeniden ayarlamanız ve tmpfs'e kaydetmeniz (geçici dosyalarınızın ram'a sığacağı varsayılarak) kaydetmeniz gerektiğini düşünüyorum. Elbette, daha sonra başka bir yere kopyalamak zorunda kalacaksınız, uzak bir sunucuya veya yerel dosya sistemlerine geri döndükten sonra bunları RW.
Thomas Guyot-Sionnest

bölümünüz nedir ???
Hatam

1
@ Qback, gerçekten bilmiyorum. Belirtildiği gibi, adım adım izledim. Ancak init 1, idari görevler içindir ve belki de bu çalışma seviyesi senaryosuyla ilgili olmayan süreci öldürür. Bu, sabit diskin kullanılmasını önlemeye ve kurtarmaya çalıştığınız dosyanın üzerine yazmanıza yardımcı olabilir.
Gabriel L. Oliveira,

13
  • Çok önemliyse, diski bilgisayardan alın ve sizin için yapmak üzere bir şirket kiralayın.
  • Yalnızca çok önemliyse, salt okunur diski takın, tüm bölümü kullanarak bir dosyaya kopyalayın ve ddiçindeki dosyayı bulmaya çalışın (kullanarak grepveya bir düzenleyici kullanarak ).

Düzenleme: bazen ddrescuedaha iyi çalışır dd.


1
"içindeki dosyayı bulmaya çalış" kafam karıştı, 15+ GB'lık bir dosyayı nasıl makul bir şekilde açıp bu canavarı grep içine sokup araştırabilirim? Ve metni bulduğunda ne yapardın? Bu iyileşme nasıl olur?
TheLQ

1
Yapılması gereken ilk şey, belirsiz bir sonuç için çok fazla para yakmadan önce bazı ortak araçları denemektir. Btw, grep gerçekten yardımcı olmayacak, photorec veya ext3grep yardımcı olacaktır.
wazoox



5
  • Tek doğru cevap şudur: dosyanızı yedekten geri yükleyin. Herkesin bir yedeği olmalı. Gerçekten önemli dosyalar için iki yedeğiniz olmalıdır. Değil mi Eh, çok kötü, işte bir ders öğrendim (Üzgünüm kulağa sert geliyor, ama veri deposundayım ve insanlar önemli verileri kaybedene kadar desteklemiyorlar, bu verilen bir gerçek. Yani evet, aptal görünüyorsun, ama yani hemen hemen herkes var.

  • Tamam, hiç desteğin yok. Eğer gerekir durdurmak dosya içeriyordu dosya sistemini kullanarak ŞU ANDA . Herhangi yazma etkinliği kesinlikle dosya verilerini hortumla edebilir olabilir (sadece may ) diskte kalır.

  • Hem kök dosya sistemi hem de / home olarak yalnızca bir bölümü kullanmak için trajik hata yaptıysanız, başka bir cihazdan önyüklemeniz gerekir . ŞİMDİ .

  • Dosyanız yaygın bir biçimde ise (Word dosyası, JPG, vb.), Photorec kullanın . Photorec en yaygın dosya biçimlerini alabilir.

  • Daha önce önerilen "ext3 undelete" yöntemini deneyebilirsiniz, ancak komut satırında rahat olmanız, temel linux iç çalışmalarını vb. Anlamanız gerekir.

  • Dosyanız özel bir formata sahipse, zorlu şans. Bir keresinde bazı özel dosyalar için bir sürücü taramak için bir Perl programı yazdım ve oldukça iyi çalıştı; ancak bunu yapmak için biraz programlama bilmeniz ve linux ile oldukça rahat olmanız gerekir.


5

Bunu birkaç yıl önce yaptım. Yaklaşımım doğrudan oldu, kaybedecek zaman yoktu, bölümleri ayırdı ve sonra

dd if=/dev/hda1 of=backup_image.ext3

Bölümün tam durumunun bir yedek dosyasına sahip olmak. Ardından, bölümü tekrar bağlayabilir ve silinen dosyayı, oluşturulan görüntünüzde ararken her zamanki gibi çalışmaya devam edebilirsiniz. Görüntü, tüm "boş" alana ihtiyaç duyduğunuzdan ÇOK büyük olacaktır, bu nedenle saklamak pratik bir sorun olabilir.

Daha sonra, sadece bölüm içeriğinin çorbasında bir yerde olmasını beklediğim metin parçacıklarından sonra sıkıcı aramalar yapmak üzereydi. Örneğin .tex dosyaları bulmak için koştum

grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles

"alt bölüm" ifadesi etrafında geniş bir bağlam yazdı ve çıktıyı elle aranacak bir dosyaya kaydetti. Görüntüyü aramak çok uzun sürdüğü için, benden daha fazla yapmamayı tercih ettiğimden, çok büyük bir bağlam basmıştım.

Ayrıca komut strings, ikili çöpün çıktıdan çıkarılmasında yardımcı oldu, ancak doğru şekilde geri çağırırsam, sorun olabilecek tüm yeni satırları da çıkardı.

İkili dosyaları aynı şekilde bulmak için, karakteristik bir başlık veya belirli bir dosyadaki bir şeyi bulmakta başarılı olabilir, ancak oldukça büyük bir macera olduğunu hayal ediyorum.


Kısa teknik notlar: disk kurtarma ve Ext3 / 4 ile teknik zorluklar vardır. Açıklamak çok uzun, ama kısaca (ve yetersiz): Ext3 / 4, sildiğiniz dosyalarda işletim sistemindeki dosyaların nerede bulunduğunu söyleyen "işaretleri" kaldırıyor. Dosyalar silinmedi, ancak diskte nerede başladıklarını ve bittiklerini kimse bilmiyor, bazen de birçok yerde parçalanıyorlar. Diğer bazı dosya sistemleri sadece dosyaların durumlarını "silindi" olarak ayarlar, fakat konum verilerini tutar. Öyleyse geri alma, bu bayrakla dosya işaretçilerine bakmaktan daha zor değildir (çok fazla etkinlik gerçekleşmediyse hala kullanılabilir olmalıdır) ve ardından içeriklerinin üzerine yazılmadığını umarız.

En iyisi nedir? Retorik, benim görüşüme göre. Sık sık yedekleme, tüm bu sorunların cevabıdır. Otomatik yedekleme sistemi olmayan önemli veriler , gerçekleşmeyi bekleyen bir kazadır, IMHO.


Kişisel zorunlu anekdot: Kaldırtmak gidiyordu foo\ foo*den ~. yazdım

rm -r foo<Tab>*

Ne yazık ki, foogörünüşe göre bir sembolik bağlantı olduğundan ve buna uyan tek dosya olduğundan, kabuk

rm -r foo\ foo *

Enter'a bastım ve oraya oturdum, en fazla bir saniye almış olması gereken komuta baktım. Biraz daha uzun bir süre sonra rm"yazmaya karşı korumalı dosyayı 'bir şeyden çıkarmak için' istediğimi sordum. Oldukça hızlı bir şekilde titremeleri hissettim ve yumuşakça ve çok kontrol ettim Ctrl+c. ~ ~Çocuğumun yarısı silindi, ancak yukarıda anlatılan grepleme ve biraz daha fazla ya da daha az güncel yedeklemeyle, her şeyin değerini geri almayı başardım. Şahsen çok değerli (okuma: zaman alıcı) ve diskte kaybedilen son ölçüm verilerim vardı, ancak dörtlü yedekleme yaptım. Biri burada hayal kırıklığına uğradı, bir başkası okuldaki sistem kesintisi nedeniyle, bir başkası bozuktu ve ilk başta dördüncü bir şey bulamadım, çünkü yanlışlıkla onu yanlış klasöre koydum :-D. Yokturm -ryazmaya karşı korumalı bir dosyaya sıkışıp kaldığında dördüncü, o klasör benim sshfs aracılığıyla monte edildiğinden beri yenilmiş olurdu ~. O zamandan beri böyle şeyler konusunda daha dikkatli oluyorum.


5

Standart buysa rm , sana bir yedekleme umuyoruz. Silinen bir dosyayı kurtarma prosedürü, herhangi bir şekilde yapılabiliyorsa, her dosya sistemi için farklı olacaktır. Linux'ta yerleşik bir "geri dönüşüm kutusu" yoktur; Bir dosyayı sildiğinizde, hepsi gider.

Herhangi bir şekilde, bilgisayarı fişten çekmek isteyeceksiniz - mümkün olan en kısa sürede, bilgisayarı çalıştırmaya devam ederken (hatta kapatmaya devam etmek) diske yazma işlemine neden olur ve bazı blokların daha önce işgal ettiği tarafından engellenme olasılığını artırır dosyanın üzerine yazılacak. Bunu yaptıktan sonra, başka bir bilgisayara yerleştirin, canlı bir CD'yi yeniden başlatın (salt okunur şekilde takmadan sürücüyü takmadığınızdan emin olun) veya sabit sürücüyü çıkarın ve veri kurtarma uzmanına götürün.


4

Beklentilerinizi düşük ayarlayın. 'Silinen' verileri üzerine bir şey yazılmışsa, kaybedersiniz.

Az miktarda kurtarma yaptım ve bulduğum en iyi araçlar genellikle belirli biçimlere yönelik olarak tasarlandı. Örneğin, 'fotorec', onbinlerce jpeğin kurtarılmasını istediğimde harikaydı.

Recuva bana daha önce de yardımcı oldu ve en iyi seçiminiz olabilir. (Ücretsizdir, reklamlarıyla ödeme yapmaya kandırılmayın)

Günün sonunda, kaybettiğiniz şey önemliyse, sürücüyü çevrimdışına alın ve yazmayı bırakın. Verilerinizi geri alana kadar veya bulabileceğinize değinceye kadar bulabileceğiniz her kurtarma yazılımını kullanın. Gerçekten önemliyse, profesyonellere yüksek fiyata gönderin.

Daha önce bir araçla şansınız varsa, aşina olduğunuz şekilde tekrar deneyin. Günün sonunda, diske yazmamalılar ve böylece çalışacak olanı bulana kadar yazılımı kullanabilirsiniz.


2

İşte sizin için harika bir belge . Burada bir sürü pratik ipucu bulacaksınız.

BTW, iki grup insan var:

  1. yedekleme yapanlar
  2. yedekleme yapacaklar

Tebrikler, kendinizi sadece grup 2'ye yükselttiniz; ;-)


2

Şu anda VLC veya LibreOffice gibi dosyayı okuyan bir uygulamanız varsa, bu müthiş L & U.SO cevabı bu karışıklıktan kurtulmamda bana yardımcı oldu. İşte aynısını yapmak için alternatif bir yöntem .

Genel fikir, bağlantıyı bulmak /proc/PID/fd/DESCRIPTOR_NUMBERve orijinal konumuna geri kopyalamaktır. ps aux | grep APP_NAMEPID'yi bulmak ve ardından ls -la /proc/PID/fd/uygun DESCRIPTOR_NUMBER öğesini bulmak için kullanın .


1

"Doğru" cevap, güvenli bir şekilde kurtarmanın ve bunun yerine yedeklemelerden veya klonlanmış bir sistemden geri yükleme veya yeniden yükleme yönteminin olmadığını varsaymaktır.

TestDisk harika bir araçtır ve dosya sistemi ve silme sıklığını bağlı fiziksel sürücüden bazı veri kurtarma için güçlü olmanın başka yolları da vardır, ama sadece çok büyük olabilir, bu yüzden olabilir harcanan zaman ve ağrı BACKUPS TUTUN (ve ayrıca testi geçerli ve düzeltilebilir olduklarını)!


1

Diğer kullanıcılar tarafından üzerine yazılmadıysa, şanslısınız demektir. Yanlışlıkla cpp kaynak dosyamı sildim ve en başta denilen bir araç kullandım , bu da diskten 60G cpp artıklarını geri yüklememe yardımcı oldu. Sonunda, bu enkazın parça parça birleştirilmesiyle dosyamı kurtardım. Belli bir dosya tipi için belirli bir deseni taradığını ve dosyaları kurtarmak için diskteki tüm düğümleri geçtiğini düşünüyorum! Sadece bir dene!


0

Yanlışlıkla dosyayı Linux'tan silmişseniz, bu komutu kullanabilirsiniz:

find /root -name "search text" -type f  -exec mv {} "/home" \;

bunun search textyerine dosya adını koyabilir ve yerine geri yüklemek istediğiniz dizini belirleyebilirsiniz /home.


2
Selam Santosh. Lütfen yazılarınıza yanıltıcı bağlantılar eklemeyin. Kaldırıldı.
13'te

0

Bu betiği deneyebilirsiniz. Güzel çalışıyor ve rm yerine kullanılmaya başlandı ve şimdi yaygın olarak kullanıyorum.

https://github.com/nateshmbhat/safe-rm

Özellikleri :

  • rm yerine kullanılmak üzere
  • rm'nin alabileceği tüm argümanları ele alır.
  • Dosya adı çarpışmalarını, önceden alınmış dosyalar ile ele alır.
  • bazı izin sorunlarını otomatik olarak ele alır
  • rm, başka bir betikten veya dolaylı olarak çağırılırsa, sistem 'rm' komutu otomatik olarak kullanılır.
  • ortaya çıkanlar gibi uygun hata mesajlarını gösterir. rm

-2

Geçen hafta aynı problemi yaşadım ve debugfs, photorec, ext3grep ve extundelete gibi birçok program denedim. ext3grep, dosyaları kurtarmak için en iyi programdı. Sintaks çok kolaydır:

ext3grep image.img --restore-all

veya:

ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’

Bu video şovları size yardımcı olabilecek küçük bir rehberdir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.