Резервное копирование 1С 8.3 по расписанию: файлы, SQL, PG

Резервное копирование 1С 8.3 по расписанию настраивается по-разному в зависимости от того, где лежат данные. Для файловой базы это копия каталога с файлом 1Cv8.1CD, сделанная, когда в базе никто не работает, или выгрузка в файл .dt. Для выгрузки данных из файловой версии 1С нужен монопольный доступ, база блокируется. Для клиент-серверной базы правильный способ — штатные средства СУБД: план обслуживания или команда BACKUP DATABASE в MS SQL, утилита pg_dump в PostgreSQL. Эти копии делаются без остановки работы пользователей.

Запуск по расписанию обеспечивает Планировщик заданий Windows или SQL Server Agent. Но само расписание — только половина дела: копии нужно хранить по правилу 3-2-1 (одна из них вне офиса, например в облаке) и регулярно проверять, что из них действительно восстанавливается рабочая база.

Ниже — способы по порядку, их ограничения, пример скрипта для PostgreSQL на Windows и чек-лист проверки.

Какой способ подходит вашей базе

Способ	Для какой базы	Нужно ли выгонять пользователей	Плюсы	Минусы
Копия каталога файловой базы	Файловая	Да, база должна быть закрыта	Просто, быстро восстанавливается	Копия во время работы может оказаться повреждённой
Выгрузка .dt	Файловая и клиент-серверная	Да, нужен монопольный режим	Не зависит от СУБД, удобна для переноса	Долго на больших базах, не заменяет бэкап СУБД
Встроенная обработка резервного копирования в типовых конфигурациях	Файловая	Да, в момент копирования	Настраивается из интерфейса 1С	Зависит от запущенного клиента, мало контроля
План обслуживания или BACKUP в MS SQL	Клиент-серверная на MS SQL	Нет	Работает при подключённых пользователях, есть полные, разностные копии и копии журнала	Нужно понимать модель восстановления
pg_dump в PostgreSQL	Клиент-серверная на PostgreSQL	Нет	Согласованный снимок без остановки работы	Восстанавливать нужно в сборку PostgreSQL для 1С

Если вы ещё не определились, какой режим у вашей базы и какой нужен, прочитайте разбор файловой и клиент-серверной 1С.

Файловая база: копия каталога по расписанию

Файловая база — это каталог, в котором лежит файл 1Cv8.1CD (сами данные) и служебные файлы. Для восстановления достаточно скопировать этот каталог обратно и подключить его в списке баз.

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

Как настроить

Выберите время, когда гарантированно никто не работает, например 2:00 ночи. Предупредите сотрудников, чтобы выходили из 1С в конце дня. Или настройте принудительное завершение сессии пользователей (возможна потеря не записанных данных).
Определите, куда складывать копии: отдельный диск, сетевое хранилище, облачное хранилище. Не на тот же диск, где лежит база.
Создайте скрипт копирования. Для каталогов в Windows удобна штатная утилита robocopy, а для экономии места — архивация в zip или 7z с датой в имени архива.
Добавьте задание в Планировщик заданий Windows: триггер «Ежедневно», действие «Запуск программы» (ваш скрипт), параметр «Выполнять вне зависимости от регистрации пользователя» и учётная запись с правами на чтение каталога базы и запись в каталог копий.
Добавьте в скрипт удаление копий старше нужного срока, иначе место закончится.
Настройте уведомление об ошибке или хотя бы раз в неделю смотрите результат последнего запуска в Планировщике.

Чтобы копия не оказалась сделанной при открытой базе, скрипт можно дополнить проверкой: если файл 1Cv8.1CD занят, копирование откладывается или завершается с ошибкой. На терминальном сервере некоторые администраторы перед копированием принудительно завершают сеансы пользователей, но это стоит делать осознанно и с предупреждением.

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

В типовых конфигурациях на базе БСП (Бухгалтерия предприятия 3.0, ЗУП 3, УТ 11 и другие) для файлового режима есть раздел Администрирование — Обслуживание — Резервное копирование и восстановление. Там можно задать расписание и каталог. Ограничение: механизм зависит от запущенного клиента 1С и выполняет копирование при завершении работы или по расписанию, завершая сеансы. Для одного пользователя на своём компьютере это приемлемо, для офиса надёжнее отдельный скрипт на сервере.

