Как откатить 1С 8.3 на день назад

Откат базы 1С 8.3 на день назад означает восстановление информационной базы из резервной копии, созданной вчера или в нужный момент времени. Самой платформы 1С механизма «машины времени» не существует: вернуть состояние данных можно только из ранее сделанной копии — файла выгрузки .dt, SQL-бэкапа или снапшота виртуальной машины. Поэтому первый шаг — понять, какая копия у вас есть и где она лежит.

Типичные ситуации, когда требуется откат: ошибочное проведение или удаление документов, неудачное обновление конфигурации, некорректная обработка, массово изменившая данные, сбой при обмене. Во всех этих случаях восстановление из копии возвращает базу в состояние на момент её создания, но всё, что было введено после, будет потеряно.

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

Проверьте, какие резервные копии у вас есть

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

Уточните у администратора или в инструкции по резервному копировании: где хранятся копии, как часто они создаются и как называются. Часто в имени файла зашита дата, например base_2026-05-14.dt. Если копии делаются раз в сутки ночью, то «откат на день назад» вернёт состояние на момент ночного бэкапа, а не на начало вчерашнего рабочего дня.

Подготовка: зафиксируйте текущее состояние и выведите пользователей

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

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

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

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

Для файловой базы самый простой способ — загрузка выгрузки через конфигуратор. Запустите конфигуратор, откройте нужную базу и выберите в меню «Администрирование» пункт «Загрузить информационную базу». Укажите файл .dt за нужную дату и подтвердите операцию.

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

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

Откат клиент-серверной базы

Восстановление из бэкапа СУБД

Если база работает на MS SQL или PostgreSQL, восстановление выполняется средствами самой СУБД. В MS SQL это команда RESTORE DATABASE или восстановление через Management Studio: выберите бэкап за нужную дату и восстановите его поверх рабочей базы либо в новую базу с последующим переключением. Перед восстановлением базу нужно вывести из использования — перевести в single-user mode или завершить подключения.

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

Загрузка .dt на сервере

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

Сравнение способов отката

Загрузка .dt через конфигуратор

Просто и универсально, но медленно на больших базах; точность — момент выгрузки

Восстановление бэкапа СУБД

Быстро для больших баз; требует доступа к серверу БД и навыков администрирования

Point-in-time по журналу транзакций

Точный откат на любой момент; работает только при модели full и бэкапах журнала

Снапшот виртуальной машины

Откатывает весь сервер целиком; затрагивает всё, что на нём работает

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

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

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

Контрольные точки

Как проверить результат

Дата последнего документа

Норма

Соответствует моменту создания копии

Тревожный признак

Есть документы позже даты копии

Ошибочные изменения

Норма

Проблемные документы отсутствуют или в исходном виде

Тревожный признак

Ошибка сохранилась — копия взята не та

Оборотно-сальдовая ведомость

Норма

Сальдо совпадает с ожидаемым на дату копии

Тревожный признак

Расхождения — возможно, копия повреждена

Планы обмена

Норма

Нет нежелательных зарегистрированных изменений

Тревожный признак

Очередь на выгрузку дублей во внешние системы

Что делать с данными, введёнными после копии

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

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

Если резервной копии нет

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

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

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

Можно ли откатить только один документ, а не всю базу?

Штатного механизма отката отдельного объекта нет. Варианты: отменить проведение или пометить документ на удаление вручную, восстановить его из копии базы через обработку «Выгрузка и загрузка данных XML» либо использовать механизм версионирования объектов, если он был включён заранее.

Откатится ли конфигурация вместе с данными?

Да. Загрузка .dt и восстановление бэкапа СУБД возвращают и конфигурацию, и данные на момент создания копии. Если после копии было обновление, его придётся установить заново.

Сколько времени занимает восстановление?

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

Что будет с пользователями и их настройками после отката?

Список пользователей и их настройки хранятся в базе, поэтому они вернутся к состоянию на момент копии. Пользователи, добавленные после создания копии, исчезнут, а изменённые настройки — откатятся.

Можно ли восстановить базу не на ночной бэкап, а на середину вчерашнего дня?

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

Опасно ли откатывать базу, если с ней работает обмен с сайтом или банком?

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