Резервное копирование 1С 8.3: полное руководство

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

Восстановление без бэкапа занимает дни или невозможно вовсе. Резервное копирование 1С 8.3 — не опция, а обязательная часть эксплуатации.

В этой статье: что именно резервировать, какие способы бэкапа существуют, как настроить автоматическое копирование средствами SQL Server и PostgreSQL. Внутри — готовые скрипты для Windows и Linux. Результат — настроенная система бэкапов с ротацией и проверкой восстановления.

Статья для администраторов, которые работают с клиент-серверной архитектурой 1С. Если вы ещё не определились с СУБД — начните со сравнения SQL Server и PostgreSQL для 1С.

Что нужно резервировать

Резервная копия 1С — это не только база данных. Полное резервное копирование включает четыре компонента. Потеря любого из них усложняет восстановление.

Информационная база — главный объект бэкапа. Если вы используете кластер серверов 1С, база хранится в СУБД. Бэкап базы 1С SQL делается средствами СУБД — это самый надёжный и быстрый способ.

Конфигурация входит в состав информационной базы, поэтому при бэкапе базы она сохраняется автоматически. Отдельный бэкап конфигурации через Конфигуратор (выгрузка .cf) полезен как дополнительная страховка — файл занимает 10-100 МБ и восстанавливается за минуту.

Настройки кластера — каталог srvinfo. На Windows: C:\Program Files\1cv8\srvinfo\, на Linux: /home/usr1cv8/.1cv8/1C/1cv8/. Содержит реестр кластера, список зарегистрированных ИБ, параметры рабочих серверов. Потеря srvinfo не критична (кластер пересоздаётся), но экономит время — не нужно заново регистрировать все базы.

Способы резервного копирования 1С 8.3

Четыре способа сделать бэкап 1С. Выбор зависит от типа базы (файловая или SQL), размера, допустимого простоя и уровня автоматизации.

Через Конфигуратор (ручной бэкап .dt)

Конфигуратор 1С умеет выгружать базу в файл .dt (Администрирование → Выгрузить информационную базу). Файл .dt содержит данные и конфигурацию в сжатом виде.

Плюсы: простой, не требует знания SQL, работает с любым типом базы. Минусы: требует монопольного доступа — всех пользователей нужно отключить. На базе 10 ГБ выгрузка занимает 15-30 минут. Не подходит для автоматизации — нужен запущенный Конфигуратор.

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

Автоматизировать выгрузку .dt можно через командную строку 1С:

:: Выгрузка .dt через командную строку (Windows)
"C:\Program Files\1cv8\8.3.23.2040\bin\1cv8.exe" CONFIG ^
  /S "server\MyBase1C" ^
  /N "Admin" /P "password" ^
  /DumpIB "D:\Backup\MyBase1C.dt" ^
  /Out "D:\Backup\dump.log"

Этот способ по-прежнему требует монопольного доступа. Перед запуском скрипта завершите все сеансы через консоль администрирования кластера.

Средствами СУБД (SQL Server / PostgreSQL)

Основной метод для клиент-серверных баз. СУБД создаёт бэкап своими инструментами: BACKUP DATABASE в SQL Server, pg_dump в PostgreSQL. Работает без остановки пользователей (горячий бэкап). Поддерживает полные, дифференциальные и инкрементальные копии.

Плюсы: быстрый, не требует отключения пользователей, встроенная поддержка сжатия, можно восстановить на определённый момент времени (point-in-time recovery). Минусы: требует знания СУБД, разные команды для SQL Server и PostgreSQL.

Какую СУБД выбрать — зависит от задач и бюджета. SQL Server проще в настройке бэкапов (планы обслуживания через GUI), PostgreSQL бесплатен и отлично работает на Linux. Подробное сравнение — в статье SQL Server vs PostgreSQL для 1С.

Файловое копирование (для файловых баз)

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

Расположение файловой базы: путь указан в свойствах информационной базы в списке баз 1С. Обычно C:\Users\...\Documents\1C\Base\ или сетевая папка.

Скрипт для автоматического копирования файловой базы (PowerShell):

# Бэкап файловой базы 1С
$sourceDir = "\\server\share\1C_Base"
$backupDir = "D:\Backup\1C_File"
$timestamp = Get-Date -Format "yyyy-MM-dd_HHmm"

# Копируем всю папку базы
Copy-Item -Path $sourceDir -Destination "$backupDir\Base_$timestamp" -Recurse

