Новый PBS и старые резервные копии: как я вернул доступ к хранилищу

Я установил Proxmox Backup Server на новый SSD и подключил к нему прежнее хранилище на mdadm RAID6 с файловой системой XFS. Старые резервные копии снова появились в PBS, хотя файлов конфигурации от предыдущей установки у меня не было. Затем я восстановил полный состав массива из шести HDD и выполнил успешное тестовое восстановление.

Расскажу по порядку, как я проверил диски после установки, собрал массив, зарегистрировал datastore и настроил его автоматическое подключение. Затем покажу перенос сети на LACP из четырёх портов, добавление шестого HDD и проверку результата после завершения ребилда.

Статья обновлена 14 сентября 2026 года. Хранилище доступно и автоматически подключается после перезагрузки, сеть через bond0 работает. Завершение ребилда подтверждено: в RAID6 шесть активных участников, состояние clean, degraded = 0. Тестовое восстановление я выполнил — оно прошло успешно, всё работает.

Установка PBS на новый SSD и первый вход

Я начал с чистой установки PBS на отдельный SSD ADATA SU650 объёмом 240 GB. Помимо SSD в сервере определялись шесть HDD по 12 TB; их участие в массиве ещё предстояло проверить. После установки я вошёл в консоль сервера под root через SSH.

В новой системе у меня были такие параметры:

Параметр	Моя конфигурация
Имя сервера	pbs2
IP-адрес	172.16.2.211/24
Шлюз	172.16.2.1
Веб-интерфейс PBS	https://172.16.2.211:8007/
Основа установленной системы	Debian trixie
Системный SSD	ADATA SU650, серийный номер 2O172L15A5H9; в этой установке — /dev/sdc.
Корневой том	pbs-root в группе LVM pbs, файловая система ext4.

На первом этапе адрес находился на nic0. Объединением дополнительных сетевых портов я занялся после подключения резервных копий.

Что именно мне нужно было подключить

Прежнее хранилище было построено на программном RAID6 из шести HDD по 12 TB. Полезный размер массива составлял около 48 TB, или 43,66 TiB. Это один и тот же объём, представленный в десятичных и двоичных единицах.

Для себя я разделил три уровня:

mdadm собирает физические диски в одно устройство Linux MD.
XFS хранит на этом устройстве файлы. После монтирования они становятся доступны в каталоге Linux.
Datastore PBS — зарегистрированный в PBS каталог с резервными копиями. Я вернул ему имя Local_pbs2 и путь /mnt/Local_Storage.

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

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

Какие настройки пришлось создать заново

После переустановки у меня не было прежних файлов конфигурации. Я разобрался, за что отвечал каждый из них:

Файл или каталог	Что пришлось восстановить
/etc/proxmox-backup/	Описание datastore, пользователей, прав, токенов, заданий и других параметров PBS.
/etc/mdadm/mdadm.conf	Настройки сборки существующего массива.
/etc/fstab	Монтирование XFS в нужный каталог при запуске системы.
/etc/network/interfaces	Сетевые интерфейсы, IP-адрес, шлюз и bond.

Сами резервные копии хранились на HDD. Служебные записи mdadm тоже находились на дисках массива, поэтому отсутствие прежнего mdadm.conf не помешало их прочитать.

При этом подключение datastore не возвращает автоматически пользователей, API-токены, права доступа и расписания. Если копии зашифрованы на стороне клиента, для восстановления понадобится соответствующий ключ: регистрация каталога в PBS его не заменяет.

Инвентаризация после чистой установки

Я начал с двух команд:

Bash:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
cat /proc/mdstat

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

Устройство	Модель / серийный номер	Назначение на этом этапе
/dev/sdc	ADATA SU650, 2O172L15A5H9	Системный SSD. Корень / на pbs-root, swap и системные разделы.
/dev/sdb	WDC WD121VRYZ, D7G9SWMN	Участник RAID6, роль 3.
/dev/sdd	WDC WD121VRYZ, D7G9VZ3N	Участник RAID6, роль 5.
/dev/sde	Seagate ST12000NM002H, ZZ303HAN	Участник RAID6, роль 0.
/dev/sdf	Seagate ST12000NM002H, ZZ304R1X	Участник RAID6, роль 1.
/dev/sdg	WDC WD121VRYZ, D7G9PS4N	Участник RAID6, роль 2.
/dev/sda	WDC WD121VRYZ, D7G9PNEN	HDD со старыми разделами и группой LVM pve. В массив пока не входил.

Свежая установка PBS: пять HDD определяются как linux_raid_member, на отдельном HDD осталась прежняя разметка PVE. Утилита mdadm ещё отсутствовала.

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

