Настройка MS SQL Server Log Shipping для отказоустойчивости и DR

Настройка MS SQL Server Log Shipping для репликации

Представьте: primary база вышла из строя в час пик, а бэкапы — от вчерашнего дня. Потеря данных — 12 часов. Альтернатива — Log Shipping. Асинхронная репликация transaction log с secondary сервера, где резервная копия обновляется каждые 15–30 минут. RPO — 15 минут, RTO — 5–10 минут на failover. Без лицензий Enterprise и дорогого оборудования.

Наши инженеры с 10+ летним опытом внедряют DR-решения для SQL Server, где бюджет на Always On AG или FCI отсутствует. Log Shipping — проверенный механизм, работающий с SQL Server 2000 и до последних версий. Принцип прост: primary сервер бэкапит transaction log, копирует файл на secondary, secondary восстанавливает его. Всё через SQL Server Agent jobs, без дополнительной инфраструктуры.

Почему Log Shipping — надежное решение для DR?

Log Shipping даёт экономию по сравнению с Always On AG: стоимость внедрения в 3–5 раз ниже, не требует Enterprise-лицензий и одинакового железа. При этом RPO 15–30 минут удовлетворяет большинство бизнес-требований. Асинхронность — компромисс: при аварии теряется последний незаархивированный интервал. Но это плата за бюджетность. Для критичных систем с нулевой потерей данных — Always On AG, но для типовых DR — Log Shipping оптимален.

Как это работает и где типично ломается

Три job'а: backup (на primary), copy (на secondary), restore (на secondary). Опционально — monitor server, который отслеживает отставание и алертит при проблемах.

Самая частая ошибка при самостоятельной настройке — backup job работает, copy job молчит, в Error Log на secondary: Cannot open backup device '\\PRIMARY\LogShipping\AppDB_20240315_0230.bak'. Operating system error 5. Диагностика — Access Denied на share. SQL Server Agent на secondary работает под учёткой без прав на UNC-путь primary. Мы решаем это настройкой share permissions или сменой сервисного аккаунта. Подобные кейсы — наш ежедневный опыт.

Документация Microsoft рекомендует использовать отдельную учётную запись для SQL Server Agent с минимальными правами на UNC-путь.

Пример скрипта мониторинга:

-- Проверка состояния log shipping после настройки
SELECT primary_server, primary_database, last_backup_file, last_backup_date,
       DATEDIFF(MINUTE, last_backup_date, GETDATE()) AS minutes_since_backup
FROM msdb.dbo.log_shipping_monitor_primary;

SELECT secondary_server, secondary_database, last_restored_file, last_restored_date,
       restore_threshold,
       DATEDIFF(MINUTE, last_restored_date, GETDATE()) AS minutes_since_restore
FROM msdb.dbo.log_shipping_monitor_secondary;

Как настроить Log Shipping с минимальным RPO?

Настройка через T-SQL — воспроизводимый подход. GUI в SSMS удобен для ознакомления, но для автоматизации — только скрипты.

На primary сервере инициализируем backup job:

-- На primary: настройка backup job
EXEC msdb.dbo.sp_add_log_shipping_primary_database
    @database = N'AppDB',
    @backup_directory = N'\\SQLPRIMARY\LogShipping',
    @backup_share = N'\\SQLPRIMARY\LogShipping',
    @backup_job_name = N'LSBackup_AppDB',
    @backup_retention_period = 4320,
    @backup_threshold = 60,
    @threshold_alert_enabled = 1,
    @history_retention_period = 5760,
    @backup_compression = 1,
    @primary_id = @LS_BackupJobId OUTPUT;

На secondary — copy и restore jobs:

-- На secondary: настройка copy + restore
EXEC msdb.dbo.sp_add_log_shipping_secondary_primary
    @primary_server = N'SQLPRIMARY',
    @primary_database = N'AppDB',
    @backup_source_directory = N'\\SQLPRIMARY\LogShipping',
    @backup_destination_directory = N'D:\LogShippingLocal',
    @copy_job_name = N'LSCopy_SQLPRIMARY_AppDB',
    @restore_job_name = N'LSRestore_SQLPRIMARY_AppDB',
    @file_retention_period = 4320,
    @secondary_id = @LS_Secondary OUTPUT;

EXEC msdb.dbo.sp_add_log_shipping_secondary_database
    @secondary_database = N'AppDB',
    @primary_server = N'SQLPRIMARY',
    @primary_database = N'AppDB',
    @restore_delay = 0,
    @restore_mode = 1,
    @disconnect_users = 0,
    @restore_threshold = 45,
    @threshold_alert_enabled = 1,
    @history_retention_period = 5760,
    @secondary_id = @LS_Secondary;

@restore_mode = 1 (STANDBY) разрешает чтение secondary между восстановлениями — удобно для отчётов. @restore_mode = 0 (NORECOVERY) даёт минимальный RTO при failover. @restore_delay — задержка применения логов. Защита от случайного DROP TABLE: ставим задержку 60 минут — есть час, чтобы остановить restore и вытащить данные.

Инициализация secondary базы

Перед запуском log shipping восстанавливаем полный бэкап primary на secondary в NORECOVERY:

-- На primary: полный бэкап
BACKUP DATABASE AppDB TO DISK = N'\\SQLPRIMARY\LogShipping\AppDB_init.bak' WITH COMPRESSION, STATS = 10;

-- На secondary: восстановление
RESTORE DATABASE AppDB FROM DISK = N'\\SQLPRIMARY\LogShipping\AppDB_init.bak' WITH NORECOVERY, MOVE 'AppDB' TO 'D:\SQLData\AppDB.mdf', MOVE 'AppDB_log' TO 'D:\SQLLog\AppDB_log.ldf', STATS = 10;

После этого запускаем jobs — они начнут копировать и применять transaction log файлы. Типовые сроки настройки: одна база — 1 день, несколько баз с monitor сервером — 2-3 дня, миграция — до 3 дней.

Switchover при failover

-- На secondary при failover:
-- 1. Применить все доступные логи вручную
RESTORE LOG AppDB FROM DISK = N'D:\LogShippingLocal\AppDB_last.trn' WITH NORECOVERY;
-- 2. Вывести базу в онлайн
RESTORE DATABASE AppDB WITH RECOVERY;
-- 3. Переключить connection string приложения на secondary сервер

Сравнение: Log Shipping vs Always On AG

Типичные RPO/RTO в зависимости от конфигурации

-- Детальный мониторинг отставания
SELECT db.name, ls.primary_database, ls.last_backup_date, ls.last_restored_date,
       DATEDIFF(MINUTE, ls.last_backup_date, GETDATE()) AS backup_age_min,
       DATEDIFF(MINUTE, ls.last_restored_date, GETDATE()) AS restore_age_min
FROM sys.databases db
JOIN msdb.dbo.log_shipping_monitor_primary ls ON db.name = ls.primary_database;

Что входит в работу

• Аудит текущей инфраструктуры SQL Server
• Настройка backup/copy/restore jobs
• Конфигурация monitor сервера с алертами
• Тестирование failover и switchback
• Документация и Runbook по восстановлению
• Обучение дежурной смены

Наши инженеры имеют сертификаты Microsoft и более 50 успешных проектов по Log Shipping. Получите консультацию — оценим вашу задачу и предложим оптимальную схему репликации.

Типичные ошибки при настройке

• Неправильные права на UNC-путь (Access Denied)
• Отсутствие NORECOVERY при инициализации secondary
• Неверный restore_delay — данные могут быть потеряны при быстром failover
• Игнорирование мониторинга отставания — проблема становится заметной только при аварии

Для исключения этих проблем свяжитесь с нами — мы настроим Log Shipping под ключ за 1-3 дня в зависимости от сложности.