Выгрузка .dt: когда полезна и когда нет

Файл .dt — это выгрузка информационной базы средствами платформы 1С. Вручную её делают в Конфигураторе: Администрирование — Выгрузить информационную базу. Для расписания используется пакетный запуск Конфигуратора:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /DumpIB "E:\Backup\buh.dt" /Out "X:\Backup\dump.log" /DisableStartupMessages

Для клиент-серверной базы вместо /F"путь" указывается /S"сервер\имя_базы". Номер версии платформы в пути подставьте свой.

Ограничения .dt, о которых стоит знать:

Монопольный режим. Выгрузка не выполнится, пока в базе есть активные сеансы пользователей.
Скорость. На базах в десятки гигабайт выгрузка и особенно загрузка занимают часы.
Нет восстановления на момент времени. Вы получаете состояние на время выгрузки, без журнала изменений.
Пароль в скрипте. Для пакетного запуска нужна учётная запись 1С с административными правами, и её пароль оказывается в файле. Ограничьте доступ к скрипту.

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

MS SQL: планы обслуживания и BACKUP по расписанию

MS SQL Server делает резервные копии без отключения пользователей. Есть три вида копий:

Полная — вся база на момент копии.
Разностная — изменения с последней полной копии.
Копия журнала транзакций — позволяет восстановить базу на конкретный момент времени, но только при модели восстановления Full.

Модель восстановления

Проверьте модель восстановления базы в свойствах базы в SQL Server Management Studio (страница «Параметры»). Если стоит Full, а копии журнала не делаются, журнал транзакций будет расти, пока не займёт весь диск. Типовые варианты для 1С:

Simple — ежедневная полная копия и, при необходимости, разностные днём. Потеря данных — до последней копии.
Full — ежедневная полная копия плюс копии журнала каждые 15–60 минут. Потеря данных — минуты.

Настройка через план обслуживания

В SQL Server Management Studio откройте Management — Maintenance Plans и запустите мастер (Maintenance Plan Wizard).
Добавьте задачи: Back Up Database (Full), при необходимости Back Up Database (Transaction Log), Maintenance Cleanup Task для удаления старых файлов.
Укажите базы, каталог копий, включите проверку целостности копии (Verify backup integrity).
Задайте расписание для каждой задачи.
Убедитесь, что служба SQL Server Agent запущена и стоит в автоматическом запуске.

В редакции SQL Server Express нет SQL Server Agent, поэтому планы обслуживания там не работают. Решение — скрипт с sqlcmd в Планировщике заданий Windows:

sqlcmd -S .\SQLEXPRESS -E -Q "BACKUP DATABASE [buh] TO DISK = N'X:\Backup\buh.bak' WITH INIT, CHECKSUM"

Здесь -E означает вход под учётной записью Windows, от имени которой запущено задание; у неё должны быть права на резервное копирование базы. Параметр WITH INIT перезаписывает файл, поэтому для хранения нескольких копий добавляйте дату в имя файла или переносите копию в архив после создания. Учтите, что файл копии создаёт служба SQL Server, поэтому у её учётной записи должны быть права на запись в каталог копий.

PostgreSQL на Windows: pg_dump по расписанию

Для баз 1С на PostgreSQL основной инструмент логического резервного копирования — pg_dump. Он создаёт согласованный снимок базы и не мешает работе пользователей. Формат -F c (custom) сжимается и восстанавливается утилитой pg_restore.

Пароль без хранения в скрипте

Чтобы не писать пароль в скрипт, создайте файл %APPDATA%\postgresql\pgpass.conf в профиле пользователя, от имени которого будет выполняться задание. Формат строки:

localhost:5432:*:postgres:ваш_пароль

Доступ к этому файлу должен быть только у этой учётной записи.

Пример скрипта PowerShell

$pgBin  = 'C:\Program Files\PostgreSQL\15.x\bin'   # укажите свой путь
$target = 'X:\Backup\pg'
$db     = 'buh'
$date   = Get-Date -Format 'yyyy-MM-dd_HHmm'

