Как создать дубликат базы данных MS SQL для 1С для отказоустойчивости?

Нередко перед системными администраторами, обслуживающими инфраструктуру 1С, встает задача обеспечить непрерывность работы бизнеса. Обычных резервных копий может быть недостаточно, если время простоя критично. Возникает вопрос: как создать "горячий" или "теплый" дубликат базы данных MS SQL, на который можно было бы быстро переключиться в случае сбоя основного сервера? При этом желательно обойтись "малой кровью", без привлечения дорогостоящих специалистов и покупки лицензий Enterprise-уровня.

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

Анализ ситуации: почему старые методы не подходят и что выбрать?

В первом сообщении автор упоминает технологию зеркалирования (Database Mirroring). Важно понимать, что Microsoft объявила эту технологию устаревшей (deprecated). Она все еще поддерживается в некоторых версиях MS SQL Server, но не рекомендуется для новых внедрений и будет удалена в будущих версиях. Поэтому строить новую систему на ее основе — неперспективно.

Современными и рекомендуемыми технологиями для обеспечения высокой доступности являются Always On Availability Groups и более простая в настройке Доставка журналов (Log Shipping). Проанализируем оба варианта, чтобы понять, какой из них подходит для нашей задачи.

Always On Availability Groups: мощное, но затратное решение

Always On Availability Groups (Группы доступности Always On) — это флагманская технология Microsoft для обеспечения высокой доступности и аварийного восстановления. Она представляет собой эволюцию зеркалирования и кластеризации.

Ключевые преимущества:

• Автоматическое переключение. В синхронном режиме при сбое основного сервера система может автоматически, за несколько секунд, переключить всю нагрузку на резервный сервер. Это минимизирует время простоя до предела.
• Читаемые копии. Резервные копии базы (реплики) могут быть доступны для чтения. Это позволяет снимать с них "тяжелые" отчеты, не нагружая основной рабочий сервер.
• Группировка баз. Можно объединить несколько баз данных в одну группу, и они будут переключаться вместе, что важно для сложных конфигураций 1С, использующих несколько баз.

Однако, как справедливо заметили на форуме, это решение весьма затратно. Вот его основные требования:

1. Лицензии. Для полноценной работы с автоматическим переключением требуется редакция MS SQL Server Enterprise. Стоимость таких лицензий значительно выше, чем у Standard.
2. Кластер Windows Server. Для автоматизации процесса переключения необходим отказоустойчивый кластер Windows Server (WSFC), что также требует лицензий Windows Server Datacenter и сложной настройки.
3. Аппаратное обеспечение. Нужен как минимум еще один сервер, сопоставимый по мощности с основным, а для надежности кворума часто и третий узел.
4. Квалификация. Настройка и поддержка такой системы требует глубоких знаний в администрировании Windows Server и MS SQL Server.

Вывод: Always On — это промышленный стандарт для критически важных систем, где даже несколько минут простоя недопустимы. Для задачи "сделать малой кровью" без DBA этот вариант не подходит из-за высокой стоимости и сложности.

Доставка журналов (Log Shipping): оптимальный баланс цены и надежности

Этот метод был очень точно описан в одном из сообщений на форуме. Доставка журналов (Log Shipping) — это процесс автоматизации резервного копирования журналов транзакций с основного сервера и их последующего восстановления на резервном. Это позволяет поддерживать резервную базу данных в актуальном состоянии с небольшой задержкой.

Это решение идеально подходит для нашей задачи, так как оно:

• Доступно в редакции Standard. Не требует покупки дорогих лицензий Enterprise.
• Не требует кластера. Настройка выполняется стандартными средствами SQL Server Management Studio.
• Просто в понимании и поддержке. Механика процесса прозрачна: бэкап лога -> копирование -> восстановление лога.

Рассмотрим по шагам, как настроить доставку журналов для базы 1С.

Шаг 1. Подготовка основной базы данных

Для работы Log Shipping база данных на основном сервере (primary) должна использовать полную модель восстановления (Full recovery model). Это позволяет вести журнал транзакций, который мы и будем копировать.

1. Откройте SQL Server Management Studio (SSMS) и подключитесь к основному серверу.
2. Найдите вашу базу 1С, кликните по ней правой кнопкой мыши и выберите "Свойства" (Properties).
3. Перейдите на вкладку "Параметры" (Options).
4. В поле "Модель восстановления" (Recovery model) выберите значение Full и сохраните изменения.

Шаг 2. Создание начальной резервной копии

Теперь нужно создать полную резервную копию основной базы, чтобы развернуть ее на резервном сервере.

-- Пример T-SQL запроса для создания бэкапа

BACKUP DATABASE [ИмяВашейБазы] 
TO DISK = 'C:\Backup\ИмяВашейБазы_full.bak' 
WITH NOFORMAT, INIT, NAME = 'ИмяВашейБазы-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10;

