Как вернуть базу 1С после сбоя или удаления

Вернуть базу 1С можно несколькими способами: загрузить файл выгрузки .dt через конфигуратор, восстановить резервную копию средствами СУБД, откатить файловую базу из копии каталога или вернуть данные средствами самой платформы после неудачного обновления. Выбор метода зависит от того, в каком режиме работает база — файловом или клиент-серверном — и какие копии у вас есть на руках.

Главное правило перед любыми действиями: не работайте с единственной копией данных. Сначала скопируйте текущее состояние базы (даже повреждённой) в отдельный каталог, и только потом приступайте к восстановлению. Если что-то пойдёт не так, у вас останется исходное состояние для повторной попытки или обращения к специалисту.

Определите ситуацию: что именно случилось с базой

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

Если база просто пропала из списка в окне запуска 1С, сама информационная база, скорее всего, цела — удалена только запись о пути к ней. В этом случае достаточно заново добавить базу в список, указав путь к каталогу (для файловой) или параметры сервера (для клиент-серверной). Никакого восстановления данных при этом не требуется.

Подготовка: что сделать до восстановления

Любое восстановление базы — операция с риском, поэтому подготовка обязательна. Первый шаг — сохранить текущее состояние. Для файловой базы скопируйте весь каталог базы в надёжное место. Для клиент-серверной сделайте резервную копию средствами СУБД или выгрузите .dt через конфигуратор, если база ещё открывается.

Второй шаг — убедиться, что с базой никто не работает. Восстановление при активных сеансах может привести к несогласованным данным. Завершите сеансы пользователей через консоль кластера или попросите всех выйти из программы, а для серверной базы установите блокировку сеансов.

Третий шаг — проверьте наличие и целостность резервных копий. Откройте каталог с копиями, убедитесь, что файлы .dt или бэкапы SQL имеют ожидаемый размер и дату. Копия нулевого размера или с очень старой датой — сигнал, что план восстановления нужно пересмотреть.

Способ 1. Восстановление из файла выгрузки .dt

Файл .dt — универсальный формат выгрузки информационной базы, который содержит и данные, и конфигурацию. Это самый распространённый способ вернуть базу, если регулярно делались выгрузки через конфигуратор или по расписанию.

Порядок действий одинаков для большинства версий платформы 1С:Предприятие 8.3. Откройте конфигуратор нужной базы (если база повреждена — создайте новую пустую базу в списке и откройте её конфигуратор). В меню выберите «Администрирование» → «Загрузить информационную базу» и укажите путь к файлу .dt. Платформа предупредит, что текущие данные будут замещены — подтвердите операцию, только если текущее состояние уже сохранено отдельно.

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

1. 1
   Сохраните текущее состояние базы в отдельный каталог
2. 2
   Откройте конфигуратор нужной или новой пустой базы
3. 3
   Выберите «Администрирование» → «Загрузить информационную базу»
4. 4
   Укажите файл .dt и подтвердите замещение данных
5. 5
   Дождитесь завершения загрузки и при необходимости обновите конфигурацию БД
6. 6
   Запустите режим предприятия и проверьте остатки и документы

Способ 2. Возврат файловой базы из копии каталога

Файловая база — это каталог, в котором основной массив данных хранится в файле 1Cv8.1CD. Если вы делали копии каталога (вручную, скриптом или средствами резервного копирования), вернуть базу можно простым копированием.

Закройте все сеансы 1С, работающие с этой базой. Переименуйте текущий каталог базы, например добавив к имени суффикс «_повреждена» — это сохранит его как страховку. Скопируйте на место базы каталог из резервной копии. Откройте 1С и проверьте работу. Если путь к базе не менялся, запись в списке запуска обновлять не нужно.

Важное ограничение: копировать файл 1Cv8.1CD, пока с базой работают пользователи, нельзя — копия получится несогласованной. Если резервное копирование выполняется скриптом, заложите в него проверку отсутствия открытых сеансов или используйте механизм теневого копирования тома.

