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

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

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

Способ копирования зависит от того, как работает ваша база: в файловом варианте (один файл 1Cv8.1CD на диске) или в клиент-серверном (SQL Server, PostgreSQL). Ниже разобраны оба сценария, а также проверка резервной копии и типичные ошибки.

Какой способ копирования выбрать

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

Выгрузка в .dt — универсальный и самый надёжный метод для типовых ситуаций: файл содержит и данные, и конфигурацию, и его можно загрузить в пустую базу на любом компьютере. Копирование файла 1Cv8.1CD быстрее, но требует, чтобы все пользователи вышли из базы, иначе копия может оказаться несогласованной. SQL-копия — стандарт для серверных баз и больших объёмов.

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

Перед созданием копии завершите работу всех пользователей с базой. Активные сеансы во время выгрузки .dt недопустимы — конфигуратор потребует монопольный доступ. В клиент-серверном варианте сеансы можно завершить через консоль администрирования сервера 1С, в файловом — попросить пользователей выйти и проверить отсутствие процессов 1cv8.exe на компьютерах.

Проверьте свободное место на диске. Файл выгрузки .dt обычно занимает заметную часть размера самой базы, а при копировании файловой базы потребуется место, равное размеру 1Cv8.1CD. Для SQL-копии ориентируйтесь на размер базы данных в СУБД. Нехватка места в середине процесса — частая причина «битых» архивов.

Также зафиксируйте текущую версию конфигурации и платформы (меню «Справка» — «О программе» в конфигураторе). Если обновление пройдёт неудачно, эта информация понадобится для отката и диагностики.

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

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

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

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

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

Копирование файловой базы напрямую

Если база файловая, можно просто скопировать её каталог. Найдите папку базы (путь виден в списке информационных баз при запуске 1С) и скопируйте файл 1Cv8.1CD вместе со служебными файлами в отдельную папку или на внешний диск.

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

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

Для баз на SQL Server копия создаётся через SQL Server Management Studio: правый клик по базе — «Задачи» — «Создать резервную копию», тип «Полная». Для PostgreSQL используется утилита pg_dump. Такие копии создаются быстро, не требуют завершения сеансов пользователей и являются стандартом для серверных развёртываний.

Пример команды для PostgreSQL:

pg_dump -U postgres -F c -f base_backup_$(date +%Y%m%d).dump имя_базы

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

Проверка резервной копии перед обновлением

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

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

Где хранить копию и сколько копий держать

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

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

Что делать, если обновление прошло с ошибкой

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

Если копии нет, а база повреждена, варианты ограничены: утилита chdbfl.exe из каталога платформы для файловых баз, «Тестирование и исправление» с минимальными настройками на копии повреждённой базы, обращение к специалистам по восстановлению. Успех не гарантирован — именно поэтому копия делается до, а не после.

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