Как откатить базу 1С: пошаговые способы восстановления

Откат базы 1С требуется в трёх типовых ситуациях: после неудачного обновления конфигурации, после ошибочной загрузки данных или массовой обработки, а также после повреждения информационной базы. В каждом случае порядок действий отличается: файловая база восстанавливается из выгрузки DT или копии файла, клиент-серверная — из резервной копии СУБД или средствами MS SQL Server / PostgreSQL.

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

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

Что проверить перед откатом базы

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

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

Оцените «цену отката»: сколько данных будет потеряно между моментом создания копии и текущим моментом. Если после копии в базу введены документы, они исчезнут при восстановлении. Иногда выгоднее не откатывать всю базу, а точечно исправить ошибку — например, отменить проведение ошибочных документов или удалить загруженные данные.

Откат файловой базы через выгрузку DT

Выгрузка в DT — штатный способ переноса и отката файловой базы. Файл выгрузки создаётся в конфигураторе через меню «Администрирование» → «Выгрузить информационную базу». Если такая выгрузка делалась перед сбоем, восстановление занимает несколько минут.

Порядок восстановления: создайте пустую базу или откройте конфигуратор существующей (в монопольном режиме), выберите «Администрирование» → «Загрузить информационную базу» и укажите DT-файл. Платформа предупредит, что текущие данные будут замещены — это и есть откат. После загрузки конфигуратор предложит перезапуск; если структура метаданных в выгрузке отличается, будет выполнена реструктуризация.

Учтите ограничение: DT-выгрузка не является резервной копией в строгом смысле. При загрузке в базу с отличающейся версией платформы возможны ошибки, а для очень больших баз выгрузка и загрузка занимают значительное время. Для регулярного резервирования файловой базы надёжнее простое копирование каталога с файлом 1Cv8.1CD при остановленной работе пользователей.

1. 1
   Выведите всех пользователей и откройте базу в конфигураторе монопольно
2. 2
   Сделайте копию текущего состояния базы — на случай, если откат не решит проблему
3. 3
   Администрирование → Загрузить информационную базу → выберите DT-файл
4. 4
   Подтвердите замещение данных и дождитесь окончания загрузки
5. 5
   При запросе выполните реструктуризацию и перезапустите конфигуратор
6. 6
   Проверьте версию конфигурации и откройте базу в режиме предприятия

Откат файловой базы заменой файла 1Cv8.1CD

Если резервное копирование выполнялось копированием каталога базы, откат сводится к замене файла. Закройте все сеансы 1С, убедитесь, что файл 1Cv8.1CD не занят никаким процессом, переименуйте текущий файл (например, добавьте суффикс даты) и скопируйте на его место файл из резервной копии.

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

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

Откат клиент-серверной базы через СУБД

В клиент-серверном варианте данные хранятся в СУБД (MS SQL Server, PostgreSQL, Oracle), и откат выполняется её средствами. Для MS SQL Server это восстановление из полной резервной копии: в SQL Server Management Studio правый клик по базе → «Задачи» → «Восстановить» → «База данных», выбор backup-файла и опция перезаписи существующей базы (WITH REPLACE). Перед восстановлением все соединения с базой должны быть разорваны — проще всего перевести базу в однопользовательский режим.

Если настроена полная модель восстановления (FULL) и ведутся бэкапы журнала транзакций, доступен откат на конкретный момент времени (point-in-time recovery) — например, на минуту до ошибочной обработки. Это самый точный способ: восстанавливается полная копия, затем последовательно накатываются журналы до указанной отметки времени с опцией STOPAT.

Для PostgreSQL логика аналогична: восстановление из дампа, созданного pg_dump, выполняется через pg_restore или psql, а точечный откат во времени — через WAL-архивы, если настроен непрерывный бэкап. После восстановления на стороне СУБД никаких действий в конфигураторе не требуется — база 1С увидит данные сразу, поскольку связь с базой не менялась.

-- MS SQL: откат на конкретный момент времени
RESTORE DATABASE [Base1C] FROM DISK = 'D:\backup\base_full.bak' WITH NORECOVERY, REPLACE;
RESTORE LOG [Base1C] FROM DISK = 'D:\backup\base_log.trn' WITH STOPAT = '2026-06-10T14:30:00', RECOVERY;

Откат конфигурации без потери данных

Не всегда нужно откатывать всю базу. Если проблема вызвана обновлением конфигурации, а данные после обновления вводились и их терять нельзя, рассмотрите возврат только конфигурации. Вариант первый: если перед обновлением сохранялся CF-файл, загрузите его через «Конфигурация» → «Загрузить конфигурацию из файла» в конфигураторе. Учтите, что обратная реструктуризация (откат изменений структуры таблиц) может не поддерживаться — платформа не всегда умеет «откатывать» изменения метаданных, и в ряде случаев единственный чистый путь — восстановление всей базы из копии.

Вариант второй: конфигурация поставщика. Если база на поддержке, можно загрузить конфигурацию поставщика нужной версии («Поддержка» → «Настройка поддержки» → «Загрузить конфигурацию из файла»), а затем обновить конфигурацию базы данных. Это работает, если доработки минимальны или их можно перенести повторно.

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

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

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

Для файловой базы полезно запустить «Тестирование и исправление» в конфигураторе с минимальным набором проверок: референциальная целостность и проверка логической целостности. Для клиент-серверной базы проверьте на стороне СУБД отсутствие ошибок в логах и выполните проверку целостности средствами СУБД (например, DBCC CHECKDB для MS SQL).

Зафиксируйте, какие данные потеряны между моментом копии и моментом отката: выгрузите список документов, введённых за этот период, из «старых» остатков (если сохранили переименованный файл или отдельную копию), и передайте пользователям на повторный ввод.

Типичные ошибки при откате и как их избежать

Самая частая ошибка — восстановление не той копии. Когда бэкапов несколько, легко перепутать даты, особенно если файлы названы неинформативно. Используйте в именах копий дату и время, а перед восстановлением сверяйте размер и дату файла. Вторая ошибка — откат без сохранения текущего состояния: если выяснится, что копия старее, чем ожидалось, или проблема была не в базе, вернуться будет не к чему.

Третья группа ошибок — техническая: попытка загрузить DT в базу с работающими пользователями, копирование файла базы «на живую», восстановление бэкапа SQL без отключения соединений. Все эти сценарии приводят либо к ошибкам, либо к повреждению данных. Четвёртая ошибка — забыть про внешние связи: если база обменивается данными с другими системами, после отката возможны рассинхронизации, дубли при обмене и расхождения остатков. Планируйте пост-откатную синхронизацию заранее.

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