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