Как я подключил репозиторий без подписки

При обновлении списка пакетов APT обращался к enterprise-репозиторию PBS и получал 401 Unauthorized. Подписки для него у меня не было.

Ошибка APT относилась к доступу к репозиторию. С состоянием HDD она не была связана.

Я отключил записи enterprise-репозитория и подключил pbs-no-subscription. В моей новой системе использовался Debian trixie. Файл /etc/apt/sources.list.d/pbs-no-subscription.sources содержал:

Код:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Перед изменением источников нужно посмотреть, в каких .sources или .list уже описан PBS, чтобы не создать дубликаты. Для deb822-файла .sources enterprise-запись можно отключить строкой Enabled: false в соответствующем блоке. Имена файлов могут отличаться.

Я сохранил проверку подписей пакетов. Репозиторий no-subscription доступен без ключа подписки; Proxmox рекомендует enterprise для production из-за более строгой проверки пакетов. Описание формата и репозиториев есть в документации PBS.

После изменения источников выполнил:

Bash:

apt update && apt install mdadm

APT успешно прочитал репозитории, mdadm версии 4.4-11 стал доступен. Предложение обновить остальные 123 пакета я на этом этапе не выполнял: полного обновления системы здесь не было.

Сборка существующего RAID6 только для чтения

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

Bash:

mdadm --examine /dev/sdb /dev/sdd /dev/sde /dev/sdf /dev/sdg

У них совпадали UUID массива, уровень RAID6, параметры размещения данных и счётчик Events. В этом проходе Events был равен 243, состояние — clean. Предусматривалось шесть ролей, но роль 4 отсутствовала.

UUID массива:

Код:

106f8678:4b7f3a20:7a35992a:2ecb82f6

После сопоставления метаданных я собрал именно этот существующий массив:

Bash:

mdadm --assemble --readonly --run \
  --uuid=106f8678:4b7f3a20:7a35992a:2ecb82f6 \
  /dev/md127 /dev/sdb /dev/sdd /dev/sde /dev/sdf /dev/sdg

cat /proc/mdstat
lsblk -o NAME,SIZE,FSTYPE,UUID,RO /dev/md127

Параметр --assemble собирает ранее созданный массив, --readonly ограничивает его чтением. В моей ситуации --run позволил запустить его с пятью доступными участниками. Режимы mdadm описаны в справке утилиты.

Результат:

Код:

mdadm: /dev/md127 has been started with 5 drives (out of 6).

md127 : active (read-only) raid6 sde[0] sdd[5] sdb[3] sdg[2] sdf[1]
        46875013120 blocks super 1.2 level 6, 256k chunk, algorithm 2 [6/5] [UUUU_U]

NAME   SIZE FSTYPE UUID                                 RO
md127 43.7T xfs    f7f2d40c-9d57-4e28-8bc5-45893a7e2ee4  1

Запись [6/5] означала пять активных участников из шести, а подчёркивание в [UUUU_U] — отсутствующую позицию. Массив работал в неполном составе. Это ещё не полное восстановление его отказоустойчивости.

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

Первое монтирование XFS и проверка каталогов

Для осмотра я создал временную точку монтирования:

Bash:

mkdir -p /mnt/pbs-recovery
mount -t xfs -o ro,norecovery /dev/md127 /mnt/pbs-recovery
findmnt /mnt/pbs-recovery
ls -la /mnt/pbs-recovery

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

Я снова увидел .chunks, vm, ct, .gc-status и .lock. Каталоги принадлежали пользователю backup. Я не менял владельца всех файлов рекурсивно и не удалял скрытые каталоги.

.chunks — это сами блоки данных резервных копий. Их структура описана в документации datastore. Наличие этой папки и каталогов снимков позволило продолжить подключение, но ещё не доказывало исправность каждого бэкапа.

Как я зарегистрировал прежнее хранилище в новой PBS

После осмотра я размонтировал временный каталог, разрешил запись на массив и подключил XFS по её UUID в прежний рабочий путь:

Bash:

umount /mnt/pbs-recovery &&
mdadm --readwrite /dev/md127 &&
mkdir -p /mnt/Local_Storage &&
mount -t xfs -o rw,relatime \
  UUID=f7f2d40c-9d57-4e28-8bc5-45893a7e2ee4 /mnt/Local_Storage

findmnt --mountpoint /mnt/Local_Storage
ls -la /mnt/Local_Storage

UUID файловой системы отличается от UUID массива. Первый нужен для монтирования XFS, второй — для сборки RAID. Их я не подменял друг другом.

Перед регистрацией проверил, что в рабочем каталоге смонтирована нужная XFS и действительно есть .chunks:

Bash:

