Администрирование · 11 мин
Как вернуть конфигурацию 1С: способы восстановления и отката изменений
Как вернуть конфигурацию 1С после неудачного обновления или ошибок: восстановление из архивной копии, загрузка dt и cf, откат изменений и проверка результата.
Необходимость вернуть конфигурацию 1С возникает после неудачного обновления, некорректной доработки, повреждения базы или случайного удаления объектов метаданных. В зависимости от ситуации восстановить можно как всю базу целиком, так и только конфигурацию без потери данных. Выбор способа определяется тем, что именно пострадало: данные, структура конфигурации или и то и другое.
Главное правило любого отката — наличие резервной копии, сделанной до проблемного изменения. Если копии нет, варианты существенно сужаются: остаются конфигурация поставщика, хранилище конфигурации и автоматические копии SQL-сервера. Поэтому первый шаг — не восстановление, а точная оценка того, что именно нужно вернуть.
Ниже разобраны основные сценарии: откат через загрузку dt-файла, восстановление только конфигурации из cf-файла, возврат к конфигурации поставщика, работа с хранилищем и действия в клиент-серверном варианте. Для каждого сценария указаны условия применения, риски и способ проверить результат.
Определите, что именно нужно вернуть
Под «возвратом конфигурации» пользователи обычно понимают три разные задачи. Первая — вернуть всю базу в состояние на определённый момент, включая данные и настройки. Вторая — вернуть только структуру конфигурации (объекты метаданных, модули, формы), сохранив текущие данные. Третья — откатить конкретное изменение, например ошибочную доработку одного документа или отчёта.
От ответа зависит инструмент. Загрузка dt-файла полностью заменяет базу — и данные, и конфигурацию. Загрузка cf-файла меняет только конфигурацию, при этом может потребоваться реструктуризация таблиц. Откат к конфигурации поставщика применим, только если база находится на поддержке и изменения не затрагивают структуру данных критичным образом.
Наличие копии до обновления и журнал ошибок конфигуратора
Дата последнего dt-файла или SQL-бэкапа
Наличие cf-файла или доступ к хранилищу конфигурации
Конфигурация поставщика, дистрибутив, копии на SQL-сервере
Подготовьтесь: обязательные шаги перед откатом
Перед любым восстановлением сделайте копию текущего состояния базы, даже если она «сломана». Проблемная база может содержать данные, введённые после последней архивной копии, и их потеря обернётся большим ущербом, чем сама поломка. Для файловой базы достаточно скопировать каталог с файлом 1Cv8.1CD или выгрузить dt через конфигуратор, если он открывается.
Завершите работу всех пользователей и установите блокировку сеансов. В клиент-серверном варианте это делается через консоль кластера или параметр блокировки в свойствах информационной базы. Восстановление при активных сеансах либо не выполнится, либо приведёт к рассогласованию данных.
Верните базу полностью через загрузку dt-файла
Это самый надёжный способ, когда нужно вернуть и конфигурацию, и данные на момент создания копии. Откройте базу в режиме конфигуратора, перейдите в меню «Администрирование» → «Загрузить информационную базу» и укажите путь к dt-файлу. После загрузки конфигуратор предложит перезапустить сеанс.
Учитывайте ограничения метода. Загрузка dt в клиент-серверной базе может занимать значительное время на больших объёмах, а на некоторых конфигурациях с большими таблицами выгрузка и загрузка dt в принципе не рекомендуются как основной механизм — там корректнее использовать средства СУБД. Также dt-файл не переносит настройки хранилища конфигурации и регистрацию базы в кластере.
- 1Создайте копию текущего состояния базы и завершите сеансы пользователей
- 2Откройте базу в конфигураторе монопольно
- 3Выберите «Администрирование» → «Загрузить информационную базу» и укажите dt-файл
- 4Дождитесь завершения загрузки и перезапустите конфигуратор
- 5Запустите базу в режиме предприятия и проверьте ключевые данные и отчёты
Верните только конфигурацию без потери данных
Загрузка конфигурации из cf-файла
Если данные актуальны, а испорчена только конфигурация, используйте «Конфигурация» → «Загрузить конфигурацию из файла». Потребуется cf-файл нужной версии — его можно выгрузить из копии базы, получить от разработчика доработки или взять из дистрибутива поставщика, если релиз совпадает.
После загрузки выполните обновление конфигурации базы данных (клавиша F7). Если в новой версии конфигурации изменилась структура объектов, запустится реструктуризация таблиц — на больших базах она может занять продолжительное время. Не прерывайте процесс: прерванная реструктуризация — частая причина повреждения базы.
Возврат к конфигурации поставщика
Если база на поддержке и изменения нужно просто снять, откройте «Конфигурация» → «Поддержка» → «Настройка поддержки» и используйте опцию возврата к конфигурации поставщика. Этот способ подходит, когда доработки не меняли структуру данных: добавленные вручную реквизиты и объекты при откате будут удалены, и данные в них пропадут.
Используйте хранилище конфигурации для точечного отката
Если разработка велась через хранилище конфигурации, откат сводится к получению нужной версии. В конфигураторе откройте «Конфигурация» → «Хранилище конфигурации» → «Открыть», найдите в истории версию до проблемного изменения и получите её в базу. Можно получить как всю конфигурацию целиком, так и отдельные объекты конкретной версии.
Точечный откат удобен, когда ошибочна одна доработка, а остальные изменения терять нельзя. Выберите объект в дереве конфигурации, откройте его историю в хранилище и откатите к предыдущей версии. Учтите: если объект связан с другими доработками, откат может нарушить их работу — после получения версии проверьте конфигурацию на корректность.
Сравнение способов восстановления
Возвращает и данные, и конфигурацию. Подходит при полном откате, но затирает всё текущее содержимое базы
Меняет только конфигурацию, данные сохраняются. Требуется cf нужной версии и реструктуризация
Быстрый откат доработок на типовой базе. Удаляет все изменённые и добавленные объекты
Точечный откат до любой версии. Работает только если разработка велась через хранилище
Оптимален для больших клиент-серверных баз. Требует доступа к SQL-серверу и навыков администрирования
Особенности для клиент-серверного варианта
В клиент-серверной архитектуре основной инструмент резервного копирования — средства СУБД: для MS SQL Server это полные и разностные бэкапы, для PostgreSQL — pg_dump или физические копии. Восстановление выполняется на стороне сервера баз данных, после чего база подключается к кластеру 1С без изменения регистрации.
Преимущество этого пути — скорость и возможность восстановления на конкретный момент времени при модели полного восстановления (full recovery model) с копиями журнала транзакций. Если администрированием СУБД занимается отдельный специалист, согласуйте с ним точку восстановления: данные, введённые после неё, будут потеряны.
Проверьте результат после восстановления
После отката выполните тестирование и исправление базы в режиме проверки логической и ссылочной целостности — особенно если восстановление проходило с реструктуризацией. Затем запустите базу в режиме предприятия и откройте ключевые формы: журналы документов, основные отчёты, справочники, которые затрагивала проблема.
Сверьте контрольные цифры: обороты по счетам, остатки на складах, суммы взаиморасчётов на дату восстановления. Если восстанавливалась полная копия, попросите пользователей проверить наличие последних документов и при необходимости внесите недостающие вручную или перенесите из копии проблемной базы обработкой.
Как проверить результат
База открывается без ошибок, сеансы стартуют
Ошибки инициализации, требование обновления конфигурации БД
Соответствует целевой версии в сведениях о конфигурации
Осталась проблемная версия или смешанное состояние
Цифры совпадают с ожидаемыми на дату копии
Расхождения в остатках и оборотах
Проверки завершаются без ошибок
Ошибки ссылочной целостности, битые ссылки
Частые вопросы
Можно ли вернуть конфигурацию 1С, если резервной копии нет?
Да, но с ограничениями. Если база на поддержке — вернитесь к конфигурации поставщика или загрузите cf из дистрибутива нужного релиза. Если велась разработка через хранилище — получите нужную версию оттуда. Данные при этом не откатить, восстанавливается только структура конфигурации.
Чем отличается загрузка dt от загрузки cf?
Файл dt содержит всю информационную базу: и данные, и конфигурацию — его загрузка полностью заменяет содержимое базы. Файл cf содержит только конфигурацию, поэтому данные сохраняются, но при изменении структуры объектов потребуется реструктуризация таблиц.
Что делать, если обновление конфигурации завершилось с ошибкой и база не открывается?
Не пытайтесь повторно запускать обновление. Сделайте копию текущего состояния файловой базы или SQL-бэкап, затем восстановите копию, сделанную до обновления, и разбирайте причину ошибки уже на тестовой базе. Повторное обновление выполняйте только после устранения причины сбоя.
Пропадут ли данные при возврате к конфигурации поставщика?
Данные типовых объектов сохранятся. Но объекты, добавленные вручную при доработке (новые справочники, регистры, реквизиты), будут удалены вместе с содержащимися в них данными. Перед откатом выгрузите такие данные или согласуйте их перенос.
Как откатить только одну ошибочную доработку, а не всю конфигурацию?
Если используется хранилище конфигурации — откатите конкретный объект к предыдущей версии через историю хранилища. Без хранилища вариант один: взять cf-файл рабочей версии, сравнить конфигурации и перенести исправленный объект вручную через сравнение и объединение.
Можно ли восстановить базу на конкретный момент времени, а не на дату копии?
Да, но только в клиент-серверном варианте при настроенной модели полного восстановления в СУБД и наличии копий журнала транзакций. Администратор баз данных может восстановить базу на произвольную точку времени. В файловом варианте такая возможность отсутствует — доступен только откат к дате последней копии.
Что важно запомнить
Перед откатом всегда копируйте текущее состояние базы и завершайте сеансы пользователей. Полный возврат делайте через dt или бэкап СУБД, откат только конфигурации — через cf, конфигурацию поставщика или хранилище. После восстановления обязательно проверьте базу тестированием и сверкой контрольных данных.