Восстановление Proxmox Backup Server: RAID6, ext4 и ошибки I/O

Когда на моём Proxmox Backup Server перестало открываться хранилище, я столкнулся сразу с двумя проблемами: неактивным RAID6 на HDD и ошибками файловой системы на системном SSD.

Ниже я разберу, как проверял диски, собирал существующий массив и возвращал доступ к резервным копиям. По ходу объясню команды, которые пришлось использовать: без понимания их назначения в такой ситуации легко начать исправлять совсем не тот диск.

Результат у этой истории промежуточный. Доступ к каталогам резервных копий я получил, журнал ext4 восстановил, но спустя некоторое время системный том снова начал выдавать ошибки. Поэтому это разбор диагностики и частичного восстановления, а не история о полностью починенном сервере.

Что у меня было установлено​

Сервер назывался pbs2. Система PBS находилась на SSD ADATA SU650 объёмом 240 GB, а резервные копии — на отдельном программном RAID6 с файловой системой XFS.

Для начала я разделил четыре понятия, которые постоянно встречались в выводе команд:

• Диск — физический накопитель, например SSD или HDD.
• MD RAID — массив, собранный Linux из нескольких дисков. У меня он представлялся одним устройством /dev/md127. Управлять им позволяет mdadm.
• Файловая система — организация файлов на устройстве. На системном томе у меня была ext4, на массиве — XFS.
• Datastore PBS — каталог с данными резервных копий, который зарегистрирован в настройках PBS. Мой datastore назывался Local_pbs2 и использовал путь /mnt/Local_Storage.

Ещё в системе использовался LVM. Он представлял системный раздел как логический том /dev/mapper/pbs-root. Именно этот том позднее фигурировал в ошибках ext4.

На момент проверки диски распределялись так:

Все имена устройств ниже относятся к моей конфигурации. Перед повторением любой операции с дисками нужно определить свои накопители по модели, серийному номеру, UUID и метаданным. После перезапуска буквы /dev/sdX могут измениться. Приведённые блоки — отдельные шаги моей диагностики, а не готовый скрипт для запуска целиком.

Нажмите, чтобы развернуть...

Сначала я выяснил, где находятся система и резервные копии​

Начал с просмотра конфигурации:


Команда pvs показала две группы: pve на /dev/sda3 и pbs на /dev/sdg3. Доступных для импорта пулов ZFS не оказалось.

В /etc/fstab я нашёл запись XFS-хранилища, а в /proc/mdstat — массив md127 в состоянии inactive. То есть устройства были обнаружены, но массив ещё не работал как доступное хранилище.


Я проверил группы LVM, таблицу монтирования и исходное состояние массива.

На этом этапе стало понятно, что нужно разбираться с Linux MD. Создание нового пула ZFS или форматирование дисков к моей задаче отношения не имели.

Как я проверил участников RAID6​

Для начала запросил сведения о массиве, затем прочитал метаданные дисков:


У этих команд разные задачи. --detail показывает сведения о самом массиве, а --examine читает метаданные на его предполагаемых участниках.

Метаданные можно представить как служебную запись на диске: к какому массиву он относится, какую позицию занимал и с какими параметрами работал.


В исходном состоянии mdadm обнаружил пять устройств, но массив оставался неактивным.

Я сопоставил UUID массива, роли дисков, счётчики событий и контрольные суммы. На доступных участниках UUID совпадал:


В проверенных суперблоках были Events=2, состояние clean и корректные контрольные суммы. Массив имел имя pbs2:1, метаданные версии 1.2 и блоки по 256 KiB.

Всего в конфигурации предусматривалось шесть участников. Я обнаружил роли 0, 1, 2, 3 и 5; позиция 4 отсутствовала.


Я сопоставил метаданные доступных участников. Одинаковые параметры позволили перейти к сборке существующего массива.

Запись AAAAAA в суперблоках я не стал принимать за доказательство того, что сейчас доступны все шесть дисков: она отражала сохранённое состояние. Фактически у меня было пять участников.

