Совершил ужасную глупую ошибку. Пожалуйста, посоветуйте мне, как мне лучше поступить. Моя конфигурация - это RAID5 из дисков 4x4 ТБ. Вдобавок к этому LVM с различными разделами, включая /, swap, все. Конфигурация была полностью автоматической на основе сценариев установки центра обработки данных.
У меня возникли различные проблемы с производительностью, когда некоторые процессы постоянно считывали / записывали на моих дисках, поэтому, читая статьи о размере блока, я понял, что должен провести эксперимент и уменьшить размер блока с 512 КБ до 64 КБ. Таким образом, только для изменения этого:
mdadm --grow -c 64 --backup-file=/root/somefile.txt /dev/md2
Да, файл должен был быть размещен ВНЕШНИЙ, но к нему не было подключено ничего другого, и это было связано с риском. Команда немедленно вышла, так что понял, что это было. Выполнил команду ls, OK, а затем сервер начал не отвечать. Единственное, что работало, - это некоторые процессы, такие как nginx, которые имели приоритет -10 nice и не имели возможности остановить их, чтобы увидеть, что происходит, поскольку ничего не работало: webmin загружался вечно, SSH запрашивал пользователя и пароль, а затем нет консоль, существующее соединение SSH заблокировано через секунду ls. Я понял, что мой сервер мониторинга и другие процессы теперь съедают все мои ресурсы ввода-вывода, и поэтому я ничего не могу сделать, пока не убью их всех, поэтому с консоли центра обработки данных отправил CTRL + ALT + DEL в сервер, это не сработало. Наконец, выяснилось, что при аппаратном сбросе произойдет перезагрузка и остановка некоторых вещей, которые позже потребуют перезапуска вручную, что позволит мне увидеть, что не так. Полагаю, это большая ошибка.
Сервер не перезагружался, так как / dev / md2 сейчас не может быть найден, и все находится на томе RAID5.
Я много читал о различных mdadm -analyze -scan и стратегиях восстановления, но я действительно не хочу снова трогать свою систему, пока не спрошу некоторых экспертов. Это моя глупость привела к этой ситуации.
Я не могу сказать, насколько важно восстановить как можно больше из почти 11 ТБ уникальных данных. Позже я, к сожалению, понял, что, хотя mdadm завершается быстро, фоновые процессы работают и, что наиболее важно, первая часть --grow является критической. Питание было отключено через несколько минут, может быть, через 10 после начала роста.
Пожалуйста, порекомендуйте. Спасибо!
Я выяснил это с помощью Фила Турмела из списка рассылки linux-raid@vger.kernel.org, в моем случае
mdadm -E /dev/sd[a-d]3 (partitions involved in the volume)
давал последовательную информацию и показывал, что изменение формы остановилось где-то ~ 50 МБ, как ни странно.
mdadm -Av --invalid-backup --backup-file=/some/real/empty/file /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
действительно сработал, поскольку, хотя вы сообщаете mdadm, что файл резервной копии недействителен, вы должны предоставить еще один, чтобы операция продолжилась.
Я действительно рекомендую использовать файлы оверлеев, как описано в https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file так как это позволило мне сначала поработать с недействительной резервной копией, смонтировать разделы и извлечь правильную резервную копию, отменить все изменения моего диска, выбросив наложения, а затем
mdadm -Av --backup-file=/extracted/valid/backup/file /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
все прошло гладко без проблем.
Если у вас все еще нет файла, вы можете просто остановиться, выполнив первую команду, хотя возможна некоторая потеря данных. Однако, если вам не очень повезло потерять с ним некоторые важные метаданные файловой системы / тома, ущерб должен быть минимальным.
Тем не менее, я действительно рекомендую в случае сомнений обращаться за помощью на linux-raid@vger.kernel.org, поскольку все, как правило, можно исправить, но неправильные действия могут действительно разрушить ситуацию.