Восстановление тела недавно измененного документа

Часто происходит так, что пользователь случайно внес изменения в документ или удалил чьи-то изменения или примечания в документе и нужно восстановить тело документа.

Тело документа можно восстановить из бэкапа, но может не оказаться бэкапа за нужное время, потому как документ может изменяться несколько раз в промежутке между бэкапами. Есть другой вариант, правда с ограничениями.

Схема работы сервиса хранилищ

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

1. Тела документов представляют собой blob-файлы с именем в виде идентификатора, например, «54a2ab5d-a861-4b32-9958-3735d87e9a6d.blob».
2. Сотрудник отредактировал содержимое документа (бинарные данные).
3. Измененные бинарные данные отправляются в сервис хранилищ.
4. Сервис хранилищ присваивает бинарным данным новый идентификатор.
5. Сервис хранилищ отмечает старые данные на удаление и фиксирует полученные бинарные данные по новому идентификатору. Отмеченные старые данные размещаются в папке deleted файлового хранилища и удаляются из нее автоматически через некоторое время, по умолчанию 3 дня. Время жизни устаревших бинарных данных можно настроить через конфигурационный файл config.yml в секции с параметрами Сервиса хранилищ, параметр OBSOLETE_DATA_LIFE_PERIOD (подробнее Настройки сервиса хранилищ).
6. Таким образом, даже если меняли одну и ту же версию документа несколько раз, то в папке deleted файлового хранилища некоторое время хранятся все измененные тела этой версии.

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

Ограничения

1. Восстановить документ получится, если документ был изменен в период, который указан в настройке OBSOLETE_DATA_LIFE_PERIOD.
2. Если в системе настроено шифрование, то нижеописанный способ не сработает.

Тела хранятся в папке файлового хранилища, но структура папок неочевидна, и по ИД документа/версии однозначно нельзя сказать, где лежит тело конкретной версии документа. Точнее, можно определить по идентификатору, но только актуальную версию документа с помощью sql запроса, но этот вариант нам не подходит.

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

По сути стоит задача найти идентификатор бинарных данных, помеченных на удаление:

1. Можно попробовать посмотреть содержимое папки deleted в папке файлового хранилища, и если там один файл, то просто берем этот идентификатор и переходим к пункту 3. Но сложность в том, что в этой папке может быть большое количество помеченных на удаление бинарных данных.

2. Определим идентификатор бинарных данных которые были помечены на удаление.

1. Найдем запись об изменении содержимого в истории документа и запомним дату, время и пользователя. Обратите внимание, что время в истории - это ваше локальное время, которое может отличаться от серверного. Далее поиск будет по лог-файлу, в котором все события фиксируются именно по серверному времени.
2. В лог-файле WebServer с помощью Directum Log Viewer и фильтра «Storage/Internal/Delete» найдем запись следующего вида:

   Span("durationMs": 5, "status": "Ok", "name": "Storage/Internal/Delete", "url": "http://localhost/Storage/Internal/Delete", "subtr": "1906b4d5-615c72", "identifiers": "[71cb98cc-231b-449f-8970-f03012be305a]")

   где 71cb98cc-231b-449f-8970-f03012be305a – это идентификатор бинарных данных помеченных на удаление.  Если найденных  записей несколько, то можно сузить поиск по пользователю.  

3. Запустим поиск в папке файлового хранилища по найденному идентификатору бинарных данных. Обратите внимание, что нас интересует файл не в папке deleted, а файл с расширением «blob». 
 

4. Далее копируем найденный файл в свою папку и меняем расширение blob на нужное, в моем примере это docx.

5. Документ восстановлен.