Ошибка в понедельник утром: 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.

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

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

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

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

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

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

во-вторых

@ Тим, как сделать резервную копию без подключения удаленного диска на сервере?

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

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

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

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

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

3. Никогда не запускайте команду везде сразу. Разделяйте испытательные и производственные машины и, предпочтительно, производите их поэтапно. Лучше исправить 1 или 10 машин, а не 100 или 1000.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

кд / минт

sudo rm -rf hetznerbackup

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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