Резервное копирование Revit и Vault: что бэкапить и как тестировать

Почему тут мало просто копировать папки

Когда речь заходит о резервном копировании Revit и Vault, первое желание простое: скопировать папку проекта на диск или в облако. Для одиночных файлов это иногда выручает. Но в BIM большая часть "жизни проекта" находится не в самих RVT, а вокруг них: в базах данных, индексах, настройках и правах доступа.

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

С Vault ситуация еще жестче. Vault - это не просто хранилище файлов, а система с базой данных, служебными компонентами и правилами. Если скопировать только папку с файлами, вы сохраняете "тело", но теряете "паспорт": историю версий, состояния, связи между объектами, маршруты согласования, индекс для поиска.

Чаще всего выпадают из бэкапа база данных Vault (метаданные, версии, связи), Filestore и поисковые индексы, настройки сервера и задания (например, Job Processor), права доступа и привязки к учетным записям, а также клиентские конфигурации и надстройки, которые меняют поведение проектов.

Чем опасен бэкап только папки проекта? Это видно сразу: поиск в Vault пустой, в проектах нет истории, ссылки на сборки "осиротели", а нужная версия модели не находится. Типичный сценарий: сервер упал, администратор восстановил файлы из копии, люди заходят в Vault и видят, что документы как будто "не существовали" или они без версий и атрибутов.

Хороший бэкап здесь - не "склад файлов", а снимок системы, который можно развернуть и проверить.

Revit: что бэкапить кроме самих RVT

Если ограничиться копированием папки с RVT, восстановление часто получается формально успешным. Но команда теряет связи, единые правила оформления и повторяемость данных. Revit живет не только в модели.

Сами модели все равно в центре. Для рабочих проектов сохраняйте центральные файлы и папки с автоматическими резервными копиями Revit (которые создаются при сохранении). Рабочие локальные копии обычно можно пересоздать из центральной модели. Иногда имеет смысл держать их короткое время как "снимок" для разборов, если после сбоя появились странные предупреждения или пропали элементы.

Дальше идут связи. У проекта может быть десятки подгруженных моделей, CAD-вставок, подложек, изображений и облаков точек. Если эти файлы лежат в разных местах, после восстановления модель откроется, но часть ссылок станет "не найдена", а виды и спецификации начнут вести себя иначе. Хорошая практика - держать связи рядом с проектом или хотя бы сохранять карту путей и структуру папок.

Чтобы после отката сохранилась логика проекта, отдельно сохраняйте то, что задает стандарты: шаблоны проектов (RTE) и типовые "стартовые" RVT, используемые библиотеки семейств и материалов, файл общих параметров (TXT) и таблицы keynotes, конфигурационные файлы и служебные справочники для спецификаций, а также надстройки и их настройки (если они влияют на экспорт, проверки и совместимость).

Не забывайте про рабочие места. Разные версии плагинов, разные шаблоны или потерянный файл общих параметров дают эффект "у меня поехали спецификации, а у коллеги нет". Мини-сценарий: восстановили RVT, но забыли общий параметр и таблицу примечаний - на следующий день половина спецификаций стала пустой, хотя модель "целая".

Vault: какие компоненты нужно сохранять

Для Vault опасно делать бэкап только папки с файлами. Vault состоит из файлового хранилища, базы данных и настроек. Потеря любой части ломает связи, историю и права.

1) Хранилище файлов (Filestore)

Это физические данные: модели, чертежи, вложения и служебные структуры Vault. Filestore - не просто "папка с проектами": внутри лежат версии и внутренние каталоги. Бэкап должен захватывать Filestore целиком, а не выбранные подпапки.

2) База данных Vault

SQL-база хранит то, что делает Vault "умным": карточки и свойства, версии, связи между файлами, историю, результаты поиска, статусы жизненного цикла. Если восстановить только Filestore без базы, вы получите набор файлов без контекста. Если восстановить базу без Filestore, вы увидите записи, которые указывают на отсутствующие данные.

В минимальный набор для сохранения обычно входят: Filestore (все тома и каталоги), SQL-базы Vault (и связанные экземпляры, если они используются), конфигурация (категории, шаблоны, свойства, жизненные циклы), учетные записи и права (группы, роли, интеграция с доменом), службы и задания (включая Job Processor и очереди, если они задействованы).

Короткий пример: после аварии восстановили Filestore и SQL, но забыли настройки и права. Сотрудники могут войти, но не видят привычные категории, не могут переводить файлы по жизненным циклам, а автоматические задания перестают выполняться.

Метаданные и связи: что исчезает при неполном бэкапе

Часто спасают только сами файлы. Их действительно можно открыть. Но система вокруг них может оказаться пустой, и вы теряете то, что делает работу управляемой: кто что утвердил, какие версии актуальны, где лежит исходник, а где производная.

