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


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


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

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

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

rm: cannot remove `/mnt/hetznerbackup': Is a directory
rm: cannot remove `/sys/fs/ecryptfs/version': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/inode_readahead_blks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_max_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/delayed_allocation_blocks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/max_writeback_mb_bump': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stream_req': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_min_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stats': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/trigger_fs_error': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/session_write_kbytes': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/lifetime_write_kbytes': Operation not permitted
# and so on..

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

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

Сервер работает под управлением Ubuntu-12.04 и размещается в Hetzner.


140
2018-04-07 06:39


Источник


Восстановить из резервных копий. Честно говоря, это один из тех сценариев не-простой обратный путь. - MadHatter
Как вы даже набираете --no-preserve-root случайно?! : -o - ThatGraemeGuy
Greame, ключи похожи друг на друга. - MadHatter
Работа во вторник: Ищите новую работу;) Возьмите ее как урок, почему нужны резервные копии. - TomTom
Это, похоже, похоже на троллинг для меня. Вы не можете случайно ввести «i-really-mean-delete-my-whole-root». - psusi


Ответы:


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

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


91
2018-04-07 07:00



посмотрите на яркую сторону, по крайней мере, у него нет проблем с бровями! - metacom


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

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

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

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

во-вторых

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

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

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

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

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

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

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

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


219
2018-04-11 08:02



