Как сделать резервное копирование 1С Предприятие

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

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

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

Какой способ копирования выбрать под ваш режим работы

Первый шаг — определить, в каком режиме работает база. Откройте конфигуратор, меню «Администрирование» → «Свойства информационной базы», либо посмотрите строку подключения в списке баз при запуске. Если путь ведёт к каталогу на диске — это файловый режим. Если указан сервер 1С и имя базы на СУБД — клиент-серверный.

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

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

Это универсальный и самый безопасный способ для файловой базы. Файл dt — это архив выгрузки в формате платформы, из которого базу можно развернуть на любом компьютере с совместимой версией платформы 1С.

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

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

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

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

Файловая база целиком хранится в файле 1Cv8.1CD внутри каталога базы. Скопировав этот файл, вы получаете полную резервную копию. Способ быстрее выгрузки в dt, особенно для больших баз, и легко автоматизируется простым скриптом копирования.

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

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

Для базы на MS SQL Server резервную копию создают штатными средствами СУБД: через SQL Server Management Studio (правый клик по базе → Tasks → Back Up) или скриптом T-SQL по расписанию. Рекомендуется полная модель восстановления (Full) с регулярными копиями журнала транзакций — это позволяет восстановить базу на любой момент времени, а не только на момент последнего бэкапа.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_full.bak' WITH COMPRESSION, CHECKSUM

Для PostgreSQL используйте утилиту pg_dump с форматом custom (-Fc), который поддерживает сжатие и выборочное восстановление. Команда выполняется на сервере СУБД и не требует остановки работы пользователей — СУБД обеспечивает согласованный снимок данных.

pg_dump -U postgres -Fc -f /backups/mybase_$(date +%Y%m%d).dump mybase1c

Копирование средствами СУБД выполняется «на горячую», без выгона пользователей, и гораздо быстрее выгрузки dt. Именно поэтому для клиент-серверных баз dt используют редко — в основном для переноса базы на другую платформу или СУБД.

Автоматизация: бэкап по расписанию

Ручное копирование рано или поздно забывается, поэтому ежедневный бэкап должен выполняться автоматически. Для файловых баз настройте задачу в планировщике Windows, которая ночью запускает скрипт копирования файла 1Cv8.1CD или пакетную выгрузку конфигуратора. Перед копированием скрипт должен убедиться, что сеансов нет, либо завершить их.

Пакетная выгрузка через конфигуратор запускается из командной строки. Это удобно, когда нужен именно dt-файл без ручных действий:

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /DumpIB"D:\Backups\Buh_%date%.dt"

Для клиент-серверных баз расписание настраивается средствами самой СУБД: в MS SQL — через планы обслуживания (Maintenance Plans) или задания агента SQL Server, в PostgreSQL — через cron или планировщик с вызовом pg_dump. Типовая схема: полная копия раз в день ночью, копии журнала транзакций — каждые 15–60 минут в течение дня.

Проверка копий и правила хранения

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

Храните копии по правилу «3-2-1»: минимум три копии данных, на двух разных носителях, одна — вне основной площадки (другой офис, облачное хранилище). Копия, лежащая на том же диске, что и база, не спасёт ни от отказа диска, ни от шифровальщика — вирусы-вымогатели в первую очередь уничтожают доступные по сети бэкапы.

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

Типичные ошибки и как их избежать

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

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