Как настроить репликацию и резервирование баз данных 1С на MS SQL Express между двумя серверами?

← На главную

При работе с базами данных 1С:Предприятие часто возникает задача обеспечения отказоустойчивости. Бизнес требует, чтобы в случае выхода из строя основного сервера систему можно было запустить на резервном оборудовании с минимальными потерями данных и в кратчайшие сроки (в пределах 1–2 часов). Однако, когда инфраструктура построена на бесплатной СУБД MS SQL Server Express Edition, стандартные высокотехнологичные инструменты СУБД (такие как репликация AlwaysOn или встроенный механизм Log Shipping) оказываются недоступны.

В этой статье мы подробно разберем, как обойти аппаратные и программные ограничения MS SQL Express, какие существуют рабочие схемы резервирования баз данных 1С и как автоматизировать процесс актуализации резервного сервера.

Ограничения MS SQL Express, о которых нужно знать заранее

Перед тем как проектировать отказоустойчивую систему, проанализируем архитектурные ограничения редакции MS SQL Express:

Отсутствие SQL Server Agent. В бесплатной редакции нет встроенного планировщика задач. Это значит, что любые регламентные операции (бэкапы, индексация, очистка логов) невозможно настроить стандартными средствами СУБД. Нам придется использовать сторонние планировщики, например, встроенный Task Scheduler (Планировщик задач Windows).
Отсутствие встроенной репликации и AlwaysOn. СУБД MS SQL Express не поддерживает технологии транзакционной репликации, репликации слиянием или создание групп доступности (Availability Groups).
Лимит на размер базы данных. Максимальный размер одной реляционной базы данных (файла .mdf) в версии Express ограничен 10 ГБ. Обратите внимание, что файл лога транзакций (.ldf) в этот лимит не входит, но если сама база превысит 10 ГБ, СУБД заблокирует запись. Если ваша база 1С приближается к 8–9 ГБ, вам необходимо заранее рассмотреть переход на другие СУБД (например, PostgreSQL) или коммерческую версию MS SQL Standard.

Учитывая эти ограничения, рассмотрим проверенные практические схемы резервирования.

Схема 1. Регулярное создание и загрузка разностных бэкапов (классический подход)

Проанализируем наиболее популярную и отказоустойчивую схему, которая позволяет минимизировать потерю данных до 1 часа, а время переключения (RTO) сократить до 15–30 минут.

Суть схемы: На основном сервере разворачивается рабочая база 1С, на резервном сервере СУБД находится в режиме ожидания (служба сервера 1С на нем остановлена или "спит", чтобы избежать конфликтов и случайного изменения данных пользователями).

Разберем регламент создания копий по шагам:

Создание полной копии (Full Backup): Каждую ночь (например, в 04:00) на основном сервере средствами скриптов запускается создание полного резервного копирования базы данных.
Создание разностных копий (Differential Backup): В течение дня с интервалом в один час (например, с 05:00 до 23:00) создаются разностные копии базы. Разностный бэкап фиксирует только те изменения, которые произошли в базе с момента создания последнего полного бэкапа.
Копирование файлов на резервный сервер: Сразу после создания файлы бэкапов копируются по локальной сети на резервный сервер. Для этого отлично подходит утилита robocopy, которая умеет передавать только новые или изменившиеся файлы.
Восстановление данных на резервном сервере: На резервном сервере запускается автоматический скрипт, который восстанавливает ночную полную копию, а затем поверх нее накатывает последний актуальный разностный бэкап. Это позволяет всегда иметь "горячую" базу, отстающую от рабочей максимум на 1 час.

Рассмотрим пример скрипта резервного копирования. Поскольку службы SQL Server Agent нет, мы будем вызывать утилиту командной строки sqlcmd через cmd-файл, запускаемый планировщиком Windows.

Пример скрипта для создания полного бэкапа (выполняется в 04:00):


sqlcmd -S SERVER1\SQLEXPRESS -E -Q "BACKUP DATABASE [Trade1C] TO DISK = N'D:\Backup\Trade1C_Full.bak' WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10"

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


sqlcmd -S SERVER1\SQLEXPRESS -E -Q "BACKUP DATABASE [Trade1C] TO DISK = N'D:\Backup\Trade1C_Diff.bak' WITH DIFFERENTIAL, FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD, STATS = 10"

После создания файлов выполняем копирование на резервный сервер (SERVER2):

robocopy "D:\Backup" "\\SERVER2\BackupShare" /MIR /R:3 /W:5

На резервном сервере (SERVER2) скрипт восстанавливает базу. Сначала восстанавливаем полный бэкап с параметром NORECOVERY (это указывает SQL-серверу, что процесс восстановления не завершен и база пока не готова принимать подключения, ожидая разностный бэкап):


sqlcmd -S SERVER2\SQLEXPRESS -E -Q "RESTORE DATABASE [Trade1C] FROM DISK = N'C:\BackupShare\Trade1C_Full.bak' WITH FILE = 1, NORECOVERY, REPLACE"

Затем накатываем разностный бэкап и переводим базу в рабочий режим (параметр RECOVERY):


sqlcmd -S SERVER2\SQLEXPRESS -E -Q "RESTORE DATABASE [Trade1C] FROM DISK = N'C:\BackupShare\Trade1C_Diff.bak' WITH FILE = 1, RECOVERY"

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

Схема 2. Кастомный Log Shipping (доставка журналов транзакций)

Если для бизнеса критичен часовой лаг потери данных, и вы хотите сократить его до 10–15 минут, схема с разностными бэкапами может не подойти. В разностных бэкапах есть серьезный минус: каждый последующий разностный бэкап в течение дня увеличивается в размере, так как содержит в себе все изменения с ночи. При интенсивной работе к вечеру разностный бэкап может весить почти столько же, сколько вся база.

