Что это значит

Начиная с версии 25.2 в Directum RX есть фоновый процесс «Проверка целостности данных сервисов хранилищ». По умолчанию он включён и запускается раз в неделю, в ночь на воскресенье. Процесс проходит по ссылкам на содержимое (тело версии документа, его представление с отметкой об ЭП) и проверяет, есть ли эти данные в хранилище.

Если чего-то не хватает, процесс формирует отчёт в CSV и отправляет менеджеру системы задачу на восстановление данных. Отсюда и сообщение в заголовке. Отчёт открывается из карточки хранилища по кнопке Результаты диагностики. Новый отчёт заменяет предыдущий, а невыполненная старая задача прекращается.

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

Как проверить

  1. Открыть отчёт и посмотреть два столбца: «Временный» и «Найден». - «Временный: Да, Найден: Да» означает, что сохранение не завершилось. Такие данные система удаляет сама через некоторое время, обычно это прерванная загрузка. - «Временный: Нет, Найден: Нет» означает, что ссылка в базе есть, а данных в хранилище нет. Это и есть потеря.
  2. Отсортировать потерянные версии по дате изменения. Картина почти всегда подсказывает причину: - все версии после определённой даты: хранилище в эти дни было недоступно, переполнено или писалось не туда, например во время переноса; - все версии до определённой даты: базу восстановили из более свежей копии, чем хранилище, или хранилище из более старой; - разрозненные версии за долгий срок: сбои диска, ручная чистка каталогов или бакета, неудачная синхронизация реплик.
  3. По столбцу «Путь» или по ИД бинарных данных проверить, нет ли файла в хранилище на самом деле: в каталоге файлового хранилища или в бакете S3. Если файл есть, но в другом месте, хранилище в карточке настроено не на тот путь или бакет.
  4. Посмотреть журналы сервиса хранилищ за даты изменения потерянных версий: ошибки записи, отказы S3, нехватка места.

Что сделать

  1. Если файлы нашлись в другом месте, вернуть их по нужному пути или поправить настройки хранилища, затем дождаться следующей проверки или запустить процесс вручную.
  2. Если потеря после переноса хранилища, докопировать недостающее из старого места. Как переносить бакет без простоя и сверять результат, разобрано в статье Перенос бакета S3 при работающей RX.
  3. Если хранилище и база восстанавливались из разных копий, достать недостающие файлы из резервной копии хранилища по путям из отчёта.
  4. Если данных нет нигде, по отчёту видно, какие документы и версии пострадали. Их авторов просят загрузить версии заново, а пустые версии помечают, чтобы ими не пользовались.
  5. На будущее: делать резервные копии базы и хранилища согласованно, в одно окно, и проверять восстановление обоих вместе. Подробнее в статье Бэкап RX на PostgreSQL: что считать бэкапом.

Отключать фоновый процесс, чтобы задачи перестали приходить, не стоит. Потери от этого не исчезнут, их просто перестанет быть видно.