test "$(findmnt -n -o UUID --mountpoint /mnt/Local_Storage)" = \
  "f7f2d40c-9d57-4e28-8bc5-45893a7e2ee4" &&
test -d /mnt/Local_Storage/.chunks &&
proxmox-backup-manager datastore create Local_pbs2 \
  /mnt/Local_Storage --reuse-datastore true

В результате получил:

Код:

Access time update check successful.
TASK OK

Ключ --reuse-datastore true указывает PBS использовать существующий каталог хранилища; его назначение подтверждает справка proxmox-backup-manager. Команда регистрировала datastore в новой установке, сохраняя прежние файлы.

Я проверил список:

Bash:

proxmox-backup-manager datastore list

В нём появился Local_pbs2 с путём /mnt/Local_Storage. После этого старые резервные копии стали видны и в веб-интерфейсе.

Автоматическая сборка и монтирование после перезагрузки

Ручного подключения было мало: я хотел, чтобы сервер сам находил хранилище при следующем запуске.

В новом /etc/mdadm/mdadm.conf уже была строка с правильным UUID:

Код:

ARRAY /dev/md/1 metadata=1.2 UUID=106f8678:4b7f3a20:7a35992a:2ecb82f6

Вторую запись для того же массива я не добавлял. Затем сохранил копию fstab и добавил монтирование XFS, проверив отсутствие такой записи:

Bash:

cp -a --backup=numbered /etc/fstab /etc/fstab.before-pbs-restore &&
if ! grep -qF 'UUID=f7f2d40c-9d57-4e28-8bc5-45893a7e2ee4' /etc/fstab; then
    printf '\n%s\n' 'UUID=f7f2d40c-9d57-4e28-8bc5-45893a7e2ee4 /mnt/Local_Storage xfs defaults,relatime 0 0' >> /etc/fstab
fi

Эта проверка подходила к моей исходной конфигурации без строки хранилища. Если такой UUID уже указан с другим путём или параметрами, существующую запись нужно проверить и исправить, а не добавлять ещё одну.

Я оставил relatime. PBS использует время доступа к блокам данных в работе сборщика мусора, поэтому отключение atime без понимания последствий здесь неуместно. Проверка обновления времени доступа при регистрации datastore у меня прошла успешно. Механизм описан в разделе о Garbage Collection.

Далее проверил таблицу монтирования, перечитал конфигурацию systemd и обновил initramfs:

Bash:

findmnt --verify --verbose &&
systemctl daemon-reload &&
update-initramfs -u -k all

findmnt сообщил о нуле ошибок и предупредил, что systemd ещё использует старую версию fstab. Следующий daemon-reload как раз перечитывал её. initramfs обновился без ошибки.

После перезагрузки выполнил:

Bash:

cat /proc/mdstat
findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS,UUID --mountpoint /mnt/Local_Storage
systemctl is-active proxmox-backup proxmox-backup-proxy
proxmox-backup-manager datastore list

Массив теперь назывался /dev/md1. Это соответствовало записи в mdadm.conf. UUID XFS остался прежним, она автоматически смонтировалась в /mnt/Local_Storage с параметром rw. Обе службы вернули active, а Local_pbs2 снова присутствовал в списке datastore.

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

Зачем мне понадобился bond из четырёх интерфейсов

После восстановления доступа я занялся сетью. Изначально адрес 172.16.2.211/24 и шлюз 172.16.2.1 находились на nic0. Четыре порта nic2, nic3, nic4 и nic5 я хотел объединить в bond0, чтобы несколько соединений могли распределяться между ними. nic1 оставался свободным.

Исходная сеть новой установки PBS: адрес находится на nic0, четыре дополнительных порта ещё не объединены.

Я сохранил конфигурацию и сначала создал bond в режиме balance-alb без переноса IP:

Bash:

cp -a --backup=numbered /etc/network/interfaces /root/interfaces.before-bond &&
proxmox-backup-manager network create bond0 --type bond \
  --bond_mode balance-alb --slaves nic2,nic3,nic4,nic5 \
  --method manual --autostart true &&
proxmox-backup-manager network changes

proxmox-backup-manager network reload

В /proc/net/bonding/bond0 все четыре порта показали 1000 Mbps, full duplex и MII Status: up. Однако после переноса IP доступ пропал.

Заранее поставленный пятиминутный таймер вернул прежнюю конфигурацию. В журнале я увидел применение сети в 15:48:09 и выполнение отката в 15:53:10. После этого адрес снова находился на nic0 и подключение восстановилось.

Я получил практическое подтверждение: наличие физического линка ещё не означает доступность нужной сети.

Как я проверял связь с коммутатором

Для проверки Ethernet-связности установил arping:

Bash:

apt install iputils-arping

Проба через bond0 ответа от шлюза не получила:

Bash:

arping -D -I bond0 -c 3 172.16.2.1

Та же проба через nic0 получила ответ. Обычный запрос через nic0 тоже отработал:

Bash:

arping -I nic0 -c 3 172.16.2.1

Ответивший шлюз имел MAC C4:36

A:A1:00:0D. Даже временное выделение nic5 из bond в отдельный интерфейс не дало ответа через этот порт; после проверки я вернул nic5 в bond0.

Здесь -D использовался для пробы с исходным адресом 0.0.0.0, поскольку на bond ещё не было IPv4. Это режим проверки дублирования адреса, а не обычный ping. Отсутствие ответа в такой проверке само по себе не доказывает, что адрес свободен или что причина точно в VLAN. Поведение параметров описано в справке arping.

Коммутатор у меня — RTT C310 48P 4XG. Для понимания настроек я посмотрел похожее руководство Raisecom ISCOM3000G(B), Release 05. Но команды другого семейства нельзя автоматически считать точным синтаксисом моего RTT, поэтому непроверенную настройку коммутатора в этот разбор я не включаю.

Почему у меня заработал LACP 802.3ad

Следующим я проверил режим 802.3ad с политикой layer3+4. Адрес на время проверки оставался на nic0:

Bash:

proxmox-backup-manager network update bond0 \
  --bond_mode 802.3ad --bond_xmit_hash_policy layer3+4 \
  --method manual

proxmox-backup-manager network changes
proxmox-backup-manager network reload
cat /proc/net/bonding/bond0

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

Код:

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up

Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 4
        Actor Key: 9
        Partner Key: 5
        Partner Mac Address: 00:0e:5e:6a:b9:c0

У nic2, nic3, nic4 и nic5 был один Aggregator ID: 2. Каждый порт показывал 1000 Mbps и full duplex. Повторная ARP-проба через bond0 получила ответ от прежнего шлюза.

Это подтвердило согласование LACP с партнёром на стороне коммутатора. Из такого результата нельзя делать вывод, что любой коммутатор автоматически настроится при создании bond в PBS: для 802.3ad требуется соответствующая конфигурация группы на обеих сторонах и доступ к нужной сети.

В моём случае balance-alb не обеспечил связь, а после перехода на LACP появились и согласованный агрегатор, и ответ шлюза. Точную причину отсутствия связи в предыдущем режиме без конфигурации портов коммутатора я не установил.

Чего я ожидал от четырёх портов по 1 Гбит/с: несколько соединений могут использовать разные линии. Один обычный TCP-поток остаётся ограничен одной линией; фактическую суммарную скорость ещё нужно измерить. Политика layer3+4 на PBS относится к исходящему трафику. Распределение входящих потоков выбирает коммутатор своим алгоритмом.

У layer3+4 также есть оговорка для смеси фрагментированных и нефрагментированных пакетов: возможно нарушение порядка, поэтому документация не считает эту политику полностью соответствующей 802.3ad. Эти ограничения я сверил с руководством Linux bonding.

Перенос IP с nic0 на bond0 с возможностью отката

Когда bond стал отвечать на ARP, я подготовил перенос адреса. Сначала сохранил рабочий вариант, в котором IP ещё находился на nic0, а bond уже использовал LACP:

Bash:

cp -a --backup=numbered /etc/network/interfaces /root/interfaces.before-lacp-ip &&
proxmox-backup-manager network update nic0 \
  --delete cidr --delete gateway --method manual --autostart false &&
proxmox-backup-manager network update bond0 \
  --method static --cidr 172.16.2.211/24 \
  --gateway 172.16.2.1 --autostart true &&
proxmox-backup-manager network changes

Команда network changes показывала подготовленные изменения. Я проверил их до применения. Перенос адреса может оборвать SSH, поэтому применение запускал отдельной службой systemd, а возврат предыдущего файла — таймером через пять минут:

Bash:

systemd-run --unit=pbs-lacp-rollback --on-active=5m \
  --timer-property=AccuracySec=1s \
  /bin/sh -c 'cp -a /root/interfaces.before-lacp-ip /etc/network/interfaces.new && proxmox-backup-manager network reload && arping -U -I nic0 -c 3 172.16.2.211' &&
systemd-run --unit=pbs-lacp-apply \
  /bin/sh -c 'proxmox-backup-manager network reload && ip link set dev nic0 down && arping -U -I bond0 -c 3 172.16.2.211'

В этой схеме arping -U отправляет объявление об адресе, чтобы соседние устройства обновили ARP-записи. Фоновая служба продолжает работать независимо от текущей SSH-сессии; создание такой службы и таймера описано в справке systemd-run. Сам таймер не гарантирует восстановление доступа при любой ошибке, поэтому локальная консоль всё равно полезна.