Способ 3. Восстановление клиент-серверной базы из резервной копии СУБД

Для баз на SQL Server или PostgreSQL основной механизм возврата — восстановление из резервной копии средствами самой СУБД. Выгрузка .dt в клиент-серверном режиме тоже работает, но для больших баз она медленнее и требует значительных ресурсов.

Для MS SQL Server откройте SQL Server Management Studio, найдите нужную базу, вызовите контекстное меню: «Tasks» → «Restore» → «Database». Укажите файл резервной копии (.bak), на вкладке «Options» при восстановлении поверх существующей базы включите опцию перезаписи (WITH REPLACE) и убедитесь, что активные соединения закрыты — для этого можно перевести базу в однопользовательский режим или завершить сеансы в консоли кластера 1С.

Для PostgreSQL восстановление выполняется командой pg_restore (для копий формата custom) или psql (для текстовых дампов). Перед восстановлением базу обычно пересоздают пустой. После завершения проверьте, что кластер 1С видит базу, и запустите её в режиме предприятия.

pg_restore -U postgres -d mybase --clean --if-exists /backup/mybase.backup

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

Способ 4. Откат после неудачного обновления конфигурации

Отдельный сценарий — база работает, но после обновления конфигурации появились ошибки, и нужно вернуться к прежнему состоянию. Если перед обновлением делалась выгрузка .dt или резервная копия (это стандартная практика, а типовые механизмы обновления сами предлагают создать копию), откат выполняется теми же способами, что описаны выше.

Если копии нет, но обновление ещё не завершено обновлением конфигурации базы данных (кнопка «Обновить конфигурацию базы данных» не нажималась), можно просто вернуть конфигурацию из файла поставки: «Конфигурация» → «Загрузить конфигурацию из файла». Данные при этом не пострадают. Если же обновление базы данных уже выполнено, вернуть старую структуру без копии невозможно — структура таблиц изменена необратимо.

Если резервной копии нет: ремонт повреждённой базы

Ситуация без копии — самая рискованная. Для файловой базы первый инструмент — утилита chdbfl.exe из каталога установленной платформы (подкаталог bin). Сделайте копию файла 1Cv8.1CD, запустите утилиту, укажите путь к копии файла, включите опцию «Исправлять обнаруженные ошибки» и дождитесь завершения проверки.

После работы утилиты откройте базу в конфигураторе и выполните «Администрирование» → «Тестирование и исправление». Сначала запускайте только проверки без включённых режимов исправления, чтобы оценить масштаб проблем. Режимы «Удалять объект» и «Создавать объект» при обнаружении битых ссылок применяйте осознанно: они могут удалить данные, которые теоретически ещё подлежат восстановлению.

Если повреждена серверная база, используйте штатные средства СУБД: для SQL Server — проверку целостности DBCC CHECKDB, для PostgreSQL — анализ журналов и при необходимости восстановление из WAL-архивов, если они настроены. Глубокий ремонт базы без копии — задача, при которой ошибка стоит дорого; если данные критичны, разумнее привлечь специалиста по 1С или по соответствующей СУБД.

Проверка результата после восстановления

Восстановление нельзя считать завершённым, пока вы не убедились, что база работоспособна и данные на месте. Минимальный набор проверок: база открывается в режиме предприятия без ошибок, отчёты по остаткам (склад, касса, взаиморасчёты) формируются и их цифры согласуются с ожиданиями, документы за последние дни перед сбоем присутствуют.

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

Как не попасть в эту ситуацию снова

Восстановление из копии — это всегда потеря данных за период с момента копирования. Чтобы минимизировать потери, настройте регулярное резервное копирование: для файловых баз — выгрузку .dt или копирование каталога по расписанию, для серверных — план обслуживания в СУБД с полными и разностными копиями.

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

Частые вопросы