@MarcoMarsala Если вы использовали что-либо перед использованием rsync, вы делали это неправильно. Вы должны использовать rsync через ssh. - Michael Hampton♦
Я бы добавил к этому превосходному ответу: отходите от компьютера. Не пытайтесь ничего исправить, пока не успокоитесь. Вы уже смотрите на серьезный простой; уделяя время размышлениям, вместо того, чтобы разрушать ваши системы еще больше (как в dd выше) не ухудшит ситуацию. - Jenny D
Любая идея, почему команда действительно работает? Если $fooа также $bar были обеими неопределенными, rm -rf / должно быть --no-preserve-root сообщение. Единственный способ, которым я могу думать, что это действительно сработало на машине CentOS7, - это если $bar оценивается *, так что было rm -rf /*, - terdon
Мне нравится стилизм в «Случайно что-то?». Это должно означать, что слово «удалено» было «удалено» или «сброшено» случайно. - sehe
@MarcoMarsala хорошо, по крайней мере, вы теперь знамениты independent.co.uk/life-style/gadgets-and-tech/news/... - Martin Smith


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

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

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

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

  • Не работайте как root, когда не нужно, А также всегда дважды подумайте, прежде чем что-либо делать. Я бы посоветовал вам также установить сейф-ет,

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


90
2018-04-07 07:57



Точно так же, если только вы ДЕЙСТВИТЕЛЬНО ЗНАЧИТЕ ЭТО, не добавляйте --please-destroy-my-drive параметр hdparm, - MikeyB
Я бы хотел добавить; «Тройка проверьте свои аргументы (и параметры) при работе с правами root», «Проверьте свой CurrentWorkingDirectory (прежде чем делать что-то вроде rm -rf *)» и «Используйте полные пути к командам (не ретранслируйте по $ PATH). - Baard Kopperud


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

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


46
2018-04-11 08:17



Я бы определенно рекомендовал отключить хранение в автономном режиме, если это вообще возможно, и повторно установить как «только для чтения», если вы вообще можете. Является ли с проживалом или другим экземпляром сервера. - mhouston100
Я бы даже подумал о том, чтобы сделать dd-биткопию исходного диска на новый диск с монтирования только для чтения исходного диска, чтобы быть в безопасности. - Jim
«Эти инструменты не будут восстанавливать имя файла и путь» Да, они делают. Из трех упомянутых инструментов только одна (Photorec) выполняет резьбу. - Andrea Lazzarotto


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

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

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

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

cd / mnt

sudo rm -rf hetznerbackup


33
2018-04-07 21:22



Я всегда помещал -rf в конец списка аргументов, поэтому rm /bla/foo/bar -rf, По крайней мере, таким образом я не испытываю особых проблем, когда я с радостью нажимаю на возврат после ввода rm / часть. - Jens Timmerman
Аналогично, при удалении файлов «* ~» я сначала набираю тильду, а затем добавляю звездочку. - tekknolagi
Значит, вы скорее удаляете свой дом, чем все в текущем каталоге?!? - greg0ire
@ greg0ire Нет, я думаю, он хотел сказать, что внутри /mnt/hetznerbackup, он должен был использовать «/», чтобы отметить все внутри этой папки .. но от родителя, только hetznerbackup достаточно, без косых черт. - T.Todua
@tazotodua: Я имел в виду комментарий tekknolagi - greg0ire


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

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

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

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


16
2018-04-11 00:32



Это очень сильно обрезало ваш диск. Это серьезно усложняет восстановление. Есть веская причина, по которой OP предположил, что вы пытались использовать testdisk и сначала восстанавливались, и хотя синтаксис dd может быть немного странным, это хорошая причина для двойной и тройной проверки перед запуском команды. Вы только уничтожили один сервер, верно? - Journeyman Geek
Вы все еще можете восстановиться, зависит от того, как долго вы позволили dd чтобы стереть ваш последний шанс. - Abc Xyz
извините, что это, но я чувствую огромный тролль в этом вопросе ... - tymik
надеюсь, что ты чувствуешь себя маленьким троллем в ответ :) - Abc Xyz
Если честно. Я не уверен, что ты настоящий. Если это так, вы, вероятно, ошибаетесь ... - leftcase


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

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

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

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

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


7
2018-04-07 07:54



может быть: ssh root@host cat /dev/sda | gzip -c - > /path/to/dir_on_huge_partition/server.img.gz («на лету» gzip будет или не поможет в зависимости от того, что содержимое файловой системы ...) - Olivier Dulac
@OlivierDulac Используя gzip, этот способ отправит несжатые данные по сети, а затем сжимает их на принимающей стороне. Я предполагаю, что результатом, который вы намеревались достичь, было сжатие данных при передаче. Локальное изображение можно сохранить сжатым или нет, но инструменты, которые вы хотите применить к этому изображению позже, не будут работать со сжатой версией. Если все, что вы хотите достичь, это сжатие данных во время транзита, вы можете использовать функцию сжатия в ssh. Он может быть включен с помощью -Cесли он еще не включен в вашей конфигурации. - kasperd
Я больше пытался уменьшить размер файла. Но если вы хотите сохранить пропускную способность (хорошая идея): просто добавьте цитаты: ssh root@host "cat /dev/sda | gzip -c - " > /path/to/dir_on_huge_partition/server.img.gz (параметр -c для ssh обычно хорош, но вам все равно нужно сжимать в конце, так как ssh будет только сжиматься при входе в его туннель и распаковывать перед отправкой на stdout) - Olivier Dulac


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

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

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

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

:( Правдивая история


2
2018-04-15 09:51



По моему опыту, такие инструменты скорее напоминают неприятность, чем реальную помощь - рано или поздно, и после некоторого ругательства вы ее удалите. Это может быть нормально для рабочей станции, но во многих случаях, если не в большинстве случаев, когда вы выполняете административную работу на сервере, вам действительно нужно удалить данные, а не просто перемещать их в другое место (и если это так, просто используйте mv вместо). Кроме того, автоматическое перемещение данных в папку мусора может привести к серьезным проблемам (например, мусор не в той же файловой системе, безопасность). - maetthu
@maetthu. О, конечно, вещи удаляются после того, как они были в корзине в течение определенного количества дней. Рабочий стол Ubuntu делает это для элементов, которые были в корзине более 30 дней. На сервере вам может понадобиться что-то более короткое, например. trash-empty 5 в cron. Дело в том, чтобы дать вам некоторый льготный период, потому что люди делают ошибки. - Gerry
Разве не лучше ли иметь рабочий план восстановления после стихийного бедствия, а не запрещать основные системные инструменты? - user292812
@ user292812 Я не предлагал запретить / bin / rm, просто чтобы он не был первым вариантом в большинстве случаев (обратите внимание на псевдоним / bin / rm). Ваш вопрос также предполагает ложный выбор между аварийным восстановлением и вариантом удобства для человека. У вас должны быть оба. - Gerry
Двухэтапный процесс удаления может сэкономить массу неприятностей: 1. перейдите к корзине (verbosely), 2. пустой мусор. Я имею в виду такой скрипт для «rm», и он спас меня от случайного удаления важных вещей много раз. - Sam Watkins