Я открыл новое SSH-подключение и проверил:

Bash:

ip -br address
ip route
arping -I bond0 -c 3 172.16.2.1

Адрес 172.16.2.211/24 и маршрут по умолчанию уже были на bond0. Шлюз ответил три раза из трёх, веб-интерфейс тоже работал.

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

Bash:

systemctl stop pbs-lacp-rollback.timer

В моём случае она вернула Unit not loaded. Я не стал записывать это как успешную отмену: к моменту проверки загруженного таймера с таким именем не было. Точную причину по имеющемуся выводу я не определил. Оставалось отдельно сверить текущую сеть и сохранённую конфигурацию.

Обнаружилась ещё одна деталь: nic0 уже был DOWN, но старый IPv4 на нём сохранился. Перевод интерфейса в DOWN сам по себе адрес не удаляет. Из-за неудачного stop в первоначальной цепочке с && следующая команда удаления вообще не выполнилась.

Я убрал остаточный адрес отдельным шагом, предварительно проверив его наличие на bond0:

Bash:

ip -4 -o address show dev bond0 | grep -qF 'inet 172.16.2.211/24 ' &&
ip address del 172.16.2.211/24 dev nic0

Теперь nic0 был DOWN без IPv4, а адрес и маршруты принадлежали bond0. Итоговый /etc/network/interfaces выглядел так:

Код:

auto lo
iface lo inet loopback

iface nic0 inet manual
iface nic1 inet manual
iface nic2 inet manual
iface nic3 inet manual
iface nic4 inet manual
iface nic5 inet manual