Выясним, как реализовать аналог профессионального механизма Log Shipping на базе MS SQL Express.

Для этого нам необходимо перевести базу данных 1С в модель восстановления FULL (Полная). В отличие от модели SIMPLE (Простая), в полной модели транзакции не очищаются из лога автоматически, и мы можем делать резервные копии самого журнала транзакций (файлы .trn).

Разберем алгоритм работы кастомного Log Shipping:

Один раз в сутки создаем полный бэкап базы данных и восстанавливаем его на резервном сервере с флагом WITH NORECOVERY. База на резервном сервере переходит в состояние Restoring.
Каждые 10–15 минут на основном сервере делаем бэкап журнала транзакций:
```
sqlcmd -S SERVER1\SQLEXPRESS -E -Q "BACKUP LOG [Trade1C] TO DISK = N'D:\Backup\Trade_Log.trn' WITH FORMAT, INIT"
```
Переносим файл Trade_Log.trn на резервный сервер.
Накатываем лог на резервную базу, сохраняя её в состоянии восстановления:
```
sqlcmd -S SERVER2\SQLEXPRESS -E -Q "RESTORE LOG [Trade1C] FROM DISK = N'C:\BackupShare\Trade_Log.trn' WITH NORECOVERY"
```

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

В случае аварии на основном сервере, администратор выполняет на резервном сервере финальную команду восстановления, которая открывает базу для работы пользователей:

sqlcmd -S SERVER2\SQLEXPRESS -E -Q "RESTORE DATABASE [Trade1C] WITH RECOVERY"

Внимание! При использовании модели восстановления FULL обязательно следите за тем, чтобы бэкапы логов транзакций выполнялись без сбоев. Если бэкап лога перестанет выполняться, файл лога (.ldf) будет разрастаться бесконтрольно, пока не займет все дисковое пространство основного сервера.

Схема 3. Репликация на уровне виртуальных машин (Hyper-V / VMware)

Рассмотрим альтернативный вариант, когда резервирование настраивается не на уровне СУБД, а на уровне виртуализации. Если ваши серверы 1С и СУБД работают внутри виртуальных машин (например, на Hyper-V или VMware ESXi), можно настроить встроенную репликацию виртуальных машин на второй физический сервер-гипервизор.

Однако здесь кроется критически важный нюанс. При обычной репликации виртуальной машины файлы дисков копируются посекторно (режим Crash-Consistent). Если запустить такую реплику после аварии, SQL Server воспримет это как некорректное выключение питания. В базах 1С могут возникнуть логические ошибки, битые индексы или незавершенные транзакции.

Чтобы репликация виртуальной машины СУБД была безопасной, придерживайтесь следующих правил:

Настройте репликацию в режиме Application-Consistent (согласованная на уровне приложений).
Для этого в настройках репликации Hyper-V или VMware необходимо активировать интеграцию со службой теневого копирования тома Windows — VSS (Volume Shadow Copy Service).
При создании контрольной точки репликации служба VSS будет временно приостанавливать запись в SQL-сервере, сбрасывать все транзакции из оперативной памяти на диск и только после этого делать снимок. Это гарантирует полную целостность базы 1С на резервном сервере при его запуске.

Стоит ли использовать РИБ (Распределенные информационные базы) для резервирования?

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

Однако использовать РИБ исключительно как средство создания резервного сервера крайне не рекомендуется по следующим причинам:

Сложность контроля актуальности. В РИБ данные передаются пакетами через XML-файлы. Если в конфигурацию вносятся изменения, обмен может заблокироваться до тех пор, пока конфигурация на резервном узле не обновится.
Проблема коллизий. Если пользователи случайно зайдут в резервную базу и внесут туда данные параллельно с основной базой, при последующей синхронизации возникнет конфликт данных, который придется решать вручную.
Нагрузка на систему. Постоянная регистрация изменений для планов обмена создает дополнительную нагрузку на и без того ограниченный в ресурсах MS SQL Express.

Механизмы резервного копирования и восстановления СУБД (модели бэкапов) являются гораздо более надежными, простыми в администрировании и гарантируют 100% идентичность данных без участия прикладных механизмов 1С.

Сравнение альтернативных решений

Если ограничения MS SQL Express не позволяют вам построить надежную систему (например, база превысила 10 ГБ или требуется полноценная автоматическая репликация без написания скриптов), проанализируем альтернативные варианты:

Переход на PostgreSQL. Бесплатная СУБД PostgreSQL (в сборке для 1С) не имеет ограничений на размер базы данных и оперативную память. Она поддерживает встроенную потоковую репликацию (Streaming Replication) по схеме Master-Standby. WAL-файлы (журналы предзаписи) непрерывно передаются на резервный сервер, что сводит потенциальную потерю данных к долям секунды, а перевод реплики в рабочий режим выполняется одной быстрой командой pg_ctl promote.
Апгрейд до MS SQL Server Standard. Если бюджет компании позволяет приобрести коммерческую лицензию SQL Standard, вы получите доступ к технологии Basic AlwaysOn (Базовые группы доступности). Она позволяет настроить отказоустойчивый кластер СУБД из двух узлов с автоматическим переключением клиентов при падении основного сервера (время простоя сокращается до нескольких секунд, ручное вмешательство администратора не требуется).

Резюме и рекомендации

Для реализации резервирования базы 1С на MS SQL Express в течение 1–2 часов рекомендуем внедрить схему с полными ночными и ежечасными разностными бэкапами, автоматизированную через Планировщик задач Windows и утилиту sqlcmd. Это простое, бесплатное и надежное решение, проверенное годами эксплуатации в фирмах малого и среднего бизнеса.