Nie mówię o odzyskiwaniu usuniętych plików , ale nadpisane pliki. Mianowicie następującymi metodami:
# move
mv new_file old_file
# copy
cp new_file old_file
# edit
vi existing_file
> D
> i new_content
> :x
Czy jest możliwe odzyskanie czegokolwiek, jeśli którakolwiek z powyższych trzech czynności zostanie wykonana przy założeniu, że na komputerze z systemem Linux nie są zainstalowane żadne specjalne programy?
data-recovery
ext4
Przepełnienie pytania
źródło
źródło
mv
) przypomina usuwanieold_file
, a nie zastępowanie go, więc w takim przypadku zastosowanie miałyby metody (jeśli istnieją) odzyskiwania plików usuniętych, w przeciwieństwie do plików zastąpionych. Pozostałe dwa przykłady rzeczywiście zastępują odpowiednio istniejąceold_file
iexisting_file
odpowiednio.mv
jest inny.Odpowiedzi:
Odpowiedź brzmi: „Prawdopodobnie tak, ale zależy to od typu systemu plików i czasu”.
Żaden z tych trzech przykładów nie zastąpi fizycznych bloków danych starego_pliku lub istniejącego_pliku, z wyjątkiem przypadku.
mv new_file old_file
. To rozłączy stary plik. Jeśli istnieją dodatkowe twarde linki do old_file, bloki pozostaną niezmienione w pozostałych linkach. W przeciwnym razie bloki będą na ogół (w zależności od typu systemu plików) umieszczone na wolnej liście. Następnie, jeślimv
wymaga kopiowania (w przeciwieństwie do tylko przenoszenia pozycji katalogu), nowe bloki zostaną przydzielone jakomv
zapisy.Te nowo przydzielone bloki mogą, ale nie muszą być tymi samymi, które zostały właśnie uwolnione . W systemach plików, takich jak UFS , bloki są przydzielane, jeśli to możliwe, z tej samej grupy cylindrów, co katalog, w którym plik został utworzony. Istnieje więc szansa, że połączenie pliku z katalogu i utworzenie pliku w tym samym katalogu zostanie ponownie wykorzystane ( i nadpisują) niektóre z tych samych bloków, które właśnie zostały uwolnione. Dlatego standardową poradą dla osób, które przypadkowo usuną plik, jest nie zapisywanie żadnych nowych danych w plikach w drzewie katalogów (a najlepiej nie w całym systemie plików), dopóki ktoś nie spróbuje odzyskać pliku.
cp new_file old_file
wykona następujące czynności (możesz użyć,strace
aby zobaczyć wywołania systemowe):Flaga O_TRUNC spowoduje zwolnienie wszystkich bloków danych, podobnie jak
mv
powyżej. I jak wyżej, będą one generalnie dodawane do darmowej listy i mogą, ale nie muszą, zostać ponownie wykorzystane przez kolejne zapisy wykonane przezcp
polecenie.vi existing_file
. Jeślivi
takvim
, to:x
polecenie wykonuje następujące czynności:Więc nawet nie usuwa starych danych; dane są przechowywane w pliku kopii zapasowej.
Na FreeBSD,
vi
robiopen("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664)
, który będzie miał taką samą semantykę jakcp
powyżej.Możesz odzyskać część lub całość danych bez specjalnych programów; Wszystko czego potrzebujesz to
grep
idd
, a dostęp do urządzenia surowego.W przypadku małych plików tekstowych jedno
grep
polecenie w odpowiedzi z @Steven D w pytaniu, do którego się łączysz, jest najprostszym sposobem:Ale w przypadku większych plików, które mogą znajdować się w wielu nieciągłych blokach, robię to:
co da ci przesunięcie w bajtach pasującej linii. Postępuj zgodnie z serią
dd
poleceń, zaczynając odChciałbyś również przeczytać kilka bloków przed i po tym bloku. W systemie plików UFS bloki plików mają zwykle rozmiar 8 KB i zwykle są przydzielane dość ściśle, bloki jednego pliku są przeplatane naprzemiennie z blokami 8 KB z innych plików lub wolnej przestrzeni. Ogon pliku na UFS ma do 7 fragmentów 1 KB, które mogą, ale nie muszą być ciągłe.
Oczywiście w systemach plików kompresujących lub szyfrujących dane odzyskiwanie może nie być takie proste.
W Uniksie jest tak naprawdę niewiele narzędzi, które zastąpią bloki danych istniejącego pliku. Przychodzi mi na myśl jedna
dd conv=notrunc
. Innym jestshred
.źródło
btrfs
jest dość odporny na usunięte pliki. Zwykle używa bloków w sposób okrągły, więc jeśli masz wystarczająco dużo miejsca na urządzeniu, plik nie zostanie nadpisany przez długi czas. Zobacz tutajskip=
parametr dd , to zamiast czytać od początku wejścia, pominie tę liczbę bloków. Blok ma domyślnie 512 bajtów, ale można go zmienić za pomocąbs=
parametru.skip=
wartości, która jest o 1 blok (512 bajtów) mniejsza. W moim przykładzie$(expr 13813610612 / 512 - 1)
. Jeśli to nie pomoże, spróbuj jeszcze raz, odejmując 16 lub 32, co pozwoli spojrzeć na obszary o 8192 i 16384 bajtów mniej; pliki są często przydzielane w 8192-bajtowych porcjach. Jeśli próbujesz odzyskać większy plik, wypróbuj większą liczbę, aby zaoszczędzić czas. Zwykle używamcount=16
i patrzę na wynik w edytorze,emacs
który nie ma nic przeciwko, jeśli niektóre dane nie są tekstem.Powiem „nie” (z wielką gwiazdką).
Zastanów się, jak dane są układane na dysku. Masz bloki, które zawierają dane i wskazują następny blok (jeśli taki istnieje).
Kiedy nadpisujesz dane, zmieniasz zawartość bloku (a jeśli rozszerzasz plik cały znacznik końcowy). Więc nic nie powinno być w stanie odzyskać (patrz poniżej).
Jeśli skrócisz plik, tracisz stare bloki i wkrótce zostaną one poddane recyklingowi. Jeśli jesteś programistą, pomyśl o połączonej liście, w której „zgubisz” połowę listy bez wykonywania operacji usuwania / usuwania. Te dane wciąż istnieją, ale powodzenia w ich znalezieniu.
Warto zastanowić się nad fragmentacją.
Fragmentacja występuje, gdy na dysku znajdują się „dziury” niesąsiadujące dane. Może to być spowodowane modyfikacją plików, tak aby je rozszerzyć lub skrócić i nie mieszczą się już w oryginalnym miejscu na dysku.
Jeśli plik przekroczy swój pierwotny rozmiar (w tym momencie musi się przenieść), w zależności od systemu plików możesz skopiować cały plik do nowej lokalizacji, w której nadal byłyby stare dane (ale oznaczone jako wolne) lub po prostu zmienisz stary wskaźnik zakończenia i wskażesz nową lokalizację (doprowadzi to do przeładowania).
Krótko mówiąc, twoje dane są prawdopodobnie utracone (bez przechodzenia przez ekstremalny proces sądowy, w którym patrzysz na nie pod mikroskopem); istnieje jednak szansa, że nadal tam jest.
źródło
ext4
lubxfs
. Z kopiowaniem przy zapisywaniu systemów plików takich jakzfs
ibtrfs
tak naprawdę nigdy nie „zmieniasz zawartości bloku”; te systemy plików zawsze używają zupełnie nowych bloków do przechowywania nowych danych. Również systemy plików oparte na logach, takie jakjffs2
zawsze, zawsze zapisują nowe dane w nowych lokalizacjach (nie „blokach”, te systemy plików nie są oparte na blokach). Biorąc to pod uwagę, nie oznacza to, że łatwo jest znaleźć miejsce, w którym znajdują się stare dane i zrobić to, zanim przestrzeń zostanie poddana recyklingowi. Więc twoja odpowiedź, która nie jest, jest wciąż poprawnaUpewnij się, że masz wystarczająco dużo miejsca na dysku w / var / tmp lub gdzieś dużym.
Próbować
gdzie / dev / sda1 będzie twoim dyskiem w twoim systemie.
Następnie wyszukaj mój ciąg odzyskanego pliku.
To może przede wszystkim tam, Jeśli okaże się to sprawdzić brakuje linespaces, wsporniki, sysmbols etc.
Użyj słowa wyszukiwania z pliku, które jest dość niepotrzebne, lub ciągu, który zmniejszy ilość danych w pliku. Jeśli wyszukasz słowo takie jak „echo”, odzyskasz mnóstwo ciągów znaków, ponieważ system będzie zawierał wiele plików z wyrazem echo.
źródło
Zastąpiłem plik tekstowy (VQ1.txt) danymi testowymi wartymi 12 godzin :( Idea, że Unix zapisuje poprzednią wersję pliku w formacie text.txt ~, sprawiła, że zajrzałem do folderu zawierającego nadpisany plik z $ -ll Full lista pokazała VQ1.txt ~, który zawierał moje „utracone” dane!
źródło
TL; DR - Jeśli nadpisany plik jest nadal utrzymywany przez uruchomiony proces, ten post na blogu może zapisać bekon:
https://www.linux.com/news/bring-back-deleted-files-lsof/
Mówi w nim o usuniętych plikach, ale miałem szczęście, nawet z plikiem, który został zastąpiony przez rsync. Mówię o pliku o pojemności 60 GB, który został zastąpiony plikiem o rozmiarze 4 MB, i mogłem odzyskać oryginał, ponieważ na szczęście nie zatrzymałem trwającego procesu, który go utrzymywał.
źródło