source /etc/network/interfaces.d/*

auto bond0
iface bond0 inet static
        address 172.16.2.211/24
        gateway 172.16.2.1
        bond-mode 802.3ad
        bond_xmit_hash_policy layer3+4
        bond-slaves nic2 nic3 nic4 nic5

network changes больше не показывал отложенных изменений. Работу сети в этом состоянии я подтвердил. Отдельную перезагрузку для проверки автозапуска именно новой конфигурации LACP на момент статьи ещё не выполнял.

Почему RAID6 всё ещё показывал пять дисков

После настройки сети я вернулся к составу массива:

Bash:

cat /proc/mdstat
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
mdadm --detail /dev/md1

В выводе было clean, degraded, пять активных устройств и пустая роль 4. Слово clean здесь не означало, что массив полностью исправен: рядом прямо указывался неполный состав — degraded.

Оставшийся HDD /dev/sda, WDC с серийным номером D7G9PNEN, содержал разделы и старую группу LVM pve. Новая PBS работала на /dev/sdc в группе pbs. Эти похожие имена я проверил особенно внимательно.

Перед любыми изменениями прочитал сигнатуры и состояние LVM:

Bash:

mdadm --examine /dev/sda
wipefs --no-act /dev/sda /dev/sda1 /dev/sda2 /dev/sda3
lvs -a -o lv_name,vg_name,lv_attr,lv_size,devices

Суперблока MD на /dev/sda я не обнаружил. На нём определялись GPT, FAT и LVM, а внутри pve — прежние системные тома и thin pool. Считать такой диск пустым только потому, что он не участвует в RAID, было бы ошибкой.

Я отдельно решил, что данные старой установки PVE на D7G9PNEN мне не нужны. Только после этого стал готовить этот HDD как замену отсутствующего участника. Данные пяти действующих участников и XFS-хранилище очищать не требовалось.

Что показала проверка HDD и почему SMART сначала пугал

Перед добавлением я проверил SMART диска D7G9PNEN. В доступных атрибутах были нулевые значения переназначенных, ожидающих переназначения и неисправимых секторов, а также счётчика CRC. Температура составляла около 30 °C, наработка — 21 361 час.

Короткий тест запустил так:

Bash:

smartctl -t short /dev/sda

После указанного утилитой ожидания прочитал результат:

Bash:

smartctl -l selftest /dev/sda

Он завершился без ошибки:

Код:

Num  Test_Description  Status                   Remaining  LifeTime(hours)
# 1  Short offline     Completed without error  00%        21361

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

После просмотра smartctl --scan-open стало видно, что диски доступны через MegaRAID. Для проверяемого HDD я получил информацию напрямую через найденный идентификатор контроллера:

Bash:

smartctl -i -H -d sat+megaraid,8 /dev/bus/0

Утилита подтвердила модель и серийный номер D7G9PNEN и объяснила ограничение:

Код:

SMART Status not supported: ATA return descriptor not supported by controller firmware
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

То есть именно этот запрос SMART Status ограничивала прошивка контроллера. PASSED был получен по атрибутам, а не по полноценному ответу команды статуса. Возможные способы доступа через контроллер описаны в справке smartctl. Значение megaraid,8 относится к моему обнаруженному устройству и не является универсальным номером диска.

Короткий тест HDD я не считал полной проверкой 12 TB поверхности. Длительный тест на этом этапе не запускался.

Как я подготовил шестой диск к добавлению

Чтобы не опираться только на букву sda, я нашёл постоянный путь по WWN:

Bash:

ls -l /dev/disk/by-id/ | grep -E 'D7G9PNEN|5000cca2dfc468a5'

Он указывал на нужный HDD:

Код:

/dev/disk/by-id/wwn-0x5000cca2dfc468a5 -> ../../sda

Я сопоставил WWN, серийный номер и размер 12 000 138 625 024 байта. Кроме того, проверил отсутствие смонтированных томов на этом устройстве, принадлежность /dev/md1 нужному массиву и его состояние: RAID6, шесть предусмотренных участников, один отсутствует.

Следующий блок удаляет прежнюю разметку конкретного HDD и добавляет его в массив. После начала восстановления RAID старое содержимое этого диска перезаписывается. Я выполнил его один раз для D7G9PNEN, заранее отказавшись от данных старой PVE. Для другого диска или массива эти значения не подходят. На уже добавленном участнике повторять подготовку не нужно.

Мой выполненный блок:

Bash:

(
set -euo pipefail

raid_disk=/dev/disk/by-id/wwn-0x5000cca2dfc468a5

test "$(lsblk -dn -o SERIAL "$raid_disk" | tr -d '[:space:]')" = "D7G9PNEN"
test "$(blockdev --getsize64 "$raid_disk")" = "12000138625024"
test "$(lsblk -dn -o FSTYPE "$raid_disk")" != "linux_raid_member"
test -z "$(lsblk -nr -o MOUNTPOINTS "$raid_disk" | tr -d '[:space:]')"

mdadm --detail --export /dev/md1 |
    grep -Fx 'MD_UUID=106f8678:4b7f3a20:7a35992a:2ecb82f6' > /dev/null

test "$(cat /sys/block/md1/md/degraded)" = "1"
test "$(cat /sys/block/md1/md/level)" = "raid6"
test "$(cat /sys/block/md1/md/raid_disks)" = "6"

umask 077
mdadm --detail /dev/md1 > /root/md1.before-add-D7G9PNEN.txt
vgcfgbackup -f /root/pve.before-add-D7G9PNEN.vg pve

vgchange -an pve

wipefs --all --backup --lock=yes \
    "${raid_disk}-part1" \
    "${raid_disk}-part2" \
    "${raid_disk}-part3" \
    "$raid_disk"

blockdev --rereadpt "$raid_disk"
udevadm settle

mdadm --manage /dev/md1 --add "$raid_disk"
)

Перед очисткой я сохранил описание массива и метаданные старой группы pve. Затем vgchange -an pve отключил её логические тома. Рабочую группу pbs эта команда не затрагивала.

wipefs убрал сигнатуры разделов и таблицы разделов выбранного HDD, после чего ядро перечитало разметку. Параметр --backup сохраняет копии удаляемых сигнатур, но это не резервная копия пользовательских данных. Аналогично vgcfgbackup сохраняет описание LVM, а не содержимое её томов. Назначение wipefs и его резервных файлов описано в справке утилиты.

Последняя команда добавила подготовленный диск в уже существующий /dev/md1. Я получил:

Код:

mdadm: added /dev/disk/by-id/wwn-0x5000cca2dfc468a5

Что означал вывод после добавления диска

Сразу после операции я проверил:

Bash:

cat /proc/mdstat
mdadm --detail /dev/md1

Вот фактическое начало восстановления:

Код:

md1 : active raid6 sda[6] sdd[5] sdg[2] sdf[1] sde[0] sdb[3]
      46875013120 blocks super 1.2 level 6, 256k chunk, algorithm 2 [6/5] [UUUU_U]
      [>....................] recovery = 0.0% (215424/11718753280)
      finish=7252.4min speed=26928K/sec

mdadm --detail уточнял:

Код:

State : clean, degraded, recovering
Raid Devices : 6
Total Devices : 6
Active Devices : 5
Working Devices : 6
Failed Devices : 0
Spare Devices : 1

Number   Major   Minor   RaidDevice State
     6       8       0           4  spare rebuilding /dev/sda

Диск уже был принят, но ещё не стал полностью восстановленным участником. Поэтому одновременно отображались шесть рабочих устройств, пять активных и spare rebuilding. Число 6 в sda[6] было внутренним номером устройства; его роль в RAID — 4. Седьмой HDD в массиве не появился.

Я восстанавливал отсутствующий участник, поэтому полезная ёмкость оставалась 43,66 TiB. Увеличения массива и расширения XFS здесь не происходило.

Начальная скорость составляла около 26 MiB/s. Первая оценка времени — примерно пять суток — появилась практически сразу после старта. Я не принял её за точный срок: она зависит от фактической скорости, нагрузки и хода восстановления.

Для наблюдения достаточно:

Bash:

watch -n 10 cat /proc/mdstat

Закрытие PuTTY или Ctrl+C в watch остановит просмотр, а не саму перестройку: восстановлением занимается ядро Linux. Состояния массива и показатели синхронизации описаны в документации Linux MD.

Во время ребилда для диагностики низкой скорости я рассматривал просмотр действующих ограничений:

Bash:

grep -H . /sys/block/md1/md/sync_speed_min /sys/block/md1/md/sync_speed_max

Этот запрос я оставил как возможный диагностический шаг; его результат и отдельный замер скорости в статье не приводятся. Завершение ребилда я подтвердил проверкой состояния массива, которую покажу дальше.

Ребилд завершён: RAID6 снова работает на шести дисках

14 сентября 2026 года я проверил массив и подтвердил, что восстановление шестого HDD завершилось. Для этого выполнил:

Bash:

cat /proc/mdstat
mdadm --detail /dev/md1
cat /sys/block/md1/md/degraded
findmnt --mountpoint /mnt/Local_Storage

В /proc/mdstat уже не было строки с ходом recovery. Массив показывал полный состав:

Код:

md1 : active raid6 sda[6] sdd[5] sdg[2] sdf[1] sde[0] sdb[3]
      46875013120 blocks super 1.2 level 6, 256k chunk, algorithm 2 [6/6] [UUUUUU]

Ключевые строки из mdadm --detail /dev/md1:

Код:

Raid Level : raid6
Array Size : 46875013120 (43.66 TiB 48.00 TB)
Raid Devices : 6
Total Devices : 6
State : clean
Active Devices : 6
Working Devices : 6
Failed Devices : 0
Spare Devices : 0
UUID : 106f8678:4b7f3a20:7a35992a:2ecb82f6

Number   Major   Minor   RaidDevice State
     0       8      64           0  active sync /dev/sde
     1       8      80           1  active sync /dev/sdf
     2       8      96           2  active sync /dev/sdg
     3       8      16           3  active sync /dev/sdb
     6       8       0           4  active sync /dev/sda
     5       8      48           5  active sync /dev/sdd

Команда чтения /sys/block/md1/md/degraded вернула:

Код:

Для себя я выделил несколько признаков завершения:

[6/6] — все шесть предусмотренных участников активны.
[UUUUUU] — в массиве больше нет отсутствующей позиции.
State : clean — в статусе больше нет degraded и recovering.
degraded = 0 — отсутствующих активных участников нет.
/dev/sda перешёл из spare rebuilding в active sync и занял роль 4.

Проверка findmnt подтвердила, что XFS на /dev/md1 по-прежнему смонтирована в /mnt/Local_Storage. UUID файловой системы сохранился: f7f2d40c-9d57-4e28-8bc5-45893a7e2ee4. Полезная ёмкость осталась прежней — 43,66 TiB.

Таким образом, я подтвердил завершение ребилда и восстановление полного состава RAID6. Шестой HDD стал обычным активным участником массива.

Тестовое восстановление: проверка результата на практике

Я также выполнил тестовое восстановление из прежнего хранилища, подключённого к новой установке PBS. Восстановление прошло успешно, результат работает.

Для меня это стало практическим подтверждением, что подключённые резервные копии можно использовать для восстановления. Проверку состояния RAID и пробное восстановление я зафиксировал отдельно: первая показывает состав массива, второе — результат работы с резервной копией.

Тестовое восстановление выполнено успешно. Полная проверка всех снимков через Verify — отдельная процедура; её результат в этом разборе не зафиксирован.

Итог: что я восстановил и проверил

После завершения ребилда и тестового восстановления я зафиксировал такие результаты:

Этап	Мой подтверждённый результат
PBS на новом системном SSD	Система установлена и работает.
Существующий RAID6 и XFS	Массив собран, XFS подключена по прежнему UUID.
Datastore Local_pbs2	Зарегистрирован с reuse-datastore, старые копии появились в интерфейсе.
Перезагрузка после подключения хранилища	Автоматическая сборка и монтирование подтверждены, службы PBS активны.
LACP на nic2–nic5	Четыре порта в одном агрегаторе, IP и маршруты на bond0, связь со шлюзом и доступ к PBS работают.
Шестой HDD	Короткий SMART-тест пройден. HDD добавлен в массив, ребилд завершён; /dev/sda работает как active sync в роли 4.
Полный состав RAID6	Подтверждён: `[6/6] [UUUUUU]`, шесть активных устройств, состояние clean, degraded = 0.
Тестовое восстановление	Выполнено успешно, результат работает.
Полная проверка всех копий через Verify	Отдельная процедура. Её результат в этом разборе не зафиксирован.

Для дальнейшей эксплуатации я оставил отдельный список задач:

Организовать регулярную проверку резервных копий через Verify и повторять тестовые восстановления. Проверка datastore описана в документации PBS.
Проверить подключение клиентов Proxmox VE: учётные записи, API-токены, права, отпечаток сертификата новой PBS, задания резервного копирования и уведомления.
Сохранить рабочие конфигурации PBS, mdadm, fstab и сети вне системного SSD. Отдельно сохранить используемые ключи шифрования.
В плановое окно проверить автозапуск LACP после перезагрузки и измерить распределение нагрузки между портами на нескольких соединениях.

Я подключил прежнее хранилище к PBS на новом SSD, подтвердил его автоматическое монтирование и восстановил полный состав RAID6. Все шесть HDD активны, ребилд завершён, сеть работает через LACP на nic2–nic5. Тестовое восстановление прошло успешно — всё работает.

Поиск

Поиск

Как я восстановил хранилище Proxmox Backup Server после переустановки

Установка PBS на новый SSD и первый вход

Что именно мне нужно было подключить

Какие настройки пришлось создать заново

Инвентаризация после чистой установки

Как я подключил репозиторий без подписки

Сборка существующего RAID6 только для чтения

Первое монтирование XFS и проверка каталогов

Как я зарегистрировал прежнее хранилище в новой PBS

Автоматическая сборка и монтирование после перезагрузки

Зачем мне понадобился bond из четырёх интерфейсов

Как я проверял связь с коммутатором

Почему у меня заработал LACP 802.3ad

Перенос IP с nic0 на bond0 с возможностью отката

Почему RAID6 всё ещё показывал пять дисков

Что показала проверка HDD и почему SMART сначала пугал

Как я подготовил шестой диск к добавлению

Что означал вывод после добавления диска

Ребилд завершён: RAID6 снова работает на шести дисках

Тестовое восстановление: проверка результата на практике

Итог: что я восстановил и проверил

Комментарии

Информация о статье

Ещё в Proxmox Backup

Ещё от Guru

Поделиться этой статьёй

Как я восстановил хранилище Proxmox Backup Server после переустановки

Установка PBS на новый SSD и первый вход​

Что именно мне нужно было подключить​

Какие настройки пришлось создать заново​

Инвентаризация после чистой установки​

Как я подключил репозиторий без подписки​

Сборка существующего RAID6 только для чтения​

Первое монтирование XFS и проверка каталогов​

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

Автоматическая сборка и монтирование после перезагрузки​

Зачем мне понадобился bond из четырёх интерфейсов​

Как я проверял связь с коммутатором​

Почему у меня заработал LACP 802.3ad​

Перенос IP с nic0 на bond0 с возможностью отката​

Почему RAID6 всё ещё показывал пять дисков​

Что показала проверка HDD и почему SMART сначала пугал​

Как я подготовил шестой диск к добавлению​

Что означал вывод после добавления диска​

Ребилд завершён: RAID6 снова работает на шести дисках​

Тестовое восстановление: проверка результата на практике​

Итог: что я восстановил и проверил​

Комментарии

Информация о статье

Ещё в Proxmox Backup

Ещё от Guru

Поделиться этой статьёй

Установка PBS на новый SSD и первый вход

Что именно мне нужно было подключить

Какие настройки пришлось создать заново

Инвентаризация после чистой установки

Как я подключил репозиторий без подписки

Сборка существующего RAID6 только для чтения

Первое монтирование XFS и проверка каталогов

Как я зарегистрировал прежнее хранилище в новой PBS

Автоматическая сборка и монтирование после перезагрузки

Зачем мне понадобился bond из четырёх интерфейсов

Как я проверял связь с коммутатором

Почему у меня заработал LACP 802.3ad

Перенос IP с nic0 на bond0 с возможностью отката

Почему RAID6 всё ещё показывал пять дисков

Что показала проверка HDD и почему SMART сначала пугал

Как я подготовил шестой диск к добавлению

Что означал вывод после добавления диска

Ребилд завершён: RAID6 снова работает на шести дисках

Тестовое восстановление: проверка результата на практике

Итог: что я восстановил и проверил