Как делать бэкап базы 1С: полная инструкция

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

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

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

Определите режим работы базы: файловый или клиент-серверный

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

Файловая база — это один файл 1Cv8.1CD в каталоге на диске или сетевой папке. Клиент-серверная база физически хранится в СУБД (MS SQL Server, PostgreSQL, Oracle), и файл .1CD у неё нет — копировать «папку с базой» в этом случае бессмысленно.

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

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

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

1. 1
   Завершите работу всех пользователей и фоновых задач в базе
2. 2
   Откройте базу в режиме «Конфигуратор» под учётной записью с полными правами
3. 3
   Выберите в меню: Администрирование → Выгрузить информационную базу
4. 4
   Укажите путь и имя файла, например buh_2026-05-15.dt, и дождитесь окончания
5. 5
   Проверьте, что файл создан и его размер соизмерим с размером базы

Включайте дату в имя файла — иначе через месяц будет непонятно, какая копия свежая. Удобный формат: база_ГГГГ-ММ-ДД.dt. Файл выгрузки обычно заметно меньше самой базы, поскольку данные в нём сжаты.

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

Как скопировать файловую базу напрямую

Быстрый альтернативный способ для файлового режима — скопировать файл 1Cv8.1CD средствами операционной системы. Главное условие: база должна быть полностью закрыта всеми пользователями. Копирование открытого файла даст повреждённую копию, которая не откроется.

Проверить, что сеансов нет, можно по отсутствию файла 1Cv8.1CL рядом с базой — это служебный файл блокировок, он существует, пока кто-то работает. После копирования сравните размеры исходного файла и копии: они должны совпадать до байта.

Способ удобен для скриптовой автоматизации ночью, когда пользователей гарантированно нет. Но он менее надёжен, чем выгрузка в .dt: платформа при копировании файла не проверяет целостность данных, а выгрузка фактически перечитывает всю базу.

Как бэкапить клиент-серверную базу на SQL

Для баз на MS SQL Server резервное копирование выполняется штатными средствами СУБД, а не 1С. Откройте SQL Server Management Studio, найдите базу, щёлкните правой кнопкой: Tasks → Back Up, выберите тип Full и укажите файл назначения с расширением .bak.

Для регулярной работы настраивают план обслуживания (Maintenance Plan): полная копия ежедневно или еженедельно, разностные копии чаще, копии журнала транзакций — если база в модели восстановления Full и важна возможность отката на произвольный момент времени.

Для PostgreSQL используется утилита pg_dump или pg_basebackup. Важно: копию средствами СУБД можно делать без остановки работы пользователей — СУБД обеспечивает согласованный снимок данных. Это главное преимущество клиент-серверного режима для бэкапов.

pg_dump -U postgres -F c -f /backup/ut_$(date +%Y-%m-%d).dump ut_database

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

Как автоматизировать резервное копирование

Ручные копии рано или поздно перестают делать — автоматизация обязательна. Стандартный подход: скрипт (bat, PowerShell или shell), запускаемый планировщиком заданий Windows или cron в нерабочее время.

Для файловой базы скрипт может вызывать конфигуратор в пакетном режиме с параметром /DumpIB и указанием файла выгрузки. Для SQL-базы — вызывать sqlcmd с командой BACKUP DATABASE или запускать pg_dump. Храните скрипт и лог его выполнения вместе с копиями: по логу видно, когда копирование реально отработало, а когда завершилось ошибкой.

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

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

Действует практическое правило «3-2-1»: минимум три копии данных, на двух разных носителях, одна — вне основной площадки. На практике это означает: рабочая база на сервере, копии на отдельном диске или NAS и дополнительная копия в облачном хранилище или на площадке в другом здании.

Глубина хранения зависит от того, как далеко назад может понадобиться откат. Разумный минимум для учётной базы: ежедневные копии за последние 7–14 дней, еженедельные — за 1–2 месяца, помесячные — за год и дольше. Копию на конец отчётного периода после сдачи отчётности хранят долго и не перезаписывают.

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

Как проверить, что бэкап рабочий

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

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

Типичные ошибки и ограничения

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

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

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