У меня есть Xen domU, предоставленный третьей стороной, работающий под управлением Ubuntu (10.04, серверная версия, стандартное ядро сервера). Этот сервер запускает Dovecot и Exim4 с почтой, хранящейся в Maildirs, и запускает довольно типичный стек LAMP с большинством приложений на Perl, и все данные хранятся либо в дереве каталогов, полном файлов TIFF, либо в базе данных MySQL. Этот сервер работает для LAMP около 3 месяцев и месяц обслуживает почту. Все файловые системы (кроме свопа) - Ext3.
Пару недель назад мы внезапно обнаружили целую кучу файлов TIFF, которые больше не были доступны, как было отмечено нашим сценарием резервного копирования (с использованием rsync). rsync на удаленном хосте сообщил о следующих ошибках:
rsync: readlink_stat("/srv/data/documents/archive/pdf/2007/Aug/06/085717/00000002.TIF") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2007/Aug/06/085717/00000001.TIF") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/XSMDESC.DAT") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/DOC010.XST") failed: Input/output error (5)
rsync: readlink_stat("/srv/data/documents/archive/pdf/2011/Jan/04/125227/00000001.TIF") failed: Input/output error (5)
...и так далее. Файлы будут созданы либо в конце декабря, либо в дату, указанную в пути, в зависимости от того, что будет позже, поскольку мы перенесли наши данные на этот компьютер в конце прошлого года. Насколько мне известно, никакие процессы не будут записывать в файлы с тех пор - только чтение из них.
В течение дня мы отметили, что список затронутых файлов увеличивался, поэтому в ту ночь мы отключили эту файловую систему (виртуальное блочное устройство Xen) и запустили fsck, который нашел и исправил очень много ошибок. Затронутые файлы исчезли. Однако повреждение перестало распространяться после завершения fsck и перемонтирования файловой системы.
(Кстати, чтобы проиллюстрировать, как нам здесь повезло - единственный диск, на котором хранилась наша единственная резервная копия этих данных, катастрофически умер в тот же день. Да, действительно. Наш единственный Другой резервная копия была от 10 декабря 2010 года ...)
Это может иметь значение, а может и не иметь значения, что подавляющее большинство затронутых файлов было создано 4 или 5 января этого года, однако некоторые из них были документами от 2006/7, а некоторые были более новыми.
Когда fsck завершен, и машина теперь, по-видимому, стабильна, мы были обеспокоены - провайдер хостинга не смог найти первопричину, и мы не смогли - и мы потеряли данные, но, по крайней мере, повреждение прекратилось.
Перейти на несколько дней вперед и рутина mysqldump отказывается выгружать 3 таблицы, потому что они помечены как поврежденные. mysqlcheck подтверждает это, и REPAIR TABLE [foo] исправляет все 3, в 2 случаях сообщая о меньшем количестве строк, найденных после события, чем до него. И снова поставщик не видит первопричины, не было прерывания питания, доступа к диску или mysqld. Проблема кажется не связанной, но - за 3 месяца размещения на этом сервере мы уже потеряли больше данных, чем за несколько лет запуска этих приложений на различных (но никогда не виртуальных!) Платформах.
Наконец, на этой неделе мы обнаружили 3 файла в FS, которые, похоже, превратились в двоичный мусор - точнее, все единицы (или все \0xFF Если вы предпочитаете). Все 3 файла (2 небольших текстовых файла конфигурации, 1 сценарий Perl на 100 строк) были частью нашего веб-приложения и часто читались, но записывались только тогда, когда мы развертывали новую версию, которая работает путем обновления локального "рабочего" copy, экспортировав эту рабочую копию, чтобы получить чистую новую установку, и указав символическую ссылку на эту новую установку. Файлы были повреждены в рабочей копии и распространены оттуда, и время модификации всех файлов соответствовало тому, что они не менялись в течение многих недель (за это время было несколько развертываний, и все они прошли нормально!), Поэтому содержимое явно изменилось без обновления mtime.
Любое из этих событий заставит меня восстанавливаться из резервных копий, почесать голову и продолжить свою жизнь, но 3 за две недели заставляют меня ждать следующего события.
Мои вопросы просты: возможно ли, что эти 3 события связаны, и если да, то где мне искать основную причину?
(Также приветствуются ответы относительно решений, однако мы уже находимся в процессе настройки параллельной платформы под управлением CentOS, на VMware, с тем же поставщиком, чтобы попытаться исключить проблемы, связанные с распространением, ядром, гипервизором и виртуальными блочными устройствами. Это могло бы Было бы здорово узнать, в чем проблема, но если у нас нет диагноза и замена всего этого стека сработает, это поможет мне спать по ночам ... в конце концов.)
Как всегда, если какая-либо дополнительная информация поможет, прокомментируйте, и я обновлю ее соответствующим образом!
Похоже, что программа резервного копирования поставщика повредила файловую систему.
У нас был аналогичный случай, когда DomU начал плохо себя вести после того, как для него была создана резервная копия непропатченной версии нашего стандартного клиента резервного копирования.
После двух попыток восстановить fs он продолжал работать некорректно (файлы не читались ...)
Решением было полностью переустановить файловые системы (mkfs), установить последнюю исправленную версию стандартного клиента резервного копирования и затем восстановить последние исправные данные.
Здесь нам повезло: раздел данных (/ opt) остался цел и ничего не потерял. Поврежденные разделы просто содержали / и / var.