Właśnie „mv” zmieniłem katalog o pojemności 49 GB do złej ścieżki do pliku, czy można przywrócić pierwotny stan plików?

Mam (no cóż, miałem ) katalog:

/media/admin/my_data

Miał rozmiar około 49 GB i zawierał dziesiątki tysięcy plików. Katalog jest punktem podłączenia aktywnej partycji LUKS.

Chciałem zmienić nazwę katalogu na:

/media/admin/my_data_on_60GB_partition

Nie zdawałem sobie wtedy sprawy, ale wydałem polecenie z katalogu domowego, więc skończyłem na:

~% sudo mv /media/admin/my_data my_data_on_60GB_partition

Tak więc mvprogram zaczął się przenosić /media/admin/my_datai jego zawartość do nowego katalogu ~/my_data_on_60GB_partition.

Użyłem Ctrl+, Caby częściowo anulować polecenie, więc teraz mam całą grupę plików podzielonych na katalogi:

~/my_data_on_60GB_partition    <---  about 2GB worth files in here

i

/media/admin/my_data           <---- about 47GB of orig files in here    

Nowy katalog ~/my_data_on_60GB_partitioni niektóre z jego podkatalogów są własnością root.
Zakładam, że mvprogram musiał najpierw skopiować pliki jako root, a następnie po przeniesieniu chownz powrotem je na moje konto użytkownika.

Mam nieco starą kopię zapasową katalogu / partycji.
Moje pytanie brzmi: czy można niezawodnie przywrócić wiązkę plików, które zostały przeniesione?

Czy mogę po prostu uruchomić:

sudo mv ~/my_data_on_60GB_partition/*  /media/admin/my_data

czy powinienem zrezygnować z próby odzyskania, ponieważ pliki są prawdopodobnie uszkodzone i częściowo kompletne itp.?

• System operacyjny - Ubuntu 16.04

mv --version  
mv (GNU coreutils) 8.25

Podczas przenoszenia plików pomiędzy systemami plików, mvnie usunąć plik przed jego zakończeniu kopiowania go i przetwarza pliki sekwencyjnie (I początkowo powiedział, że kopie następnie kasuje każdy plik po kolei, ale to nie jest gwarantowane - przynajmniej GNU mvkopii następnie usuwa każdy Command argument linii , a POSIX określa to zachowanie ). Powinieneś mieć co najwyżej jeden niekompletny plik w katalogu docelowym, a oryginał nadal będzie w katalogu źródłowym.

Aby cofnąć zmiany, dodaj -iflagę, aby mvniczego nie nadpisywać:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

(zakładając, że nie masz żadnych ukrytych plików do przywrócenia ~/my_data_on_60GB_partition/) lub jeszcze lepiej (biorąc pod uwagę, że, jak odkryłeś, możesz mieć wiele plików oczekujących na usunięcie), dodaj -nflagę, aby mvniczego nie zastępować, ale nie zapytam cię o to:

sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/

Możesz także dodać -vflagę, aby zobaczyć, co się dzieje.

W przypadku dowolnej zgodnej z POSIX mvoryginalna struktura katalogów powinna pozostać nienaruszona, więc alternatywnie możesz to sprawdzić - i po prostu usunąć /media/admin/my_data... (W ogólnym przypadku jednak uważam, że mv -nwariant jest bezpieczny - obsługuje wszystkie formy mv, w tym np mv /media/admin/my_data/* my_data_on_60GB_partition/ .)

Prawdopodobnie będziesz musiał przywrócić niektóre uprawnienia; możesz to zrobić masowo za pomocą chowni chmod, lub przywrócić je z kopii zapasowych za pomocą getfacli setfacl(dzięki Sato Katsura za przypomnienie ).

Po uzyskaniu odpowiedzi Stephena Kitta i omówieniu tego polecenia jako potencjalnego rozwiązania:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

Postanowiłem wstrzymać się z uruchomieniem go, dopóki nie skupię się na tym, co się dzieje, ta odpowiedź opisuje to, czego się dowiedziałam i co skończyłam.

Używam GNU, mvktóry kopiuje pliki do celu, a tylko wtedy, gdy operacja kopiowania się powiedzie, usuwa oryginał.
Chciałem jednak potwierdzić, czy mvwykonuje tę sekwencję jeden plik na raz, jeśli to prawda, oryginalna zawartość folderu zostałaby czysto podzielona na dwie części, jedna przesunięta do miejsca docelowego, a druga pozostawiona w źródle. Być może miałby miejsce jeden plik, który został przerwany podczas kopiowania, który byłby wspólny dla obu katalogów - i prawdopodobnie byłby zniekształcony.

Aby odkryć pliki, które były wspólne między dwoma katalogami, uruchomiłem:

~% sudo diff -r --report-identical-files my_data_on_60GB_partition/. /media/admin/mydata/. | grep identical | wc -l
14237

Ten wynik sugerował, że w katalogach źródłowym i docelowym było 14 237 takich samych plików, co potwierdziłem, sprawdzając pliki ręcznie - tak, w obu katalogach było wiele takich samych plików. Sugeruje to, że dopiero po mvskopiowaniu wielkich kawałków plików wykonuje usuwanie plików źródłowych. Szybkie wyszukiwanie w infona mvkomendzie wykazało

mvNajpierw używa [ ] tego samego kodu, którego używa cp -ado kopiowania żądanych katalogów i plików, a następnie (zakładając, że kopiowanie się powiedzie) usuwa oryginały. Jeśli kopiowanie nie powiedzie się, część skopiowana na partycję docelową zostanie usunięta.

Nie uruchomiłem polecenia, ale podejrzewam, czy spróbowałem uruchomić

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

-i Szybka przed zastąpienie prawdopodobnie byłby uruchamiany ponad 14.000 razy.

Następnie sprawdź, ile wszystkich plików w nowo utworzonym katalogu:

~% sudo find my_data_on_60GB_partition/ -type f -a -print | wc -l                                                                    
14238

Zatem jeśli w nowym katalogu było 14238 zwykłych plików, a 14237 miało identyczne oryginały z powrotem w źródle, oznacza to, że w nowym katalogu był tylko jeden plik, który nie miał odpowiadającego identycznego pliku z powrotem w źródle. Aby dowiedzieć się, co to był plik, uruchomiłem rsync z powrotem w kierunku źródła:

~% sudo rsync -av --dry-run my_data_on_60GB_partition/ /media/admin/my_data
sending incremental file list
./
Education_learning_reference/
Education_learning_reference/Business_Education/
Education_learning_reference/Business_Education/Business_education_media_files/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/
Education_learning_reference/Business_Education/Business_education_media_files/Jeff Hoffman - videos/Jeff and David F interview/018 business plans-identifying main KPIs.flv

sent 494,548 bytes  received 1,881 bytes  330,952.67 bytes/sec
total size is 1,900,548,824  speedup is 3,828.44 (DRY RUN)

Szybka kontrola potwierdziła, że ​​był to zniekształcony plik, w którym plik istniał zarówno na źródłowym, jak i docelowym, docelowym pliku = 64 MB, oryginalnym = 100 MB. Ten plik i jego hierarchia katalogów były nadal własnością roota i nie przywrócono jeszcze oryginalnych uprawnień.

Podsumowując:

• wszystkie pliki, które mvnigdy nie dotarły, wciąż znajdują się w swoich oryginalnych lokalizacjach (oczywiście)
• wszystkie pliki, które zostały mvcałkowicie skopiowane, nadal miały swoje oryginalne kopie w katalogu źródłowym
• plik, który został tylko częściowo skopiowany, nadal miał oryginał w katalogu źródłowym

Innymi słowy wszystkie oryginalne pliki pozostały nienaruszone, a rozwiązaniem w tym przypadku było po prostu usunięcie nowego katalogu!

Pomyślałem, że skomentuję, że niektórzy ludzie mogą mieć ochotę wrzucić „xargs” do miksu, aby równolegle uruchamiać rzeczy. To daje mi wolę i naprawdę podoba mi się powyższe rozwiązanie rsync.

Jeśli chodzi o system plików o przenoszeniu i kopiowaniu oraz o tym, kiedy dokładnie zostanie usunięty oryginał, VFS i bazowy system (pliki) współrzędnych gwarantują atomowość poszczególnych plików przed przejściem do tego kroku usuwania. Więc nawet jeśli zostanie przerwany przed pełnym zapisaniem pliku docelowego, całe blokowanie w VFS jest naprawdę ścisłe i chroni przed takimi przypadkowymi przeplataniem danych, nawet w równoległych przypadkach. (Pracowałem na Linux VFS i NFS4)

Dodanie „xargs” do miksu prawdopodobnie sprawiłoby, że krok sprawdzania podwójnego zdrowia byłby kłopotliwy, z wieloma plikami w połowie tranzytu. Chciałbym mieć więcej skryptów na poziomie systemu. Dobre przypomnienia dla mnie!

Podobało mi się pytanie, dobre dla pajęczyn i sprawia, że ​​znów kocham rsync. Twoje zdrowie!