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

В таблице групп найдите бейдж статуса:

Смена избыточности (R) запускает перераспределение данных: при увеличении R существующие копии докладываются на дополнительные узлы; при уменьшении R избыточные копии не удаляются автоматически (R-кратность при этом обеспечивается). Если перераспределение уже идёт в момент изменения R, оно перезапускается с учётом нового значения. | Авария | живых узлов меньше требуемой избыточности; запись в группу блокируется | | Требуется перераспределение | запланировано перераспределение данных (после добавления или удаления узла, изменения избыточности) | | Идёт перераспределение | перераспределение выполняется; писать в группу можно, идёт перенос чанков |

Проверка целостности — глубокая: берутся все актуальные объекты группы из БД (письма и вложения) и для каждого проверяется наличие и целостность всех его чанков (корневые meta_hash/content_hash/attachment_meta_hash + вложенные body-чанки из meta-чанка + чанки содержимого вложений) на каждом узле, где этот чанк должен находиться согласно избыточности (R) и кольцу хеширования. Это покрывает все 7 статусов и не даёт ложных срабатываний на «орфанных» чанках (не привязанных к письмам).

1. В строке группы выберите действие [deep health(!)] (иконка сердцебиения).
2. В открывшемся окне выберите:
   • Узел-координатор — узел кластера, на котором выполнится проверка. Любой узел (не обязан быть узлом хранилища): координатор проверяет узлы хранилища группы по сети.
   • Пересчитать и проверить контрольные суммы S3 (только для S3-групп) — если включено, для S3-объектов выгружаются байты и сверяется blake3(ciphertext) с эталоном в метаданных объекта. Это использует трафик и токены доступа к S3. Без галочки проверяется только наличие объектов (HEAD-запрос).
3. Проверка выполняется в фоне на координаторе:
   • локальные узлы: координатор вызывает POST /verify(!)-integrity на каждом ожидаемом узле — узел локально сверяет blake3(on-disk) == encrypted_block_hash (байты не передаются по сети);
   • S3-узлы: HEAD (наличие) + опционально GET+blake3 (целостность);
   • для каждого чанка агрегируется результат по всем R копиям → 7-статусная модель (S1–S7).
4. Результат виден в разделе [Задачи] — в состоянии задачи: chunks_total (проверено чанков), corrupt (повреждено на узле), missing (утрачено на узле), lost (потеряно на всех R — безвозвратно).
5. Откройте [Настройки → Целостность]. На странице показан полный список проблем: затронутые письма и вложения (по chunk_hash → join(!) emails.messages / emails.attachments), статусы S1–S7 и узел-донор с исправной копией. Состояния corrupt и missing на отдельном узле можно восстановить с донора через data-heal(!). Состояние referenced_lost означает, что исправной копии не осталось; восстановите данные повторным импортом из источника.

Deep-health запускается вручную; автоматически он не выполняется. Во время активной перебалансировки/вывода узла (drain(!)) проверка не фиксирует инциденты — чанки перемещаются, missing на заполняемом узле временен. Найденные проблемы сохраняются в audit.integrity_issues (status open/healed) — переживают рестарт, видны в разделе [Целостность]; data-heal(!)/реимпорт закрывают их (healed).

7 статусов: S1 — повреждён, есть донор (восстановимо); S2 — повреждён, донора нет (окончательно); S3 — утерян на узле, есть донор (восстановимо); S4 — утерян, донора нет (окончательно); S5 — утерян на всех R, найден донор вне группы (после сканирования резервной копии); S6 — утерян на всех R, есть recovery-признаки (повторный импорт возможен); S7 — утерян на всех R, источник неизвестен (SMTP, безвозвратно).

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

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