Резервное копирование высоконагруженной базы 1С: как не останавливать работу и не терять данные
Ты открываешь настройки резервного копирования в конфигураторе, видишь кнопку «Выгрузить информационную базу» — и понимаешь, что это не вариант. База 200 ГБ, 150 активных пользователей, окно обслуживания — ноль. Стандартные инструменты платформы сделаны для другого размера задач. Для высоконагруженной базы нужна другая архитектура резервирования.
Почему стандартный dt-бэкап не работает при нагрузке
Выгрузка в .dt делает логическую копию: блокирует базу, читает все объекты, сериализует. При базе больше 20–30 ГБ это занимает часы. Пользователи не могут работать. На файловой базе это вообще единственный способ, но файловая база при высокой нагрузке — это уже само по себе архитектурная проблема.
Для клиент-серверного варианта (SQL Server или PostgreSQL) правильный ответ — бэкап на уровне СУБД, а не через инструменты 1С.
SQL Server: три уровня защиты
Full backup — полная копия, база онлайн, пользователи работают. SQL Server использует теневое копирование, и для базы 200 ГБ это занимает 20–40 минут в зависимости от диска. Делай раз в сутки, ночью.
BACKUP DATABASE [my_1c_base]
TO DISK = N'D:\Backups\my_1c_base_full.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;Differential backup — только изменения с последнего full. Размер и время: 5–15% от full. Делай каждые 2–4 часа.
Log backup — бэкап журнала транзакций, при модели восстановления FULL. Позволяет восстановить базу на любой момент времени. Делай каждые 15–30 минут. Это ключ к точечному восстановлению (point-in-time recovery).
-- Переключи модель восстановления, если ещё SIMPLE
ALTER DATABASE [my_1c_base] SET RECOVERY FULL;
-- Регулярный бэкап лога
BACKUP LOG [my_1c_base]
TO DISK = N'D:\Backups\my_1c_base_log.bak'
WITH COMPRESSION;Все три типа бэкапа SQL Server делает без остановки работы пользователей. Именно поэтому клиент-серверный вариант — единственный правильный выбор для нагруженной базы.
PostgreSQL: аналогичная схема
Для PostgreSQL-варианта:
# Физический бэкап через pg_basebackup (онлайн, без остановки)
pg_basebackup -D /backup/base -Ft -z -P -Xs -c fast
# WAL-архивирование для point-in-time recovery
# В postgresql.conf:
archive_mode = on
archive_command = 'cp %p /backup/wal/%f'
wal_level = replicapg_basebackup создаёт консистентный снимок работающей базы. WAL-архивирование — аналог log backup в SQL Server.
Автоматизация и контроль
Бэкап без проверки — это не бэкап. Два обязательных элемента:
Проверка целостности. SQL Server:
RESTORE VERIFYONLY FROM DISK = N'D:\Backups\my_1c_base_full.bak'
WITH CHECKSUM;Добавь в расписание сразу после каждого бэкапа.
Тестовое восстановление. Раз в месяц разворачивай бэкап на отдельный сервер и проверяй, что 1С запускается и данные на месте. Без этого ты не знаешь, работает ли твоя схема.
Мониторинг. Создай SQL Agent Job для каждого типа бэкапа и настрой уведомления на провал. Стандартная ошибка — «бэкапы работали полгода, потом диск заполнился, скрипт начал падать, никто не заметил».
Когда нужен Always On или зеркалирование
Если требование — восстановление за минуты (RTO < 5 мин) или потеря данных не более 1 минуты (RPO < 1 мин) — бэкапы не спасут. Нужен SQL Server Always On Availability Groups или репликация PostgreSQL. Это отдельная тема, но знай: Always On — это не замена бэкапам, это добавление к ним.
Если ты на файловом варианте и думаешь «а вдруг и так сойдёт» — переходи на клиент-серверный при первой возможности. Это не просто удобство, это базовая гигиена для любой базы, где работает больше 10 человек. Файловый вариант при нагрузке теряет данные тихо и необратимо.
Если проблема с конкретной реализацией бэкапа на SQL Server — покажи план обслуживания или скрипты, и сообщество поможет. Обычно ошибки прячутся в правах доступа к папке бэкапа или в переполнении диска.
Оригинал: https://darachubarova.github.io/infostart-agent/posts/forum_forum9_highload-1c-backup/
Перейти в каталог решений