Проверка состояния хранилищ

Состояние группы показывает, достаточно ли доступных узлов для заданной избыточности и требуется ли перераспределение данных.

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

Запустите глубокую проверку целостности

Глубокая проверка проходит по всем актуальным объектам группы из базы данных — письмам и вложениям — и проверяет все связанные с ними чанки на каждом узле, где они должны находиться согласно R и кольцу хеширования.

Проверяются:

• корневые meta_hash, content_hash и attachment_meta_hash;
• чанки тела, перечисленные в мета-чанке;
• чанки содержимого вложений.

Чанки-сироты, которые не связаны с письмами, в эту проверку не входят.

1. В строке группы выберите [deep health] (!).
2. В открывшемся окне укажите [Узел-координатор]. Это может быть любой узел кластера: ему не обязательно выполнять роль хранилища.
3. Для S3-группы при необходимости включите [Пересчитать и проверить контрольные суммы S3]. В этом режиме система загружает байты объектов и сравнивает blake3(ciphertext) с эталоном из метаданных. Это увеличивает S3-трафик и требует доступа к объектам. Если параметр выключен, выполняется только проверка наличия объектов через HEAD.
4. Запустите проверку.

Проверка выполняется в фоне:

• для локальных узлов координатор вызывает POST /verify-integrity; каждый узел локально сравнивает blake3(on-disk) с encrypted_block_hash, поэтому сами байты по сети не передаются;
• для S3 выполняется HEAD, а при включённой проверке контрольных сумм — также GET и расчёт BLAKE3;
• результат по каждому чанку агрегируется по всем R копиям и переводится в один из семи статусов S1–S7.

Проверьте результат

Откройте [Задачи] и найдите задачу проверки. В её состоянии доступны показатели:

• chunks_total — число проверенных чанков;
• corrupt — число повреждённых копий;
• missing — число отсутствующих копий;
• lost — число чанков, для которых не осталось ни одной из R копий.

Затем откройте [Состояние системы] → [Целостность данных]. Здесь отображаются затронутые письма и вложения, статус S1–S7 и, если он существует, узел-донор с исправной копией. Связь с объектами архива определяется по chunk_hash и таблицам emails.messages / emails.attachments.

Состояния corrupt и missing для отдельной копии можно исправить восстановлением с узла-донора (data-heal (!)). referenced_lost означает, что исправной копии не осталось. Если исходное письмо ещё доступно и проблема имеет статус S6, выполните восстановление утраченных данных с источника.

Статусы S1–S7

Глубокая проверка по умолчанию запускается вручную. Автоматический запуск можно настроить через API расписаний задач с типом storage.deep_health; проверьте параметры в Swagger установленной версии. Кнопка расписания почтового источника настраивает сбор писем, а не проверку хранилища.

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

Найденные проблемы сохраняются в audit.integrity_issues со статусом open или healed и остаются доступными после перезапуска. Восстановление с донора или повторный импорт переводят исправленную запись в healed.

Связанные материалы

• Восстановление утраченных данных с источника
• Автоматическое восстановление реплик

Навигация по книге

• Следующая статья: Реакция на пропажу узла хранения