# Сжимаем в архив
Compress-Archive -Path "$backupDir\Base_$timestamp" `
  -DestinationPath "$backupDir\Base_$timestamp.zip"

# Удаляем несжатую копию
Remove-Item -Path "$backupDir\Base_$timestamp" -Recurse -Force

Файловая база подходит для 1-5 пользователей. При 10+ пользователях переходите на клиент-серверный режим с SQL Server или PostgreSQL — и бэкапы станут проще (горячие, без остановки).

Автоматическое по расписанию

Любой из методов СУБД можно автоматизировать: планы обслуживания в SQL Server, cron-задания для PostgreSQL, скрипты PowerShell или bash. Настройка автоматического резервного копирования 1С 8.3 — обязательный шаг для продуктивных серверов. Ручные бэкапы забываются, автоматические — нет.

Резервное копирование средствами SQL Server

SQL Server поддерживает три типа бэкапов. Комбинация всех трёх даёт оптимальный баланс между размером копий и временем восстановления. Настройка бэкапа 1С 8.3 SQL начинается с понимания этих типов.

Полный бэкап базы 1С SQL. Создаёт полную копию базы данных. Работает без отключения пользователей. Для базы 1С размером 20 ГБ занимает 2-5 минут с сжатием.

-- Полный бэкап с сжатием
BACKUP DATABASE [MyBase1C]
TO DISK = N'D:\Backup\MyBase1C_full.bak'
WITH COMPRESSION, INIT,
     NAME = N'MyBase1C-Full',
     STATS = 10;

-- Проверка целостности бэкапа
RESTORE VERIFYONLY
FROM DISK = N'D:\Backup\MyBase1C_full.bak';

Дифференциальный бэкап. Копирует только страницы, изменённые с последнего полного бэкапа. При активной работе 50 пользователей за 4 часа изменяется 10-20% базы — дифференциальный бэкап в 5-10 раз меньше полного.

-- Дифференциальный бэкап
BACKUP DATABASE [MyBase1C]
TO DISK = N'D:\Backup\MyBase1C_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, INIT,
     NAME = N'MyBase1C-Diff',
     STATS = 10;

Бэкап лога транзакций. Необходим для point-in-time recovery — восстановления базы на конкретную секунду. Например, если в 14:35 кто-то удалил все документы, вы восстанавливаете базу на 14:34. Для этого модель восстановления базы должна быть FULL (не SIMPLE).

-- Проверить модель восстановления
SELECT name, recovery_model_desc
FROM sys.databases
WHERE name = 'MyBase1C';

-- Переключить на FULL (если SIMPLE)
ALTER DATABASE [MyBase1C] SET RECOVERY FULL;

-- Бэкап лога транзакций
BACKUP LOG [MyBase1C]
TO DISK = N'D:\Backup\MyBase1C_log.trn'
WITH COMPRESSION, INIT,
     NAME = N'MyBase1C-Log',
     STATS = 10;

Планы обслуживания SQL Server. В SQL Server Management Studio (SSMS) можно создать план обслуживания через графический интерфейс. Задачи Backup Database (Full), Backup Database (Differential), Backup Database (Transaction Log) — каждая по своему расписанию. План обслуживания запускается SQL Server Agent автоматически.

Рекомендуемое расписание для продуктивной базы 1С:

• Полный бэкап: ежедневно в 01:00 (минимум нагрузки)
• Дифференциальный: каждые 4 часа (06:00, 10:00, 14:00, 18:00, 22:00)
• Лог транзакций: каждые 15-30 минут

При таком расписании максимальная потеря данных — 15-30 минут. Для базы с 50+ пользователями это приемлемый RPO (Recovery Point Objective).

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

-- Восстановление полного бэкапа (с NORECOVERY — для последующих логов)
RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backup\MyBase1C_full.bak'
WITH NORECOVERY, REPLACE,
     MOVE N'MyBase1C' TO N'D:\MSSQL\Data\MyBase1C.mdf',
     MOVE N'MyBase1C_log' TO N'D:\MSSQL\Log\MyBase1C_log.ldf';

-- Восстановление дифференциального бэкапа
RESTORE DATABASE [MyBase1C]
FROM DISK = N'D:\Backup\MyBase1C_diff.bak'
WITH NORECOVERY;

-- Восстановление логов транзакций (по порядку)
RESTORE LOG [MyBase1C]
FROM DISK = N'D:\Backup\MyBase1C_log_1.trn'
WITH NORECOVERY;

-- Последний лог — с RECOVERY (база становится доступной)
RESTORE LOG [MyBase1C]
FROM DISK = N'D:\Backup\MyBase1C_log_2.trn'
WITH RECOVERY;

Для point-in-time recovery добавьте STOPAT = '2026-03-13T14:34:00' к последнему RESTORE LOG. База будет восстановлена до указанного момента — все изменения после 14:34 будут отброшены.

Резервное копирование средствами PostgreSQL

PostgreSQL предлагает два основных инструмента для бэкапа базы 1С: pg_dump (логический бэкап) и pg_basebackup (физический бэкап). Для типовых задач бэкапа 1С SQL на PostgreSQL достаточно pg_dump.

pg_dump — логический бэкап. Создаёт файл с SQL-командами для воссоздания базы. Работает без остановки пользователей. Поддерживает сжатие и параллельное выполнение.

# Бэкап в сжатый формат (custom)
pg_dump -h localhost -U postgres -Fc -Z 6 \
  -f /backup/mybase1c.dump mybase1c

# Бэкап в plain SQL (читаемый)
pg_dump -h localhost -U postgres -Fp -Z 6 \
  -f /backup/mybase1c.sql.gz mybase1c

# Параллельный бэкап (directory format, 4 потока)
pg_dump -h localhost -U postgres -Fd -j 4 \
  -f /backup/mybase1c_dir mybase1c

Параллельный бэкап (-j 4) на базе 20 ГБ ускоряет выгрузку в 2-3 раза. Используйте для баз больше 10 ГБ. Формат -Fc (custom) — оптимальный: сжатый, поддерживает выборочное восстановление, занимает меньше места.

pg_basebackup — физический бэкап всего кластера PostgreSQL. Копирует файлы данных напрямую. Используется для настройки репликации и point-in-time recovery через WAL-архивы.

# Физический бэкап всего кластера
pg_basebackup -h localhost -U postgres \
  -D /backup/pg_basebackup \
  -Ft -z -P

# -Ft — tar-формат
# -z — сжатие gzip
# -P — показывать прогресс

WAL-архивирование для point-in-time recovery. Для восстановления на конкретный момент времени в PostgreSQL настройте архивирование WAL-файлов. В postgresql.conf:

# postgresql.conf — включить WAL-архивирование
wal_level = replica
archive_mode = on
archive_command = 'cp %p /backup/wal_archive/%f'

После этого PostgreSQL будет копировать WAL-файлы (журналы транзакций) в указанный каталог. В сочетании с pg_basebackup это даёт возможность восстановить базу на любую секунду.

Восстановление из pg_dump. Команда зависит от формата бэкапа:

# Восстановление из custom-формата
pg_restore -h localhost -U postgres -d mybase1c_new \
  -C /backup/mybase1c.dump

# Восстановление из plain SQL
psql -h localhost -U postgres -d mybase1c_new \
  -f /backup/mybase1c.sql

# Параллельное восстановление (4 потока — для directory format)
pg_restore -h localhost -U postgres -d mybase1c_new \
  -j 4 /backup/mybase1c_dir

После восстановления базы зарегистрируйте её в кластере серверов 1С. Через утилиту rac: rac infobase --cluster=<uuid> create --name="MyBase1C" --dbms=PostgreSQL --db-server=localhost --db-name=mybase1c_new --db-user=postgres --db-pwd=***. Подробнее о работе с кластером — в руководстве по настройке кластера 1С.

Автоматизация бэкапов 1С

Ручной бэкап — бэкап, который однажды забудут сделать. Настройка автоматического резервного копирования 1С 8.3 — единственный надёжный подход. Скрипт + планировщик + ротация — три компонента автоматической системы.

Скрипт для Windows (PowerShell + SQL Server)

# backup-1c.ps1 — бэкап базы 1С средствами SQL Server
$server   = "localhost"
$database = "MyBase1C"
$backupDir = "D:\Backup\1C"
$daysToKeep = 14

# Имя файла с датой
$timestamp = Get-Date -Format "yyyy-MM-dd_HHmm"
$backupFile = "$backupDir\${database}_full_$timestamp.bak"

# Создать каталог если не существует
if (-not (Test-Path $backupDir)) { New-Item -ItemType Directory -Path $backupDir }

# Полный бэкап с сжатием
$sql = @"
BACKUP DATABASE [$database]
TO DISK = N'$backupFile'
WITH COMPRESSION, INIT,
     NAME = N'$database-Full-$timestamp',
     STATS = 10;
"@

Invoke-Sqlcmd -ServerInstance $server -Query $sql -QueryTimeout 3600

# Проверка
if (Test-Path $backupFile) {
    Write-Host "OK: $backupFile ($('{0:N0}' -f ((Get-Item $backupFile).Length / 1MB)) MB)"
} else {
    Write-Error "FAIL: backup file not created"
    exit 1
}

# Ротация: удалить файлы старше N дней
Get-ChildItem $backupDir -Filter "*.bak" |
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$daysToKeep) } |
    Remove-Item -Force

Добавьте в Планировщик задач Windows: создайте задачу с триггером «Ежедневно, 01:00», действие — powershell.exe -File D:\Scripts\backup-1c.ps1. Запускайте от учётной записи с правами на SQL Server (обычно sysadmin).

Скрипт для Linux (bash + PostgreSQL)

#!/bin/bash
# backup-1c.sh — бэкап базы 1С в PostgreSQL

DB_NAME="mybase1c"
DB_USER="postgres"
BACKUP_DIR="/backup/1c"
DAYS_TO_KEEP=14
TIMESTAMP=$(date +%Y-%m-%d_%H%M)
BACKUP_FILE="${BACKUP_DIR}/${DB_NAME}_full_${TIMESTAMP}.dump"

# Создать каталог
mkdir -p "$BACKUP_DIR"

# Бэкап в custom-формате со сжатием
pg_dump -h localhost -U "$DB_USER" -Fc -Z 6 \
  -f "$BACKUP_FILE" "$DB_NAME"

# Проверка
if [ -f "$BACKUP_FILE" ]; then
    SIZE=$(du -h "$BACKUP_FILE" | cut -f1)
    echo "OK: $BACKUP_FILE ($SIZE)"
else
    echo "FAIL: backup file not created" >&2
    exit 1
fi

# Ротация: удалить старые бэкапы
find "$BACKUP_DIR" -name "*.dump" -mtime +$DAYS_TO_KEEP -delete

echo "Backup completed: $(date)"

Добавьте в cron: crontab -e и впишите строку для ежедневного запуска в 01:00:

# Ежедневный бэкап 1С в 01:00
0 1 * * * /opt/scripts/backup-1c.sh >> /var/log/backup-1c.log 2>&1

Для файла .pgpass задайте пароль, чтобы скрипт не запрашивал его интерактивно: echo "localhost:5432:mybase1c:postgres:password" >> ~/.pgpass && chmod 600 ~/.pgpass.

Ротация старых копий

Без ротации бэкапы заполнят диск за неделю. Стратегия хранения зависит от требований бизнеса:

Итого: 23 файла вместо 365. Для базы 1С размером 20 ГБ со сжатием (коэффициент ~3-5x) это 100-150 ГБ дискового пространства. Скрипты ротации в примерах выше удаляют файлы старше 14 дней — минимальный вариант. Для расширенной ротации используйте утилиты logrotate (Linux) или собственный скрипт.

Бэкап нескольких баз 1С

На продуктивном сервере обычно работают несколько информационных баз: бухгалтерия, зарплата, управление торговлей, тестовая копия. Бэкапить нужно каждую. В SQL Server используйте T-SQL с курсором по списку баз:

-- Бэкап всех пользовательских баз SQL Server
DECLARE @dbname NVARCHAR(255), @path NVARCHAR(512)
DECLARE @timestamp NVARCHAR(20) = FORMAT(GETDATE(), 'yyyy-MM-dd_HHmm')

DECLARE db_cursor CURSOR FOR
SELECT name FROM sys.databases
WHERE database_id > 4  -- пропустить системные
  AND state = 0        -- только онлайн
  AND name NOT LIKE 'ReportServer%'

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @dbname
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @path = N'D:\Backup\' + @dbname + N'_full_' + @timestamp + N'.bak'
    BACKUP DATABASE @dbname TO DISK = @path
    WITH COMPRESSION, INIT, STATS = 10
    FETCH NEXT FROM db_cursor INTO @dbname
END
CLOSE db_cursor
DEALLOCATE db_cursor

Для PostgreSQL — цикл по базам в bash:

# Бэкап всех баз PostgreSQL (кроме системных)
DATABASES=$(psql -U postgres -t -c \
  "SELECT datname FROM pg_database WHERE datistemplate = false AND datname != 'postgres'")

for DB in $DATABASES; do
    pg_dump -U postgres -Fc -Z 6 \
      -f "/backup/${DB}_full_$(date +%Y-%m-%d_%H%M).dump" "$DB"
done

Копирование на удалённое хранилище

Локальный бэкап защищает от сбоя СУБД. Но не от отказа сервера, пожара или шифровальщика. Копируйте бэкапы на удалённое хранилище — минимум раз в сутки.

Варианты удалённого хранения:

• Сетевая папка (SMB/NFS): самый простой вариант. Второй сервер или NAS в той же сети. Бэкап SQL Server можно писать напрямую на UNC-путь: TO DISK = N'\\nas\backup\MyBase1C.bak'
• rsync / robocopy: копирование после создания бэкапа. Linux: rsync -az /backup/ user@remote:/backup/. Windows: robocopy D:\Backup \\nas\backup /MIR
• S3-совместимое хранилище: MinIO, Yandex Object Storage. Утилита aws s3 sync или rclone sync. Дёшево и надёжно для долгосрочного хранения

Правило 3-2-1: три копии данных, на двух разных типах носителей, одна копия — вне основной площадки. Для серверов 1С это: рабочая база + локальный бэкап + удалённая копия.

Типичные ошибки при резервном копировании 1С

Три ошибки, которые превращают бэкап из страховки в иллюзию защиты. Каждая из них встречается регулярно — даже у опытных администраторов.

Бэкап без проверки восстановления

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

Файл повреждён, права доступа сменились, скрипт молча падал три месяца. Администратор узнаёт об этом в самый неподходящий момент — когда база уже потеряна.

Решение: ежемесячное тестовое восстановление. SQL Server: RESTORE VERIFYONLY FROM DISK = N'path\backup.bak' — проверяет целостность без восстановления. Но этого недостаточно — VERIFYONLY проверяет структуру файла, а не данные.

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

Для PostgreSQL: pg_restore --list /backup/mybase1c.dump проверяет содержимое дампа без восстановления. Полная проверка — восстановить в тестовую базу и открыть в 1С. Занимает 15-30 минут, но исключает неприятный сюрприз в момент аварии.

Хранение копий на том же диске

Бэкап базы 1С на тот же RAID-массив, где лежит СУБД — не бэкап. Отказ контроллера RAID, пожар, шифровальщик — и вы теряете и базу, и все копии одновременно.

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

Блокировки при горячем бэкапе

Бэкап СУБД работает без остановки пользователей, но создаёт дополнительную нагрузку на дисковую подсистему. На серверах со слабыми дисками (SAS 10K) полный бэкап базы 20 ГБ может замедлить работу пользователей на 10-15 минут.

Решение: запускайте полный бэкап в ночное время, когда пользователей нет. Дифференциальные бэкапы днём — они в 5-10 раз легче и практически не влияют на работу.

На серверах с NVMe-дисками проблема практически отсутствует — бэкап базы 20 ГБ занимает 1-2 минуты без заметного влияния на пользователей. На SAS-дисках тот же бэкап занимает 10-15 минут с ощутимым замедлением. Подробнее о влиянии типа диска на производительность — в требованиях к серверу для 1С.

Вопросы и ответы

Три элемента надёжного бэкапа 1С

Резервное копирование 1С 8.3 — три обязательных элемента. Первый: бэкап средствами СУБД (SQL Server или PostgreSQL), а не через Конфигуратор — быстрее, без простоя пользователей, поддерживает дифференциальные копии. Второй: автоматизация — скрипт по расписанию с ротацией старых копий. Третий: хранение вне сервера по правилу 3-2-1.

Производительность бэкапа зависит от оборудования. На серверах с NVMe полный бэкап базы 20 ГБ занимает 1-2 минуты, на SAS — 10-15 минут. Дисковая подсистема влияет и на скорость восстановления — а это время простоя бизнеса.

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

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

Не уверены, что текущий сервер потянет бэкап без просадки для пользователей? Пришлите профиль базы (размер, число пользователей, версия СУБД) — бесплатно посчитаем конфигурацию под вашу нагрузку.