В Vault основная ценность обычно не в DWG/IPT/RVT как таковых, а в данных, которые их описывают. Это свойства (карточки), статусы жизненного цикла, история версий, маршруты согласования и права доступа. Если вернуть только файловое хранилище, проект выглядит как набор документов без привычных атрибутов и контроля.

Сильно страдают зависимости. Пропадают связи между сборками и деталями, между моделью и семействами, между исходными файлами и публикациями. В результате пользователь видит файл, но не может быстро понять, откуда он взялся и что он тянет за собой. На практике это превращается в ручной поиск, ошибки с "не той" версией и потерю времени.

Чаще всего исчезают и болезненно восстанавливаются: свойства и пользовательские поля, статусы/ревизии и история утверждений, ссылки и зависимости (в какой версии что связано), индексы поиска, журналы и протоколы работы.

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

Журналы и протоколы редко считают частью бэкапа, но при инциденте они экономят часы. По ним можно понять, в какой момент начались ошибки, кто выполнял операции, и почему база и хранилище разъехались.

Корректно восстанавливается связка "база данных + Filestore + настройки/службы". Иначе вы получаете рабочие файлы без управляемости.

Где хранить и как часто делать копии

Важны две вещи: как часто вы делаете копии и где они лежат. Если выбрать только одно, страдает восстановление: либо теряете свежие изменения, либо копии недоступны в момент аварии.

Частоту удобно выбирать от того, сколько правок вы готовы потерять. Для BIM это обычно видно по темпу работы команды и по цене часа:

• Почасовой бэкап - когда в течение дня активно меняются модели и семейства.
• Ежедневный бэкап - когда допустимо откатиться на вчера.
• Копия по событию - перед крупными импортами, обновлением Vault, установкой плагинов, миграцией шаблонов Revit.

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

Хранение лучше разделять по уровням: данные Revit (центральные модели, семейства, шаблоны) отдельно от временных и локальных папок; данные Vault (Filestore и база) отдельно от экспортов; конфигурации и настройки - отдельно, чтобы их можно было быстро поднять и сравнить.

Правило 3-2-1 простыми словами: держите три копии, на двух разных типах хранилища, и одну копию вне основной площадки. "Вне площадки" спасает и от простых сбоев, и от шифровальщиков. Важно, чтобы хотя бы одна копия была изолирована: недоступна на запись обычным учетным записям и не смонтирована постоянно.

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

Пошагово: как настроить бэкап для Revit и Vault

Начните с инвентаризации. Для Revit это не только RVT и семейства, но и общие ресурсы: шаблоны, общие параметры, библиотеки, файлы конфигурации, а также то, что хранится на файловых шарах (например, исходники для подгрузок). Для Vault важно разделить "файлы хранилища" и "данные в базе": без базы вы теряете историю, связи, статусы, пользователей и правила.

Дальше определите, когда можно делать копии так, чтобы не ломать работу. Для Vault нужен согласованный режим: окно обслуживания или сценарий со снапшотами и заморозкой записи, чтобы база и Filestore не разъехались. Назначьте владельца процесса: кто следит за заданиями, кто получает уведомления об ошибках, кто принимает решение о запуске восстановления.

Практичный минимальный план:

• Составьте список объектов защиты (Revit: модели и библиотеки; Vault: Filestore, SQL-база, настройки, задания Job Processor, пользовательские скрипты/правила).
• Определите частоту и глубину: ежедневные инкрементальные и регулярные полные, плюс отдельные точки перед обновлениями.
• Договоритесь о структуре хранения и именах (дата, система, тип копии, окружение prod/test).
• Настройте проверку успешности: отчеты, уведомления, контроль размера копий и наличия всех компонентов.
• Зафиксируйте RPO и RTO простыми словами: "сколько данных можем потерять" и "за сколько вернемся в работу".

После настройки сделайте контрольную копию и сразу проверьте восстановление. Поднимите тестовый Vault на отдельной машине, восстановите туда базу и Filestore, затем откройте пару типовых проектов Revit привычным для команды способом.

Как тестировать восстановление, чтобы это работало в реальности

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

Какие сценарии прогонять

Выберите 3-4 ситуации, которые чаще всего случаются, и повторяйте их по расписанию (например, раз в квартал) и после крупных изменений:

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

Восстанавливайте не на боевом сервере. Поднимайте отдельное тестовое окружение (виртуальная машина или стенд) и туда развертывайте копию данных и базы.

Что проверять после восстановления

Один успешный запуск сервисов ничего не доказывает. Нужна проверка глазами пользователя и администратора:

• Вход под 2-3 ролями: админ, проектировщик, просмотр.
• Открытие и сохранение Revit-файлов, совместная работа (если используется).
• Vault: поиск, выдача/сдача, история версий, права на папки и файлы.
• Ссылки: Revit-связи, пути к семействам, внешние ссылки, публикации.
• Сверка цифр: число проектов, размер хранилища, количество версий и метаданных по выборке.

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

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