& "$pgBin\pg_dump.exe" -h localhost -p 5432 -U postgres -w -F c -f "$target\$($db)_$date.backup" $db
if ($LASTEXITCODE -ne 0) { exit 1 }

Get-ChildItem "$target\$($db)_*.backup" |
  Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-14) } |
  Remove-Item

Ключ -w запрещает интерактивный запрос пароля: если пароль не найден в pgpass.conf, скрипт завершится ошибкой, а не зависнет. Удаление старых копий выполняется только после успешного создания новой. Задание в Планировщике запускает powershell.exe с аргументами -NoProfile -ExecutionPolicy Bypass -File "путь_к_скрипту.ps1".

Путь к каталогу bin зависит от сборки: PostgreSQL для 1С от фирмы «1С» и Postgres Pro устанавливаются в разные каталоги. Найдите pg_dump.exe в своей установке.

Восстановление

Восстанавливают копию командой pg_restore в заранее созданную пустую базу:

pg_restore -h localhost -U postgres -d buh_test "X:\Backup\pg\buh_2026-09-20_0200.backup"

Важно: базы 1С используют типы данных из расширений, которые есть только в сборках PostgreSQL для 1С. Восстанавливать копию нужно на такую же сборку, желательно той же основной версии, иначе восстановление завершится ошибками. После восстановления базу нужно зарегистрировать в кластере серверов 1С.

Правило 3-2-1 и копии в облако

Копия, которая лежит на том же сервере, что и база, не защищает ни от отказа диска, ни от шифровальщика. Правило 3-2-1:

3 копии данных (рабочая база и две резервные);
2 разных носителя (например, локальный диск сервера и сетевое хранилище);
1 копия вне офиса или вне основной площадки — облачное хранилище, другой дата-центр.

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

Разные учётные данные. Учётная запись, с которой сервер пишет в облако, не должна иметь права удалять старые копии. Иначе шифровальщик или злоумышленник, получивший доступ к серверу, удалит и их.
История версий. Храните несколько поколений: ежедневные за 1–2 недели, еженедельные за 1–2 месяца, ежемесячные дольше.
Шифрование. Копии баз 1С содержат персональные данные и коммерческую информацию. Шифруйте архив до отправки во внешнее хранилище.
Контроль объёма и времени. Большая база по медленному каналу может не успеть уйти в облако за ночь. Проверьте это на реальных размерах.

Как действовать, если шифровальщик всё-таки добрался до сервера, разобрано в статье о вирусе-шифровальщике.

Проверка восстановления

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

Что проверить	Как часто
Последнее задание выполнено без ошибок, файл копии свежий и нормального размера	Ежедневно или через уведомления
Копия дошла до внешнего хранилища	Еженедельно
Восстановление в тестовую базу, запуск 1С, открытие отчётов	Ежемесячно
Время полного восстановления укладывается в допустимый простой	Раз в квартал или после роста базы
Документация: где копии, как восстанавливать, у кого доступ	При любых изменениях

Тестовое восстановление делайте в отдельную базу с другим именем, чтобы случайно не перезаписать рабочую. Для 1С проверьте, что база открывается, формируются основные отчёты, остатки совпадают с рабочей базой на дату копии.

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

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

Можно ли копировать файловую базу 1С, пока в ней работают?

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

Заменяет ли выгрузка .dt резервное копирование SQL?

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

Как часто делать копии базы 1С?

Ориентируйтесь на то, сколько работы вы готовы потерять. Минимум — ежедневная ночная копия. Если потерять несколько часов работы бухгалтерии недопустимо, на MS SQL используйте модель Full с копиями журнала каждые 15–60 минут, на PostgreSQL — дополнительные копии днём или архивирование WAL.

Почему в MS SQL растёт файл журнала транзакций?

Чаще всего база находится в модели восстановления Full, а копии журнала не делаются. Журнал очищается только после его резервного копирования. Либо настройте копии журнала, либо переведите базу в модель Simple, если восстановление на момент времени не нужно.

Можно ли восстановить копию PostgreSQL от 1С в обычный PostgreSQL?

Нет, базы 1С используют специальные типы данных из сборки PostgreSQL для 1С. Восстанавливайте копию на сервер с такой же сборкой, желательно той же версии.

Сколько хранить резервные копии?

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