У меня есть (ну, у меня есть)имел) каталог:
/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программа изначально скопировала файлы как пользователь root, а затем после переноса chownвернула их в мою учетную запись пользователя.
У меня есть довольно старая резервная копия каталога/раздела.
Мой вопрос в том,возможно ли надежно восстановить кучу перемещенных файлов?
То есть, могу ли я просто запустить:
sudo mv ~/my_data_on_60GB_partition/* /media/admin/my_data
или мне следует отказаться от попыток восстановления, так как файлы, возможно, повреждены и частично заполнены и т. д.?
- ОС - Ubuntu 16.04
mv --version
mv (GNU coreutils) 8.25
решение1
При перемещении файлов между файловыми системами 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ничего не перезаписывать, но и не спрашивать вас об этом:
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(благодаряСато Кацурадлянапоминание).
решение2
Получив ответ Стивена Китта и обсудив эту команду как потенциальное решение:
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копирования больших массивов файлов он выполняет удаление исходных файлов. Быстрый поиск в команде infoon показалmv
Он [
mv] сначала использует часть того же кода, который используетсяcp -aдля копирования запрошенных каталогов и файлов, затем (предполагая, что копирование прошло успешно) удаляет оригиналы. Если копирование не удается, то часть, которая была скопирована в целевой раздел, удаляется.
Я не запускал команду, но подозреваю, что если бы я попытался запустить
sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
The-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были скопированы полностью, все еще имели свои оригинальные копии в исходном каталоге - файл, который был скопирован только частично, все еще имел оригинал в исходном каталоге
Другими словами, все исходные файлы остались нетронутыми, и решением в данном случае было просто удалить новый каталог!
решение3
Я просто подумал, что стоит прокомментировать, что некоторые люди могут поддаться искушению добавить 'xargs' в смесь, чтобы запустить вещи параллельно. Это заставляет меня нервничать, и мне действительно нравится решение rsync выше.
Что касается файловой системы, перемещения и копирования, и когда именно удаляется оригинал, VFS и базовая файловая система(ы) координируют работу, чтобы гарантировать атомарность каждого файла до того, как перейти к этапу удаления. Так что даже если она прерывается до того, как целевой файл полностью записан, вся блокировка в VFS очень строгая и защищает от таких вещей, как случайное чередование данных, даже в параллельных случаях. (Я работал с Linux VFS и NFS4)
Добавление 'xargs' в смесь, вероятно, сделало бы шаг двойной проверки работоспособности головной болью, с несколькими файлами в середине передачи. Хотелось бы, чтобы у меня было больше скриптов на системном уровне. Хорошие напоминания для меня!
Понравился вопрос, хорош для паутины, и заставляет меня снова полюбить rsync. Ура!