Моментальные снимки для одного из наших томов AWS повреждены. Мы используем эти снимки в качестве резервных копий, и в прошлом они нам очень помогали. (NB: это не единственный наш метод резервного копирования!) Однако поврежденный снимок бесполезен.
Интересно, как с этим справиться, как это заранее определить и т. Д.
Ситуация
У нас есть веб-сервер AWS с одним большим томом ext3 (DATA) с множеством изображений в одной папке. Мы делаем ежедневные снимки всех томов, и, поскольку мы храним их в течение четырех недель, это слишком дорого. Мне нужен только один снимок изображений на случай чрезвычайной ситуации, а для остального тома я хочу нормальное количество. Вот что я хотел сделать:
Шаг 3 не сработал. Получила следующую ошибку:
sudo mount / dev / xvdf / images
mount: mount / dev / xvdf on / images failed: структура нуждается в очистке
Погуглил для этой ошибки, я нашел совет сделать xfs_check, но файловая система - ext3, поэтому я попробовал e2fsck. Это привело к бесконечным ошибкам и исправлениям, которые, казалось, не работали.
sudo xfs_check /dev/xvdf
sudo e2fsck -f /dev/xvdf
Я создал новый том, ИЗОБРАЖЕНИЯ, и использовал rsync, чтобы скопировать все, так как cp приводил к сбою. Я немедленно создал снимок нового тома и восстановил его, чтобы проверить, работает ли он нормально, что и произошло.
Затем я разделил том и заменил старый том двумя новыми. Все это работает, и проблемы решены.
Поддержка Amazon
Тем не менее я хочу знать, что здесь произошло, и как предотвратить это в будущем, поэтому я обратился в службу поддержки Amazon. Они сказали мне, что снимки были повреждены, вероятно, потому, что снимки были сделаны во время использования тома. Мы делаем это постоянно, выполняли много операций восстановления с этими снимками (но не с этим томом), никогда не было проблем. Этот том был присоединен, но на момент создания снимка не выполнял никаких операций записи.
Я решил последовать совету, отсоединить том, сделать снимок и посмотреть, что произошло. После отсоединения исходный том DATA больше не может быть присоединен. Поскольку я уже заменил этот том, это не имеет никаких последствий, так что это не большая проблема, но очевидно, что это не работает как adv (ert) ised.
Снимок можно прикрепить и смонтировать, и я могу открывать открытые папки и т. Д. Когда я выполняю e2fsck, я снова получаю ошибки. Оглядываясь назад, я забыл сделать этот e2fsck на исходном томе DATA, что очень жаль. Я думаю, это тоже сообщило бы об ошибках.
На этот раз уровень поддержки Amazon был ниже среднего, и это очень жаль.
Вопросы
badblocks для подобных проблем (требуется очистка структуры). Когда я восстанавливаю моментальный снимок на новый (виртуальный) том, проверка этого тома кажется бесполезной, поскольку он находится в другом физическом месте. Полезны ли плохие блоки в таком случае? Снимок не поврежден. Файловая система, содержащаяся в снимке, повреждена. Есть разница.
Файловая система в моментальном снимке может быть повреждена, если вы сделаете снимок, когда файловая система находится в процессе записи данных. Это может произойти, если при создании моментального снимка были записаны только некоторые из группы блоков «все или ничего».
Раньше, если ваши старые моментальные снимки были сделаны во время использования тома и восстановление было нормальным, это просто неудача: в момент создания моментального снимка запись в файловую систему не производилась. Ваша удача закончилась, и вы столкнулись с возможными последствиями этого сценария.
Самый простой способ справиться с этой проблемой - просто предотвратить ее возникновение. Чтобы избежать подобных проблем, AWS рекомендует:
fsfreeze), umount), илиaws ec2 stop-instances).Видеть: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Поскольку вы обнаружили, что файловая система повреждена, лучше всего исправить файловую систему, прежде чем делать что-либо еще.
xfs_check или e2fsck чтобы исправить любые поврежденные блоки в вашей файловой системе.Как только ваша файловая система будет исправлена, примите меры для предотвращения проблемы (см. Раздел 1).