Обратите внимание: ответы и комментарии на этот вопрос содержат контент из другого, похожего вопроса, который привлек много внимания со стороны внешних СМИ, но оказался вопросом мистификации в какой-то схеме вирусного маркетинга. Поскольку мы не позволяем злоупотреблять 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.
Факт есть? На данный момент для этого не существует простого / легкого автоматического решения. Восстановление данных - это наука и даже для базовых, распространенных инструментов нужен кто-то, кто сядет и обеспечит наличие данных. Если вы рассчитываете оправиться от этого без значительных простоев, вы будете разочарованы.
Я бы предложил использовать testdisk или какой-нибудь специальный инструмент для восстановления файловой системы. Попробуйте одну систему, посмотрите, работает ли она и т. Д. Нет реального способа автоматизировать процесс но ты, наверное, можешь осторожно делайте это партиями.
Тем не менее, в вопросах и комментариях есть несколько очень пугающих вещей, которые должны быть частью ваших отчетов о действиях.
Во-первых, вы запускали команду везде, не проверяя ее. Запустите команду на одном поле. Потом несколько, потом еще. Обычно, если что-то пойдет не так, лучше, чтобы это повлияло на несколько а не все ваши системы.
Во-вторых
@ Тим, как сделать резервную копию, не монтируя удаленный диск на сервере?
Пугает меня. Одностороннее резервное копирование на уровне файлов решенная проблема. Rsync можно использовать для сохранения разрешений и копирования файлов в одну сторону на резервный сайт. Случайно что-то? Переустановите (желательно автоматически) rsync обратно, и все заработает. В будущем вы можете использовать снимки состояния файловой системы со снимками состояния btrfs или zfs и отправлять их для резервного копирования на уровне системы. Я бы фактически поигрался с разделением серверов приложений, баз данных и хранилища и ввел принцип наименьших привилегий, чтобы вы могли разделить риск чего-то вроде этого ...
Я знаю, что могу сделать все. Теперь мне нужно подумать, как себя защитить
Когда что-то случилось, самое худшее время подумать об этом.
Что мы можем извлечь из этого?
Никогда не запускайте команду сразу везде. Разделите испытательные и производственные машины, и желательно, чтобы производственные машины производились поэтапно. Лучше починить 1 или 10 машин, чем 100 или 1000.
Команды двойной и тройной проверки. Нет ничего постыдного в том, чтобы попросить коллегу дважды проверить: «Эй, я собираюсь проехать диск, не могли бы вы проверить это, чтобы я не протер диск?». Обертка тоже может помочь, но ничто не сравнится с менее уставшими глазами.
Что теперь делать? Отправьте электронное письмо клиентам. Сообщите им, что есть простои и катастрофические сбои. Поговорите со своим начальством, юристами, отделами продаж и т. Д. И узнайте, как вы можете уменьшить ущерб. Начните планировать выздоровление, и при необходимости вам придется в лучшем случае нанять дополнительных рабочих. В худшем случае планируйте потратить много денег на восстановление. На этом этапе вы будете работать над устранением последствий, а также над техническими исправлениями.
Загрузитесь в спасательную систему, предоставленную Hetzner, и проверьте, какие повреждения вы нанесли.
Перенесите все файлы в безопасное место и затем повторно разверните сервер.
Боюсь, это лучшее решение в вашем случае.
Когда вы удаляете материал с помощью rm -rf --no-preserve-root, его почти невозможно восстановить. Скорее всего, вы потеряли все важные файлы.
Так как @faker В своем ответе сказал, что лучший способ действий - это перенести файлы в безопасное место и затем повторно развернуть сервер.
Чтобы избежать подобных ситуаций в будущем, я предлагаю вам:
Делать резервные копии еженедельно или хотя бы раз в две недели. Это поможет вам восстановить поврежденную службу с наименьшим возможным средним временем восстановления.
Не работать как root, когда он не нужен. И всегда подумайте дважды, прежде чем что-либо делать. Я бы посоветовал вам также установить сейф-rm.
Не вводите параметры, которые вы не собираетесь вызывать, Такие как --no-preserve-root или --permission-to-kill-kittens-explicitly-granted, в этом отношении.
У меня была такая же проблема, но просто тестируя с жестким диском, я все потерял. Не знаю, пригодится ли это, но не устанавливайте ничего, не перезаписывайте свои данные, вам необходимо смонтировать жесткие диски и запустить некоторые инструменты криминалистики, такие как вскрытие, фоторекинг, Testdisk.
Я настоятельно рекомендую Testdisk, с помощью некоторых основных команд вы можете восстановить свои данные, если вы не перезаписывали их.
Лучший способ решить такую проблему - это вообще не иметь ее.
Не вводите вручную команду «rm -rf», у которой в списке аргументов есть косая черта. (Помещение таких команд в сценарий оболочки с действительно хорошими процедурами проверки / работоспособности для защиты от совершения глупостей - другое дело.)
Просто не делай этого.
Когда-либо. Если вы думаете, что вам нужно это сделать, вы недостаточно хорошо думаете.
Вместо этого измените рабочий каталог на родительский для каталога, из которого вы собираетесь начать удаление, чтобы цель команды rm не требовала косой черты:
cd / mnt
sudo rm -rf hetznerbackup
Попробую восстановить резервную машину, где хранились все копии:
dd команда.testdisk для восстановления файлов.Допустим, вы хотите восстановить 1 ТБ, вам потребуются дополнительные 2 ТБ, 1 ТБ для резервного копирования (1-й шаг) плюс 1 ТБ для восстановления (2-й шаг).
Я сделал аналогичную ошибку с псевдонимом rm -fr [телефонный звонок] и cd к драгоценному каталогу. Теперь я всегда дважды думаю и перепроверяю пару раз, прежде чем использовать команду rm или dd.
Как упоминалось в другом ответе, у Хетцнера есть система спасения. Он включает в себя как вариант сетевой загрузки с доступом ssh, так и java-апплет, чтобы предоставить вам экран и клавиатуру на вашем vserver.
Если вы хотите восстановить как можно больше, перезагрузите сервер в системе сетевой загрузки, а затем войдите в систему и загрузите образ файловой системы, прочитав соответствующий индекс устройства.
Думаю, должно работать примерно так:
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
надеюсь, это кому-то поможет. ;)
И да, один из предложений - сделать скрипт, который перемещал стопку rm к real.rm и симлинк мв к rm ;)
Остановите все серверные процессы и все, что может вызвать ввод-вывод диска ... затем запустите testdisk, он должен быть в вашем программном стеке. Если у вас есть физический доступ, используйте live cd с testdisk.