Как откатить базу 1С к рабочему состоянию

Отдельной кнопки «Откатить базу» в 1С нет, и это первое, что путает. Откат базы 1С — это всегда возврат к её более раннему состоянию: восстановление данных из резервной копии либо возврат конфигурации, если проблему создало обновление. От того, что именно сломалось — цифры в документах или сама конфигурация, — зависит и способ отката.

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

В каких ситуациях базу откатывают назад

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

• 🧨 Массовая ошибка ввода. Загрузили не тот файл, провели пачку неверных документов, запустили групповую обработку не на той базе.
• ⚙️ Неудачное обновление конфигурации. После обновления база считает неправильно, отчёты не открываются, типовые документы ломаются.
• 💥 Сбой и повреждение базы. Отключение питания, зависание сервера СУБД, ошибка диска — база перестала открываться или выдаёт ошибки целостности.
• 🧪 Эксперименты в рабочей базе. Прогнали тестовую обработку или перепроведение «посмотреть, что будет», и результат пора отменить.
• 🦠 Последствия вируса-шифровальщика или удаление данных по ошибке.

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

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

Что сделать до отката, чтобы не потерять свежие данные

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

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

1. Предупредите пользователей и дайте им выйти — откат идёт в монопольном режиме, работать во время него нельзя.
2. Завершите все сеансы. В клиент-серверном варианте это делают через консоль кластера или rac session list, затем принудительное завершение зависших сеансов.
3. Снимите актуальную резервную копию текущей базы.
4. Запишите номер версии платформы, в которой работает база. Загрузить выгрузку .dt можно только в платформу с номером не ниже того, в котором она сделана.
5. Найдите подходящую копию для восстановления и убедитесь, что она открывается и относится к нужной дате.

Какой способ отката выбрать — зависит от того, что именно сломалось:

Откат файловой базы 1С

У файловой базы два пути, и оба быстрые.

Способ 1. Восстановить из выгрузки .dt. Подходит, если копию делали штатно из конфигуратора.

1. Откройте базу в режиме Конфигуратор.
2. Меню Администрирование → Загрузить информационную базу.
3. Укажите файл .dt и подтвердите. Конфигуратор предупредит, что текущая база будет полностью заменена.
4. Дождитесь окончания загрузки и запустите 1С:Предприятие для проверки.

Способ 2. Подменить файл базы. Файловая база целиком хранится в одном файле 1Cv8.1CD в каталоге базы. Если есть его копия на нужную дату:

1. Убедитесь, что базу никто не открыл (ни 1С:Предприятие, ни конфигуратор).
2. Переименуйте текущий 1Cv8.1CD, например в 1Cv8.1CD.old, — это и есть ваша страховка.
3. Скопируйте в каталог базы файл 1Cv8.1CD из резервной копии.
4. Запустите базу и проверьте данные.

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

В клиент-серверном варианте данные лежат в СУБД — Microsoft SQL Server или PostgreSQL, — и откат делают средствами самой СУБД, а не из конфигуратора.

Общий порядок:

1. Завершите сеансы пользователей и временно запретите новые подключения (в консоли кластера установите для базы запрет сеансов и регламентных заданий).
2. Восстановите базу СУБД из её резервной копии: в SQL Server — через восстановление базы данных из .bak, в PostgreSQL — из дампа, созданного pg_dump.
3. После восстановления снимите запрет подключений и запустите 1С:Предприятие для проверки.

Насколько далеко назад можно откатиться, зависит от модели восстановления СУБД. Если для SQL Server включена полная модель восстановления и регулярно сохраняется журнал транзакций, восстановить базу можно не только на момент последнего бэкапа, но и почти на любую точку до сбоя. При простой модели вернётесь лишь к последней полной или разностной копии. Проверьте настройку заранее — после аварии менять модель уже поздно.

Выгрузка .dt для серверной базы тоже доступна (тот же пункт Администрирование → Загрузить информационную базу в конфигураторе), но для больших баз она медленнее и тяжелее, чем восстановление средствами СУБД. .dt удобен для переноса базы между серверами, а для регулярного отката рабочей базы надёжнее бэкап СУБД.

