Ошибка в понедельник утром: sudo rm -rf --no-preserve-root /

  

Обратите внимание: ответы и комментарии к этому вопросу содержат контент из другого, аналогичного вопроса, который получил большое внимание со стороны средств массовой информации, но оказался предметом мистификации в какой-то схеме вирусного маркетинга. Поскольку мы не разрешаем ServerFault злоупотреблять таким образом, исходный вопрос был удален и ответы были объединены с этим вопросом.


Вот развлекательная трагедия. Сегодня утром я занимался небольшим обслуживанием моего производственного сервера, когда я ошибочно выполнил следующую команду:

sudo rm -rf --no-preserve-root /mnt /hetznerbackup /

Я не заметил последнего пробела перед / и несколько секунд спустя, когда предупреждения заливали мою командную строку, я понял, что я просто нажал кнопку самоуничтожения. Вот немного чего сгорело в моих глазах:

rm: не удается удалить `/mnt /hetznerbackup ': является ли каталог
rm: невозможно удалить `/sys /fs /ecryptfs /version ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /inode_readahead_blks ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /mb_max_to_scan ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /delayed_allocation_blocks ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /max_writeback_mb_bump ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /mb_stream_req ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /mb_min_to_scan ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /mb_stats ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /trigger_fs_error ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /session_write_kbytes ': операция не разрешена
rm: невозможно удалить `/sys /fs /ext4 /md2 /lifetime_write_kbytes ': операция не разрешена
# и так далее..

Я остановил задачу и был освобожден, когда обнаружил, что производственная служба все еще работает. К сожалению, сервер больше не принимает мой открытый ключ или пароль для любого пользователя через SSH.

Как бы вы продвинулись отсюда? Я буду плавать в океане колючей проволоки, чтобы получить этот SSH-доступ.

Сервер запускает Ubuntu-12.04 и размещается в Hetzner.

140 голосов | спросил Jonas Nielsen 7 AMpMon, 07 Apr 2014 10:39:14 +040039Monday 2014, 10:39:14

10 ответов


91

Загрузитесь в спасательную систему, предоставленную Хетзнером, и проверьте, какой урон вы сделали.
Перенесите любые файлы в безопасное место и затем переустановите сервер.

Я боюсь, что это лучшее решение в вашем случае.

ответил faker 7 AMpMon, 07 Apr 2014 11:00:18 +040000Monday 2014, 11:00:18
219

Факт есть? На данный момент для этого нет простого /простого автоматического исправления. Восстановление данных - это science , и даже основные, обычные инструменты требуют, чтобы кто-то сидел и обеспечивал наличие данных. Если вы ожидаете восстановления после этого без огромного количества времени простоя, вы будете разочарованы.

Я бы посоветовал использовать testdisk или некоторый инструмент восстановления конкретной файловой системы. Попробуйте одну систему, посмотрите, работает ли она и т. Д. Нет никакого реального способа автоматизации процесса , но , вы можете тщательно делать это партиями.

Тем не менее, в вопросах и комментариях есть несколько очень страшных вещей, которые должны быть частью ваших отчетов о действиях.

Во-первых, вы запускаете команду везде, не проверяя ее сначала. Выполните команду в одном окне. Потом несколько, потом еще. В принципе, если что-то пойдет не так, лучше, если это повлияет на несколько , а не на все ваши системы.

Во-вторых

  

@ Как сделать резервную копию без установки удаленного диска на сервере?

Меня пугает. Резервное копирование в одностороннем порядке на уровне файлов - это проблема решена . Rsync можно использовать для сохранения разрешений и копирования файлов в одну сторону на сайт резервного копирования. Случайно что-то? Переустановите (желательно автоматически) rsync назад, и все будет работать. В будущем вы можете использовать моментальные снимки уровня файловой системы с моментальными снимками btrfs или zfs и отправлять их для резервного копирования на уровне системы. Я бы действительно играл с разделяющими серверами приложений, базами данных и хранилищем и вводил принцип наименьших привилегий, чтобы вы могли разделить риск чего-то подобного.

  

Я знаю, что я могу что-то сделать. Теперь мне нужно подумать, как защитить себя.

После того, как что-то случилось, самое худшее время, чтобы рассмотреть это.

Что мы можем извлечь из этого?

  1. Резервные копии сохраняют данные. Возможно, карьера.
  2. Если у вас есть инструмент и вы не знаете, что он может сделать, это опасно. Джедай может делать удивительные вещи с помощью светового меча. Комнатный шимпанзе с световыми мечами ... будет беспорядочным.
  3. Никогда не запускайте команду всюду сразу. Разделите испытательные и производственные машины и, предпочтительно, производственные машины поэтапно. Лучше всего исправить 1 или 10 машин, а не 100 или 1000.

  4. Команды двойной и тройной проверки. Нет никакого стыда в том, чтобы попросить сотрудница дважды проверить «эй, я собираюсь записать диск, не могли бы вы проверить это, чтобы я не закончил стирать диск?». Обертка также может помочь, но ничто не сравнится с менее уставшим набором глаз.

Что вы можете сделать сейчас? Получите электронную почту клиентам. Сообщите им, что есть простои, и есть катастрофические неудачи. Поговорите со своими более высокими взлетами, законными, коммерческими и другими, и посмотрите, как вы можете уменьшить ущерб. Начните планировать восстановление, и в случае необходимости вам придется в лучшем случае нанять дополнительные руки. В худшем случае планируют потратить много денег на восстановление. На этом этапе вы будете работать над смягчением падения, а также с техническими исправлениями.

ответил Journeyman Geek 11 AMpMon, 11 Apr 2016 11:02:31 +030002Monday 2016, 11:02:31
90

Когда вы удаляете материал с помощью rm -rf --no-preserve-root, его почти невозможно восстановить. Скорее всего, вы потеряли все важные файлы.

Как сказал @faker в своем ответе, наилучшим способом действий является передача файлов в безопасное место и последующее повторное развертывание сервера.

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

  • Сделайте резервные копии еженедельно или, по крайней мере, раз в две недели. Это поможет вам в восстановлении затронутой службы с минимальным MTTR.

  • Не работайте как root при необходимости . И always думают дважды, прежде чем что-либо делать. Я бы посоветовал вам также установить safe-rm .

  • Не вводите параметры, которые вы не собираетесь вызывать , например - no-preserve-root или - разрешение -to-kill-kittens-explicitly-given, если на то пошло.

ответил Amal Murali 7 AMpMon, 07 Apr 2014 11:57:09 +040057Monday 2014, 11:57:09
46

У меня была такая же проблема, но просто тестирование с помощью жесткого диска я потерял все. Я не знаю, будет ли это полезно, но не устанавливать ничего , не перезаписывать свои данные , вам нужно смонтировать жесткие диски и запустить некоторые криминалистики инструменты, такие как вскрытие, фоторек, Testdisk.

Я настоятельно рекомендую Testdisk, с некоторыми командами basics вы можете восстановить свои данные, если вы не перезаписали его.

ответил Octo 11 AMpMon, 11 Apr 2016 11:17:54 +030017Monday 2016, 11:17:54
33

Лучший способ исправить такую ​​проблему - не иметь ее в первую очередь.

Не вводить вручную команду «rm -rf», которая имеет косую черту в списке аргументов. (Помещение таких команд в сценарий оболочки с действительно хорошими процедурами проверки /здравомыслия, чтобы защитить вас от выполнения чего-то глупого, отличается.)

Просто не делай этого.
Когда-либо. Если вы считаете, что вам нужно это сделать, вы не слишком много думаете.

Вместо этого измените рабочий каталог на родителя каталога, из которого вы собираетесь начать удаление, так что для цели команды rm не требуется слэш:

  

cd /mnt

     

sudo rm -rf hetznerbackup

ответил Monty Harder 8 AMpTue, 08 Apr 2014 01:22:18 +040022Tuesday 2014, 01:22:18
16

Я попытался бы восстановить резервную машину, где были сохранены все копии:

  • 1-й шаг. Сделайте резервную копию этих стираемых дисков «резервной машины» с dd.
  • Второй шаг. Используйте testdisk для восстановления файлов.

Итак, скажем, вы хотите восстановить 1 ТБ, вам понадобится дополнительный 2 ТБ, 1 ТБ для резервного копирования (1-й шаг) плюс 1 ТБ для восстановления (2-й шаг).

Я сделал подобную ошибку с псевдонимом rm -fr [phone rang] и cd в ценную директорию. Теперь я всегда думаю дважды и перепроверяю пару раз, прежде чем использовать команду rm или dd.

ответил Abc Xyz 11 AMpMon, 11 Apr 2016 03:32:54 +030032Monday 2016, 03:32:54
7

Как упоминалось в другом ответе, Хетзнер имеет спасательную систему. Он включает в себя как вариант netboot с доступом ssh, так и java-апплет, чтобы предоставить вам экран и клавиатуру на вашем сервере vserver.

Если вы хотите как можно больше восстановить, перезагрузите сервер в систему netboot, а затем войдите в систему и загрузите образ файловой системы, прочитав из соответствующего устройства inode.

Я думаю, что что-то вроде этого должно работать:

ssh root @ host cat /dev /sda> server.img

Конечно, перенаправление выполняется оболочкой перед вызовом команды ssh, поэтому server.img является локальным файлом. Если вы хотите только корневую файловую систему, а не полный диск, замените sda на sda3, если вы используете то же изображение, что и я.

ответил kasperd 7 AMpMon, 07 Apr 2014 11:54:07 +040054Monday 2014, 11:54:07
2
  

Как бы вы продвинулись отсюда?

Я останусь с помощью rm до конца своей жизни и думаю, что это безумие, что trash-cli не является командой удаления по умолчанию в системах nix.

https://github.com/andreafrancia/trash-cli

Я бы удостоверился, что это первая вещь, которую я устанавливаю в совершенно новой системе и alias rm для чего-то, что говорит людям использовать trash-cli. Он также будет содержать примечание о другом псевдониме, который на самом деле запускает /bin /rm, но говорит им, чтобы он не использовал его в большинстве случаев.

:( Настоящая история

ответил Gerry 15 PMpFri, 15 Apr 2016 12:51:28 +030051Friday 2016, 12:51:28
1

Я бы посоветовал в этом случае отключить и использовать debugfs , а с помощью lsdel вы можете перечислить все недавно удаленные файлы, которые не очищаются из журналов и затем dump необходимые файлы. Быстрая ссылка для поиска: http://www.linuxvoodoo.com/resources/howtos/debugfs

надеюсь, что это поможет кому-то. ;)

И да, один раз из предложений - создать скрипт, который переместил ream rm на real.rm и symlinc mv на rm ;)

ответил BiG_NoBoDy 18 PMpMon, 18 Apr 2016 17:46:25 +030046Monday 2016, 17:46:25
-2

Остановите всю процессинговую обработку сервера и все, что может вызвать дисковый ввод /вывод ... затем запустите testdisk, он должен быть в вашем программном стеке. Если у вас есть физический доступ, используйте livecd с testdisk.

ответил Saint Crusty 17 PMpSun, 17 Apr 2016 20:35:51 +030035Sunday 2016, 20:35:51

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132