Ситуация.
Имеется хранилище. Ведется разработка группой программистов. Хранилище бэкапится каждый день с глубиной в 14 дней.
В определенный момент, оказывается что хранилище повреждено. Выявить удалось случайно, при попытке открыть конфигурацию на определенную версию. При этом и сравнить основную конфигурацию с версией хранилища не представляется возможным. Последний раз сравнение делали более месяца назад. Как следствие, все бэкапы уже содержат битое хранилище. Новые версии в хранилище создаются. Можно захватывать объекты.

Вопрос.
Как проверять работоспособность хранилища находящегося в бэкапе автоматически?

(0) А пробовали кэш чистить? У меня такая проблема была, когда, при работе с хранилищем, комп вырубался. При последующем подключении выдавал, что хранилище повреждено и слал лесом. В итоге чистишь кэш, тебя заново просят прописать путь до хранилища и все норм подключается.

У вас хранилище скульное, или файловое?

(2) Скульное хранилище? Как его сделать? Где про это почитать?

(1) Кэш чистился. Проверялось на разных базах. На разных компьютерах. Даже, специально поставил последнюю версию платформы, мало-ли. Но не помогло.

(2) >> хранилище скульное, или файловое?

Хранилище не бывает скульным. Хранилище всегда представляет из себя 1С-овскую базу данных в файловом формате и файлом с расширением 1CD.
Подключаться к хранилище можно либо напрямую, либо через специальную службу - сервер хранилища.
При совместной разработке предпочтительнее и надежнее второй вариант. В частности решает проблемы при сбоях из-за нестандартного отключения клиентов (вырубился свет) в момент работы с хранилищем, или при одновременном доступе к хранилищу двух и более разработчиков.

(3) не знаю про скульное хранилище, но точно есть проблемы с хранилищем через файл-шару.
для этого 1с даёт костыль - Сервер хранилища конфигураций.

(4) Попробуйте утилиту chldbfl с файлом 1CD хранилища. Не факт что поможет, но можно попытаться.
Разумеется на копии.

обзор технологии тут https://its.1c.ru/db/v837doc#bookmark:dev:TI000001120

(8) (6) я это и имел в виду)

(7) Пробовал. Ошибок нет.
(6) Про сервер хранилища знаю. По сути, спасает только от одной ситуации - когда разработчики пытаются войти с разными платформами. Ну и хорошо когда разработчики за периметром безопасности.
(5) Причины возникновения ошибок тоже понятны.

Вопрос - "Как автоматически проверять работоспособность хранилища"?
Автоматически я могу развернуть хранилище из бэкапа. Могу подцепить его к базе. Как узнать что хранилище рабочее?

(0) >>  Как проверять работоспособность хранилища находящегося в бэкапе автоматически?

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

(10) скриптом в пакете запускаешь где-нибудь копию базы, подключаешься к хранилищу и строишь отчет, сравниваешь последнюю версию с версией + 100 (или рандомное число больше 10).
ключики https://its.1c.ru/db/v838doc#bookmark:adm:TI000000499

За два года работы в компании хранилище дважды глючило.
Один раз пересоздали.
Другой раз просто обновили с подчиненной базы. Все решилось.
Мы не проверяем хранилище глючное или нет. Просто чаще вовремя обновляем.
И боевая база от хранилища не отстает. Если Хранилище ломается то каждый сохраняет себе то что у него наработано потом после обновление хранилища накатывает и все.

(11) зачем это делать в копии хранилища, если оперативнее будет проверять это на рабочем экземпляре? всё равно подключить можно любую базу (а можно выполнять эти операции без подключения).

(14) >> зачем это делать в копии хранилища, ...?

Потому что задача стоит - проверить работоспособность бекапа, а не рабочего хранилища.
Рабочее хранилище может быть вполне работоспособным. Но если был сбой при выполнении бекапа (отдельный вопрос - каким именно способом этот бекап делается и как гарантируется монопольный доступ в момент бекапа), то бекап может оказаться неработоспособным.

В любом случае не стоит пренебрегать сохранением конфигурации рабочей базы данных в файл cf после каждого коммита и обновления изменений в продуктиве.
При современной себестоимости мегабайта не так уж и дорого держать историю хоть за 10 лет.

(12) Спасибо. Не видел ранее там возможности обновиться из хранилища до нужной версии. Буду пробовать именно такой способ с последующим анализом версии конфигурации полученной в результате обновления.

(15) согласен, посыл в (0) был именно такой, но фактически, ему нужно проверять боевой конфиг, чтобы оперативно отреагировать на проблему.
консистентность бэкапа - это тема для второго разговора.