Как сохранять базы 1С: практическое руководство

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

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

Чем выгрузка .dt отличается от копирования файла базы

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

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

Как сохранить файловую базу через конфигуратор

Штатный способ — выгрузка в .dt. Откройте базу в режиме конфигуратора под пользователем с правами администратора. Перед выгрузкой убедитесь, что остальные пользователи завершили работу: в меню «Администрирование» доступен пункт «Активные пользователи», где видно открытые сеансы.

Далее выберите «Администрирование — Выгрузить информационную базу», укажите папку и имя файла. Имя лучше формировать с датой, например trade_2026-05-15.dt, — так проще найти нужную копию. Дождитесь завершения выгрузки: платформа сообщит об успешном окончании. Не прерывайте процесс — недописанный файл .dt бесполезен, а старая копия при этом останется, если вы сохраняете каждый раз в новый файл.

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

Копирование файла 1Cv8.1CD

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

Копирование целесообразно для очень больших файловых баз, где выгрузка .dt занимает неприемлемо много времени. Но помните: такая копия не подходит для переноса на клиент-серверный вариант и не «лечит» базу, в отличие от цикла выгрузки-загрузки .dt.

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

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

Для Microsoft SQL Server используйте полную резервную копию (FULL backup) через SQL Server Management Studio или скрипт T-SQL. Такую копию можно делать «на горячую», не выгоняя пользователей. Для PostgreSQL применяйте утилиту pg_dump, для Oracle — штатные средства RMAN или Data Pump.

BACKUP DATABASE [TradeBase] TO DISK = N'D:\Backups\TradeBase_full.bak' WITH COMPRESSION, CHECKSUM;

pg_dump -U postgres -Fc -f /backups/trade_$(date +%F).dump trade_base

Обратите внимание на модель восстановления базы в SQL Server. При полной модели (FULL) журнал транзакций растёт, пока не выполняется резервное копирование журнала — без него диск может переполниться. Если точность «на момент времени» не нужна, переведите базу в простую модель (SIMPLE) и делайте полные копии по расписанию.

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

Ручное копирование неизбежно сбивается: отпуск администратора, аврал, забывчивость. Автоматизация решает эту проблему. Для SQL Server настройте план обслуживания (Maintenance Plan) или задание агента SQL Server с ежедневной полной копией. Для PostgreSQL и файловых баз используйте планировщик задач Windows или cron в Linux, вызывающий скрипт копирования.

Платформа 1С умеет запускать пакетные операции из командной строки, что позволяет автоматизировать и выгрузку .dt: конфигуратор запускается с параметрами /DumpIB и путём к файлу выгрузки. Скрипт помещается в планировщик задач на ночное время, когда пользователей нет.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F "D:\Bases\Trade" /N Админ /P *** /DumpIB "D:\Backups\trade_%date%.dt"

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

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

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

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

Типичные ошибки и риски

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

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

Что делать перед обновлением и переносом базы

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

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