После создания скопируйте этот файл бэкапа на резервный сервер (secondary).

Шаг 3. Восстановление базы на резервном сервере

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

• WITH NORECOVERY: База данных после восстановления будет находиться в состоянии "Restoring..." и будет недоступна для подключения до момента ее окончательного перевода в рабочий режим. Это самый простой вариант.
• WITH STANDBY: База данных будет в режиме "только для чтения". Пользователи смогут к ней подключаться и, например, строить отчеты. При каждом восстановлении очередного лога транзакций все активные подключения к базе будут принудительно разорваны.

Для нашей задачи простого резервирования достаточно режима NORECOVERY.

-- Пример T-SQL запроса для восстановления

RESTORE DATABASE [ИмяВашейБазы] 
FROM DISK = 'D:\Restore\ИмяВашейБазы_full.bak' 
WITH MOVE 'ИмяФайлаДанных_Data' TO 'D:\Data\ИмяВашейБазы.mdf',
MOVE 'ИмяФайлаЛогов_Log' TO 'D:\Log\ИмяВашейБазы_log.ldf',
NORECOVERY, NOUNLOAD, STATS = 5;

Важно: Пути к файлам базы (.mdf и .ldf) на резервном сервере могут отличаться от путей на основном. Укажите корректные пути в секции WITH MOVE.

Шаг 4. Настройка Log Shipping

Теперь, когда основа заложена, можно настроить автоматизацию. Это удобно сделать через графический интерфейс SSMS.

1. На основном сервере кликните правой кнопкой мыши по базе -> "Задачи" (Tasks) -> "Доставка журналов транзакций" (Ship Transaction Logs).
2. Установите флажок "Включить эту базу данных в качестве основной в конфигурации доставки журналов" (Enable this as a primary database...).
3. Настройка заданий резервного копирования (Backup Settings): Укажите сетевую папку, куда будут сохраняться бэкапы логов (например, `\\PrimaryServer\Backup`), и локальный путь. Задайте расписание. Частота бэкапа логов определяет максимальный объем данных, который вы можете потерять при сбое. Обычно ставят 5-15 минут.
4. Настройка резервных серверов (Secondary Server Instances): Нажмите "Add" и подключитесь к вашему резервному серверу.
5. На вкладке "Initialize Secondary Database" выберите "No, the secondary database is initialized", так как мы уже восстановили ее вручную.
6. На вкладке "Copy Files" укажите папку на резервном сервере, куда будут копироваться файлы бэкапов логов. Настройте расписание задания копирования (обычно такое же, как у бэкапа).
7. На вкладке "Restore Transaction Log" выберите режим состояния базы (No recovery mode или Standby mode). Настройте расписание восстановления. Можно поставить небольшую задержку после копирования.
8. Сохраните конфигурацию. SSMS автоматически создаст все необходимые задания (Jobs) на обоих серверах.

После этого процесс будет работать автоматически. Вы можете следить за его состоянием через "Log Shipping Monitor".

Процедура переключения при сбое и возврата в штатный режим

Итак, основной сервер вышел из строя. Переключение на резервный сервер при использовании Log Shipping выполняется вручную.

Переключение на резервную базу:

1. Если основной сервер еще хоть как-то доступен, попытайтесь сделать финальный бэкап "хвоста" журнала транзакций (tail-log backup). Это позволит не потерять самые последние транзакции.
   BACKUP LOG [ИмяВашейБазы] TO DISK = '...' WITH NORECOVERY;
2. Убедитесь, что все доступные бэкапы логов (включая "хвост", если удалось его сделать) скопированы и восстановлены на резервном сервере.
3. Переведите резервную базу в рабочий режим. Для этого выполните команду:
   RESTORE DATABASE [ИмяВашейБазы] WITH RECOVERY;
4. После этого база станет доступной для чтения и записи. Измените строку подключения на сервере 1С, чтобы пользователи начали работать с резервным сервером.

Восстановление и возврат на основной сервер:

Когда основной сервер будет починен, нужно вернуть все "как было".

1. На сервере, который теперь является основным (бывшем резервном), сделайте полную резервную копию.
2. На старом (починенном) основном сервере восстановите эту новую резервную копию.
3. Теперь вы можете либо сразу переключить 1С обратно (если это можно сделать в нерабочее время), либо настроить Log Shipping в обратном направлении (с бывшего резервного на бывший основной), чтобы синхронизировать данные и выполнить переключение с минимальным простоем.

Вывод: Метод доставки журналов транзакций (Log Shipping) является наиболее сбалансированным решением для создания "теплого" резерва базы данных 1С на MS SQL без значительных затрат и сложных настроек. Он позволяет быстро восстановить работу системы с минимальными потерями данных, что полностью соответствует запросу "сделать малой кровью".