Кому-нибудь приходилось иметь дело с поврежденной файловой системой на томе шлюза хранения? Один из моих томов теперь сообщает мне, что он поврежден или нечитаем. Я пробовал запустить на нем chkdsk / r, и это заняло несколько дней (объем 10 ТБ). После завершения я получил такое же сообщение об ошибке. У меня не было запланировано создание снимков, поэтому у меня нет предыдущей версии этих файлов. В настоящее время я работаю с поддержкой AWS, и они заставляют меня запускать chkdsk несколькими способами. Кому-нибудь приходилось сталкиваться с этим раньше?
PS: Кстати, не запускайте chkdsk на томе шлюза хранения, он портит ваш кеш и работает очень медленно
Мы решили эту проблему и вернули файлы. По совету службы поддержки AWS я создал моментальный снимок тома шлюза хранилища EBS, восстановил его как том EBS, подключил к довольно мощному инстансу EC2 и запустил оттуда chkdsk. Поскольку это был том EBS, напрямую подключенный к компьютеру и не проходивший через шлюз хранилища или глобальную сеть для выполнения chkdsk, он работал намного быстрее, чем при других способах (для запуска chkdsk на 6 ТБ данных на томе 10 ТБ все же потребовалось несколько дней) . Когда chkdsk завершился и мы подтвердили, что у нас есть доступ к файлам из экземпляра EC2, мы сделали моментальный снимок тома и восстановили его на нашем локальном шлюзе хранилища.
Мораль истории - если вы используете шлюз хранения, знайте, что файловые системы могут быть повреждены в облаке, и планируйте моментальные снимки на своих томах, если это произойдет.