Почему первую сборку я сделал только для чтения​

Моей первой задачей было посмотреть, сохранилось ли содержимое хранилища. Поэтому существующий неактивный массив я остановил и собрал в режиме только для чтения:


Здесь /dev/sd[b-f] означало пять уже проверенных дисков: sdb, sdc, sdd, sde и sdf.

• --assemble собирает существующий массив по его метаданным.
• --readonly задаёт режим только для чтения.
• --run в этом случае позволил запустить массив в неполном составе.

Эту последовательность я использовал для своего неактивного массива после проверки участников. Останавливать работающий массив с подключёнными файловыми системами ради повторения примера не нужно.

В ответ я получил:


В состоянии массива появились active (read-only) и следующая отметка:


Она означала: предусмотрено шесть участников, доступны пять, одна позиция отсутствует. Массив запустился, но остался деградированным. Полный состав я не восстановил.


Я получил доступ к существующему RAID6 на пяти дисках из шести, без применения --force.

Как я увидел каталоги резервных копий​

На /dev/md127 определилась файловая система XFS. Её UUID был:


Для первого просмотра я использовал отдельный каталог:


Монтирование подключает файловую систему к каталогу Linux. В моём случае содержимое массива становилось доступно через /mnt/pbs-recovery.

Параметр ro запрещал запись, а norecovery отключал восстановление журнала XFS при монтировании. Такой режим подошёл для первоначального осмотра. При незавершённых операциях часть файлов в нём может быть недоступна, поэтому сам по себе просмотр каталогов не заменяет проверку целостности.

На экране появились:



Я увидел структуру прежнего datastore. Это подтвердило доступ к данным на уровне файловой системы.

Каталог .chunks содержит блоки данных резервных копий. Название с точкой не делает его ненужной служебной папкой: удалять его для «очистки места» нельзя.

Наличие каталогов стало хорошим промежуточным результатом. Но утверждать, что любая копия успешно восстановится, я на этом основании не мог: полную проверку и тестовое восстановление ещё предстояло выполнить.

Какие настройки хранилища я проверил​

В файле /etc/proxmox-backup/datastore.cfg находилось описание Local_pbs2 с путём /mnt/Local_Storage. Там же были расписание GC на 8:00 и параметры проверки данных.


Я нашёл существующее описание datastore и проверил настройки mdadm.

В исходном /etc/mdadm/mdadm.conf строки ARRAY не было. При последующей проверке я уже подтвердил такую запись:


В /etc/fstab хранилище было указано по UUID файловой системы. Для себя я разделил назначение этих настроек: mdadm отвечает за сборку массива, fstab — за подключение файловой системы к каталогу, а PBS — за использование этого каталога как datastore.

Я также заметил исходный параметр noatime в fstab. Позже в фактических параметрах рабочего монтирования отображался relatime. Саму работу GC в рамках этой диагностики я не проверял.

Затем обнаружилась отдельная проблема на системном SSD​

В консоль стали сыпаться сообщения:


В моей конфигурации dm-1 соответствовал системному тому pbs-root. На массиве резервных копий была XFS, поэтому переносить выводы об этой ошибке ext4 на RAID6 было бы неправильно.

Журнал файловой системы помогает сохранять согласованность её служебных данных при изменениях и сбоях. Сообщение Detected aborted journal означало, что нормальная работа журнала была прервана. Это требовало отдельной проверки системного тома.


Я зафиксировал ошибки ext4 на системном устройстве dm-1.

Как я проверил ext4 вне работающей системы​

Для проверки корневого тома я перешёл в минимальную среду initramfs. Она позволила работать с томом отдельно от установленной системы.

Сначала активировал группу LVM и проверил, что том не смонтирован:


У системного ext4 был UUID:



Перед проверкой я активировал группу pbs и проверил состояние монтирования тома.

Исправление через e2fsck я выполнял на размонтированном ext4. Запускать его на используемом корневом томе нельзя. Для XFS на /dev/md127 эта программа тоже не подходит.

