Я просто «mv» создал 49-гигабайтный каталог для плохого пути к файлу, возможно ли восстановить исходное состояние файлов?

У меня есть (ну, у меня) каталог:

/media/admin/my_data 

Он был размером около 49 ГБ и имел в нем десятки тысяч файлов. Каталог – это точка монтирования активного раздела LUKS.

Я хотел переименовать каталог:

 /media/admin/my_data_on_60GB_partition 

В то время я не понимал, но я отдал команду из домашнего каталога, поэтому я закончил:

 ~% sudo mv /media/admin/my_data my_data_on_60GB_partition 

Итак, программа mv начала перемещать /media/admin/my_data и ее содержимое в новый каталог ~/my_data_on_60GB_partition .

Я использовал Ctrl + C, чтобы отменить часть команды, поэтому теперь у меня есть целая куча файлов, разделенных по каталогам:

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

а также

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

Новый каталог ~/my_data_on_60GB_partition и некоторые его подкаталоги принадлежат root.
Я предполагаю, что программа mv должна сначала скопировать файлы в качестве корня, а затем, после того как передача chown вернула их обратно в мою учетную запись пользователя.

У меня есть несколько старая резервная копия каталога / раздела.
Мой вопрос : можно ли надежно восстановить кучу файлов, которые были перемещены?

То есть, могу я просто запустить:

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

или я должен отказаться от попытки восстановления, так как файлы могут быть повреждены и частично завершены и т. д.?

  • OS – Ubuntu 16.04
 mv --version mv (GNU coreutils) 8.25 

При перемещении файлов между файловыми системами mv не удаляет файл до того, как он закончит его копирование, и он последовательно обрабатывает файлы (я сначала сказал, что он копирует, а затем удаляет каждый файл по очереди, но это не гарантируется – по крайней мере, копии GNU mv затем удаляют каждый аргумент командной строки , а POSIX задает это поведение ). Таким образом, вы должны иметь не более одного неполного файла в целевом каталоге, а оригинал будет по-прежнему находиться в исходной папке.

Чтобы переместить все, добавьте флаг -i поэтому mv ничего не перезаписывает:

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

(при условии, что у вас нет скрытых файлов для восстановления из ~/my_data_on_60GB_partition/ ) или еще лучше (учитывая, что, как вы обнаружили, у вас может быть много файлов, ожидающих их удаления), добавьте флаг -n чтобы mv didn ' t перезаписывать все, но не спрашивает вас об этом:

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

Вы также можете добавить флаг -v чтобы узнать, что делается.

С любым POSIX-совместимым mv исходная структура каталогов все равно остается неповрежденной, поэтому вы можете проверить это – и просто удалить /media/admin/my_data … (В общем случае, я думаю, что вариант mv -n безопасный подход – он обрабатывает все формы mv , включая, например, mv /media/admin/my_data/* my_data_on_60GB_partition/ .)

Вероятно, вам нужно будет восстановить некоторые разрешения; вы можете сделать это в массовом порядке с помощью chown и chmod или восстановить их из резервных копий с помощью getfacl и setfacl (спасибо Сато Кацуре за напоминание ).

После получения ответа Стивена Китта и обсуждения этой команды в качестве потенциального решения:

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

Я решил удержаться от работы, пока не узнал, что происходит, этот ответ описывает то, что я узнал и закончил.

Я использую Gnu mv который копирует файлы в цель, тогда только если операция копирования прошла успешно, она удаляет оригинал.
Однако я хотел бы подтвердить, будет ли mv выполнять эту последовательность по одному файлу за раз, если бы это было так, исходное содержимое папки было бы чисто нарезано на две части, одна часть была перенесена в пункт назначения, а другая осталась позади в источнике. Возможно, файл, который был прерван во время копирования, который будет распространяться между двумя каталогами, будет иметь неправильный характер.

Чтобы обнаружить файлы, которые были распространены между двумя каталогами, я запускал:

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

Этот результат предположил, что в обоих исходных и целевых каталогах было 14 237 экземпляров одинаковых файлов, я подтвердил их вручную, да, в обоих каталогах было много одинаковых файлов. Это говорит о том, что только после того, как mv копирует большое количество файлов, он выполняет удаление исходных файлов. Быстрый просмотр info о команде mv показал

Он [ mv ] сначала использует тот же код, который используется cp -a для копирования запрошенных каталогов и файлов, затем (при условии, что копия выполнена успешно) удаляет оригиналы. Если копия завершается с ошибкой, удаляется часть, скопированная в целевой раздел.

Я не запускал команду, но я подозреваю, что попытался запустить

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

-i перед перезаписью, вероятно, вызвало бы более 14 000 раз.

Итак, чтобы узнать, сколько всего файлов во вновь созданной директории:

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

Итак, если в новом каталоге было 14238 обычных файлов, а у 14237 были идентичные оригиналы в исходном коде, это означает, что в новом каталоге был только один файл, у которого не было соответствующего идентичного файла. Чтобы узнать, что это за файл, я запустил rsync обратно в направлении источника:

 ~% 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) 

Быстрая проверка подтвердила, что это был неверный файл, где файл существовал как для источника, так и для адресата, целевого файла = 64 МБ, оригинал = 100 МБ. Этот файл и его иерархия каталогов по-прежнему принадлежали root и еще не восстанавливали исходные разрешения.

Итак, вкратце:

  • все файлы, которые mv никогда не достигали, все еще вернулись в свои первоначальные местоположения (очевидно)
  • все файлы, которые mv полностью копировали, имели исходные копии в исходном каталоге
  • файл, который был только частично скопирован, все еще имел оригинал в исходном каталоге

Другими словами, все исходные файлы остались неповрежденными, и в этом случае решение было просто удалить новый каталог!

Я просто подумал, что прокомментирую, что некоторые люди могут испытывать соблазн бросить «харги» в микс, чтобы работать параллельно. Это дает мне завещания, и мне очень нравится решение rsync выше.

Что касается файловой системы о перемещении и копировании, и когда именно оригинал удаляется, VFS и базовые файловые системы (координаты) координируют, чтобы гарантировать атомарность каждого файла, прежде чем перейти к этапу удаления. Поэтому, даже если он прерван до того, как целевой файл будет полностью записан, вся блокировка в VFS является реальной и защищает от случайных чередований данных даже в параллельных случаях. (Я работал над Linux VFS и NFS4)

Добавление «xargs» в микс, вероятно, сделало бы шаг двойного контроля над головной болью, с несколькими файлами в середине транзита. Хотелось бы, чтобы у меня было больше системных сценариев. Хорошие напоминания для меня!

Любимый вопрос, хороший для паутины, и заставляет меня снова любить rsync. Ура!