Восстановление 1С из бэкапа: все рабочие способы

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

Любая загрузка .dt полностью стирает текущее содержимое базы и ставит на его место данные из копии. Если в рабочей базе после создания бэкапа успели что-то провести, эти движения пропадут. Поэтому перед восстановлением всегда делают свежую выгрузку текущего состояния — чтобы было куда откатиться, если копия окажется не той.

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

С чего начать: тип базы и формат копии

Сначала определите два момента — тогда способ выберется сам.

Тип информационной базы:

• 🗂 Файловая — база лежит в папке, внутри файл 1Cv8.1CD. Такие базы восстанавливают загрузкой .dt или копированием файла.
• 🖥 Клиент-серверная — данные хранятся в СУБД (MS SQL, PostgreSQL). Здесь два пути: загрузить .dt через Конфигуратор или восстановить бэкап на уровне СУБД.

Что за копия у вас есть:

• файл .dt — выгрузка информационной базы средствами 1С;
• бэкап СУБД (.bak, дамп PostgreSQL) — снимок базы данных целиком;
• архив папки файловой базы (скопированный 1Cv8.1CD);
• копия, созданная встроенным механизмом конфигурации (БП, ЗУП, УТ).

Чтобы не гадать, какой путь ваш:

Загрузка базы из файла .dt через Конфигуратор

Это основной способ для файловых баз и универсальный — для серверных.

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

После загрузки Конфигуратор предложит перезапустить программу — согласитесь.

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

Восстановление встроенным механизмом конфигурации

Типовые конфигурации на управляемых формах (Бухгалтерия 3.0, ЗУП 3.1, Управление торговлей 11) умеют делать и возвращать копии сами, без Конфигуратора. Удобно, когда копию создавали этим же инструментом.

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

Дальше:

1. Откройте Резервное копирование и восстановление → Восстановление из резервной копии.
2. Выберите файл копии (обычно это тот же .dt, сложенный в заданную папку).
3. Программа предупредит, что завершит работу и восстановит данные. Подтвердите.
4. После восстановления база перезапустится сама.

Этот механизм работает только в файловом варианте и фактически оборачивает ту же загрузку .dt. Для серверных баз пользуйтесь Конфигуратором или средствами СУБД.

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

Если база хранится в MS SQL или PostgreSQL и у вас есть бэкап СУБД, восстановление идёт на стороне сервера баз данных. 1С при этом не запускается — работаете в инструментах СУБД.

MS SQL Server (через SSMS):

1. Снимите активные подключения к базе. Удобно перевести её в однопользовательский режим:

ALTER DATABASE [ИмяБазы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

2. Восстановите бэкап поверх существующей базы:

RESTORE DATABASE [ИмяБазы]
  FROM DISK = N'C:\Backup\base.bak'
  WITH REPLACE, RECOVERY;

3. Верните многопользовательский режим:

ALTER DATABASE [ИмяБазы] SET MULTI_USER;

PostgreSQL: восстановление зависит от формата дампа — pg_restore для custom-формата или psql для простого SQL-дампа. Точные ключи смотрите в документации вашей версии PostgreSQL.

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

Автоматизация: восстановление через командную строку

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

Выгрузка текущего состояния в .dt:

"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER ^
  /F"C:\Bases\Buh" /N"Администратор" /P"пароль" ^
  /DumpIB "C:\Backup\buh.dt"

Загрузка (восстановление) из .dt:

"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER ^
  /F"C:\Bases\Buh" ^
  /RestoreIB "C:\Backup\buh.dt"

Для серверной базы вместо /F укажите /S:

"C:\Program Files\1cv8\common\1cv8.exe" DESIGNER ^
  /S"srv-1c\buh_test" ^
  /RestoreIB "C:\Backup\buh.dt"

Разбор ключей:

• DESIGNER — запуск в режиме Конфигуратора (пакетно).
• /F — путь к файловой базе; /S — сервер и имя серверной базы.
• /N и /P — имя и пароль пользователя (если в базе заведена авторизация).
• /DumpIB — выгрузить в .dt; /RestoreIB — загрузить из .dt.

Такой .bat ставят в Планировщик заданий Windows. Для серверных баз помните: /RestoreIB запросит монопольный доступ, поэтому запускайте задание в окно, когда база свободна.

Что проверить после восстановления

Восстановить данные — половина дела. Чтобы база работала корректно, пройдите по короткому списку.

Особенно важны два пункта.

Тестирование и исправление. В Конфигураторе: Администрирование → Тестирование и исправление. Для восстановленной копии полезны реиндексация таблиц и проверка целостности. Операцию тоже выполняют в монопольном режиме.

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

Типичные ошибки при восстановлении

Как настроить резервное копирование, чтобы было что восстанавливать

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

• 🗓 Расписание. Для файловых баз — ежедневная ночная выгрузка .dt по .bat из Планировщика. Для серверных — регламентный бэкап средствами СУБД (план обслуживания в MS SQL, задание pg_dump для PostgreSQL).
• 🔁 Глубина хранения. Держите не одну копию, а серию: несколько ежедневных плюс недельные. Одна-единственная копия бесполезна, если повреждение заметили не сразу и успели перезаписать свежим бэкапом уже битые данные.
• 💾 Отдельный носитель. Копии должны лежать не на том же диске (а лучше не на том же сервере), где сама база. Отказ диска не должен уносить и базу, и её бэкапы.
• ✅ Проверка копий. Раз в период разворачивайте копию в тестовую базу и убеждайтесь, что она открывается. Бэкап, который ни разу не пробовали восстановить, — это ещё не бэкап.

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