Первый проход сделал без записи:


Параметр -f запускает проверку даже для файловой системы, которая выглядит чистой, а -n открывает её только для чтения и отказывается от исправлений.

Я получил предупреждения о счётчиках свободных блоков и inode, а также о состоянии orphan-файла. Программа отдельно указала, что восстановление журнала пропущено из-за проверки без записи. Поэтому один только выведенный код завершения я не стал воспринимать как подтверждение исправности.

Затем выполнил проверку с автоматическим исправлением тех ошибок, которые e2fsck может исправить без дополнительного решения администратора:


Команда echo $? показывает код завершения предыдущей команды. Проверять его нужно сразу после нужной операции.

Первый запуск сообщил recovering journal и завершился с кодом 1. Для e2fsck это означает, что ошибки файловой системы были исправлены.


Я восстановил журнал ext4 и получил код завершения 1.

Повторил ту же проверку на всё ещё размонтированном томе:


На этот раз результат был 0, без новых сообщений об исправлениях. Это подтверждало успешную проверку в тот момент, но не объясняло причину первоначального сбоя.


При повторной проверке я получил код 0, после чего продолжил диагностику из chroot.

Что показал SMART системного SSD​

После проверки ext4 я смонтировал корень в режиме ro,noload, подключил каталоги устройств и процессов и вошёл в chroot.

Если объяснять коротко, chroot позволил мне запускать программы установленной системы так, будто её смонтированный каталог является корнем. Отдельную копию данных эта операция не создаёт.

Для SSD, который в тот момент определялся как /dev/sdg, выполнил:


В выводе были:

• общая оценка PASSED;
• ноль переназначенных секторов;
• 13 834 часа работы и 39 включений;
• температура 28 °C;
• No Errors Logged в журнале ошибок;
• прежний короткий тест, завершившийся без ошибки на отметке 13 830 часов.

Я прочитал SMART ADATA SU650: пороговая оценка была PASSED.


В журнале не было зарегистрированных ошибок, прежний короткий тест завершился успешно.

Новый длительный тест я не запускал. Последующие ошибки I/O показали, почему нельзя делать вывод о полной исправности накопителя только по слову PASSED. Неисправность самого SSD, соединения, питания или контроллера я на этом этапе не локализовал.

Системные журналы и восстановление пароля root​

Я просмотрел список сохранённых сеансов системного журнала:


Здесь tail -n 5 только выводит последние пять строк и завершается. Это не постоянное наблюдение за журналом, как с параметром -f.

Запрос выбранного сеанса из chroot возвращал No entries. Я не стал трактовать это как отсутствие ошибок во всей системе. В доступных записях нашлись отказы SMTP-соединения у Postfix, а в dmesg — предупреждение GPT, относящееся в контексте вывода к /dev/sda. Таблицу разделов я не исправлял. Также встретились сообщения графического драйвера и bond0; их причины остались отдельной задачей.

Заодно я восстановил пароль root. После выхода из chroot и размонтирования временных подключений смонтировал системный том для записи, подключил /dev и /proc и выполнил:


Получил password updated successfully. Затем выполнил sync и размонтировал временные подключения и сам том.


Пароль root был изменён. На фотографии также видны последующие операции монтирования и размонтирования ext4.

На какое-то время PBS снова заработал​

В работающей системе я проверил тома, массив и службы:


Корень отображался как ext4 с параметрами rw,relatime,errors=remount-ro. Хранилище на /dev/md127 было подключено как XFS в режиме rw,relatime.

Для обеих служб я получил active. Интерфейс bond0 имел адрес 172.16.2.211/24 и состояние UP/LOWER_UP.


Я подтвердил доступность томов, рабочий сетевой интерфейс и активность двух служб PBS.

Параметр errors=remount-ro описывает поведение при ошибке: перемонтировать файловую систему только для чтения. Его присутствие рядом с rw не означает, что том уже находится в режиме ro.

Массив при этом оставался в составе 5/6. Успешный вход в веб-интерфейс, полную проверку резервных копий и тестовое восстановление я ещё не подтвердил.