Откат неудачного обновления конфигурации

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

Изменения ещё не сохранены в БД. Пока вы нажали «Обновить конфигурацию базы данных», но не подтвердили реструктуризацию, или вообще только загрузили новую конфигурацию в конфигуратор:

• Конфигуратор → Конфигурация → Конфигурация базы данных → Вернуться к конфигурации базы данных.

Эта команда откатывает основную конфигурацию обратно к той, что реально работает в базе. Изменения, не дошедшие до БД, отменяются, данные не трогаются.

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

Автоматизация резервных копий и отката

Откат возможен только тогда, когда есть из чего откатывать. Поэтому копии настраивают заранее и автоматически.

Файловая база — выгрузка из командной строки. Платформа умеет выгружать и загружать базу без участия человека. Команда выгрузки:

"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER /F "C:\Bases\Buh" /N "Admin" /P "pass" /DumpIB "D:\backup\buh_%date%.dt"

Обратная команда — загрузка (откат) из выгрузки:

"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER /F "C:\Bases\Buh" /N "Admin" /P "pass" /RestoreIB "D:\backup\buh.dt"

Такой .bat-файл ставят в планировщик Windows на ночь. Параметры /DumpIB и /RestoreIB работают в режиме DESIGNER; загрузка требует монопольного доступа, поэтому запускать её нужно, когда в базе никто не работает .

Серверная база — средствами СУБД. Для SQL Server настраивают план обслуживания с регулярным полным и разностным бэкапом. Для PostgreSQL — задание с pg_dump по расписанию. Это надёжнее выгрузки .dt: восстановление идёт быстрее, а разностные копии позволяют откатиться почти на любой момент.

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

Откат облачных баз: 1С:Fresh и аренда

В облаке прямого доступа к файлу базы или к СУБД у вас нет, поэтому откат делают иначе.

В сервисе 1С:Fresh резервные копии создаёт провайдер автоматически. Пользователю доступны два действия:

• выгрузить копию своей области в файл .dt (из личного кабинета сервиса) — её можно развернуть у себя локально;
• запросить восстановление базы на нужную дату — через личный кабинет сервиса или через обслуживающего партнёра.

Самостоятельно «подменить файл», как в файловой базе, в облаке нельзя. Если базу арендуете у хостинг-провайдера (размещение 1С на его серверах), откат из резервной копии выполняет служба поддержки провайдера по вашей заявке — укажите базу и дату, на которую нужно вернуться.

Частые ошибки при откате

• ❌ Откат без свежей копии текущей базы. Если после восстановления выяснится, что откатили слишком далеко, вернуть недавние данные будет уже неоткуда.
• ❌ Путаница между откатом данных и откатом конфигурации. Восстановление всей базы ради одной слетевшей печатной формы — потеря всех документов, введённых после копии.
• ❌ Загрузка .dt в платформу старее той, где файл создан. Платформа откажется загружать выгрузку в младшую версию — проверяйте номер заранее.
• ❌ Восстановление серверной базы при активных пользователях. Сеансы оборвутся, а часть данных может не записаться. Сначала запрет подключений, потом восстановление.
• ❌ Копирование файла 1Cv8.1CD при открытой базе. Копия «на ходу» получается битой. Файловую базу копируют только когда она закрыта.

Если откат не помог

Бывает, что база после отката всё равно ведёт себя странно. Порядок действий:

1. Проверьте, ту ли копию восстановили. Сверьте дату последнего документа в базе с ожидаемой.
2. Запустите тестирование и исправление. Конфигуратор → Администрирование → Тестирование и исправление. Для файловой базы можно предварительно прогнать chdbfl.exe. Делайте это на копии базы, а не на единственном экземпляре.
3. Откатитесь на копию более ранней даты, если ближайшая оказалась уже с проблемой.
4. Соберите данные о проблеме — тексты ошибок, какие документы не открываются, что делали перед сбоем.
5. Обратитесь к обслуживающему специалисту или партнёру 1С. Повреждение на уровне СУБД или ошибку, тянущуюся из нескольких копий, быстрее разберёт специалист с доступом к серверу.