Пример: сбой на Vault-сервере в середине рабочего дня

Команда из 18 человек работает над двумя крупными объектами в Revit (по 3-6 ГБ каждый) и ведет библиотеку семейств через Autodesk Vault. Внутреннее требование: простой не больше 2 часов, потеря данных не больше 30 минут (RTO 2 часа, RPO 30 минут). Бэкап настроен, но восстановление до этого ни разу не проверяли.

В 11:40 пользователи видят одно и то же: Vault Client не входит, в Revit пропадает доступ к общим семействам, новые версии не создаются. У части сотрудников RVT открываются, но синхронизация с центральной моделью начинает выдавать ошибки из-за блокировок и отсутствия подтверждений версий.

Первое правило - остановить попытки "самопочинки". Дальше действуют по короткому плану:

• Остановить службы Vault и доступ к хранилищу, чтобы не усугубить повреждение.
• Зафиксировать время инцидента и выбрать точку восстановления по RPO (например, 11:15).
• Восстановить базу данных Vault и Filestore строго из одной точки.
• Вернуть настройки и идентичность сервера (имя, сертификаты, учетные записи служб), затем поднять службы.
• Дать доступ ограниченной группе для проверки, а не всей компании сразу.

Проверка занимает 20-30 минут, но решает исход. Открывают 2-3 контрольных проекта: смотрят права, историю версий, поиск по свойствам, выдачу файлов, корректность ссылок и зависимостей (семейства, шаблоны, общие параметры). Если метаданные "поехали", частая причина - база восстановлена из одной даты, а Filestore из другой.

Частые ошибки и ловушки

Главная ловушка в том, что резервное копирование кажется простым: скопировал папки и спокоен. Проблемы всплывают при восстановлении, когда времени уже нет.

Одна из самых частых ошибок - делать копию, пока Vault и связанные службы активно работают. В итоге часть файлов или база попадает в бэкап в разном состоянии: где-то уже записалось, где-то еще нет. Архив выглядит нормальным, а после восстановления появляются "битые" связи, пропавшие ревизии или ошибки индексов.

Вторая ловушка - сохраняют только модели и хранилище, но забывают окружение. В Revit это шаблоны проектов, общие параметры, файлы общих координат, семейства и библиотеки, настройки экспорта, а также скрипты и надстройки, от которых зависит выпуск документации. После аварии модели открываются, но команда не может выпускать листы или получать правильные спецификации.

Третья ошибка - не учитывать права и настройки доступа. Если восстановить данные без ролей, групп и правил Vault, пользователи либо теряют доступ, либо получают лишние права. Это риск для контроля изменений.

Еще одна типичная проблема - "бэкап есть, но мы его не проверяли". Тест откладывают, пока в один день не выясняется, что копия неполная или не читается, нет пароля/ключа шифрования, не сохранены зависимости, восстановление занимает в разы больше ожидаемого времени, всплывают конфликты имен и путей.

Отдельная ловушка - смешивать копии разных сред и версий (test/pilot/prod; разные релизы Revit/Vault) в одной структуре и без понятной маркировки.

Короткий чеклист для проверки бэкапа

Бэкап считается "живым" только если вы можете быстро ответить на три вопроса: что сохраняется, где лежит, как поднять завтра утром.

• Есть актуальный список того, что сохраняется для Revit и для Vault (проекты, шаблоны, семейства, настройки, базы, Filestore, служебные папки, журналы). После обновлений и смены путей список пересматривается.
• Понятно, где физически лежат копии (минимум два места) и кто имеет доступ. Доступ ограничен, действия логируются, ключевые пароли и ключи хранения не завязаны на одного человека.
• Зафиксированы RPO и RTO и они подтверждены практикой.
• Регулярно проводится тест восстановления в отдельной среде: поднимается Vault, подключается тестовый клиент, открываются несколько Revit-моделей, проверяются связи и права.
• Инструкция восстановления лежит в доступном месте и не устарела: кто запускает восстановление, в каком порядке, где брать дистрибутивы и как вернуть сервисы в работу.

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

Следующие шаги: как закрепить процесс и не забыть про тесты

Если бэкап живет только в голове администратора, он подводит. Закрепите процесс так, чтобы он работал и в отпуск, и при смене сотрудников.

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

Если не хватает ресурсов на стенд или нужна помощь с инфраструктурой под Vault и BIM, можно подключать системного интегратора. Например, GSE.kz (gse.kz) работает как производитель серверов и интегратор и может закрыть задачи по серверной платформе, настройке резервного копирования и поддержке 24/7, чтобы проверки не зависели от занятости одного специалиста.