Почему я не стал считать восстановление завершённым​

Через некоторое время ошибки ext4 появились снова. К сообщениям о прерванном журнале добавились:



После временного восстановления работы я снова получил ошибки журнала и записи ext4.

Сообщения шли прямо в консоль. Ctrl+C не помогал, потому что я останавливал команду в оболочке, а вывод ядра продолжался независимо от неё.

Освободить строку ввода удалось сочетанием Alt+SysRq+0. На экране появились Changing Loglevel и Loglevel set to 0. Затем я выполнил:


Так я уменьшил вывод сообщений ядра в консоль. Файловую систему это не исправляло — только давало возможность продолжить ввод команд.

Дальше ситуация стала серьёзнее. При попытке получить журнал команда dmesg уже не запускалась:


Аналогичная ошибка возникла для /usr/bin/realpath. Попытка остановить службы PBS через systemctl тоже не завершилась успешно: ошибка чтения появилась при запуске /usr/bin/systemd-tty-ask-password-agent.


Консоль стала доступна для ввода, но программы с системного тома начали завершаться с Input/output error.

Сохранённый журнал dmesg и успешную остановку служб я не получил. После этого считать сервер исправным было уже нельзя: проблема затрагивала чтение системных программ.

Можно ли сохранить старое хранилище после чистой установки PBS​

На этом этапе я рассмотрел переустановку системы на исправный SSD. Возник практический вопрос: смогу ли подключить старые резервные копии, если не сохраню настройки из /etc?

Для моей схемы потеря этих настроек сама по себе не означает потерю данных массива. Метаданные MD находятся на HDD, а содержимое datastore — на XFS. Но настройки системы придётся восстановить или создать заново.


Дальнейший порядок я наметил такой: сохранить то, что ещё читается с системного накопителя, разобраться с его подключением и состоянием, установить PBS на исправный накопитель, собрать существующий RAID и подключить прежнюю XFS. При установке систему нужно направить именно на системный диск, сохранив HDD массива. Для защиты от ошибки выбора я рассматривал их отключение на время установки при выключенном сервере.

Перед добавлением datastore я отдельно проверил бы через findmnt, что по нужному пути действительно подключён массив. Пустой каталог на системном SSD и каталог со смонтированной XFS могут называться одинаково, но это разное хранилище.

После подключения остались бы проверка прав доступа, клиентских подключений, резервных копий и пробное восстановление. При смене сертификата PBS потребовалось бы обновить доверие к серверу на клиентах.

Отдельно я должен сохранить ключи расшифрования, если резервные копии зашифрованы. Они обычно находятся на стороне клиента. Новая установка PBS не создаст ключ, которым можно расшифровать прежние копии.

До самой переустановки в этом цикле работ я не дошёл. Замену SSD, восстановление шестого участника RAID и проверку всех резервных копий тоже не выполнил.

Что я вынес из этой диагностики​

Доступ к существующему RAID6 и каталогам резервных копий я вернул. Журнал системного ext4 восстановил, пароль root изменил и на некоторое время получил работающие службы PBS. Но повторные ошибки ext4 и I/O оставили восстановление сервера незавершённым.

Для меня главным оказалось разделение уровней: физические диски, массив, файловая система и настройки PBS. Оно помогло не перепутать неисправность системного тома с состоянием хранилища резервных копий.

После этой истории я считаю восстановление завершённым только тогда, когда система работает стабильно, состав массива понятен, данные проверены и выполнено тестовое восстановление. Доступные каталоги, active у службы и один успешный fsck — полезные промежуточные результаты, но каждого из них по отдельности недостаточно.

Документация к использованным инструментам​

• mdadm: метаданные, сборка и режим только для чтения
• XFS: параметры монтирования, включая norecovery
• e2fsck: параметры проверки и коды завершения
• Proxmox Backup Server: хранилища и datastore
• Proxmox Backup Client: шифрование и ключи
• Linux SysRq: управление выводом сообщений ядра