Автоматизация процесса переноса базы данных с рабочего сервера (источника) на резервный (приемник) является критически важной задачей для обеспечения отказоустойчивости и возможности тестирования на актуальных данных. Рассмотрим подробную схему реализации этой задачи для стека Windows Server 2016 и SQL Server 2016, которая позволит выполнять процесс ежедневно без ручного вмешательства.
Типичная задача подразумевает наличие основного сервера 1С и SQL и аналогичного резервного сервера. Основная сложность заключается не в самом создании бэкапа, а в обеспечении работоспособности базы на приемнике «без лишних телодвижений»: исправлении прав владельца, сопоставлении пользователей и корректном подключении к кластеру 1С. Мы проанализируем несколько способов реализации: от классических T-SQL скриптов до современных инструментов автоматизации.
Важное замечание: Для баз большого объема (от 100 ГБ и выше) использование выгрузки в .dt крайне не рекомендуется. Этот процесс занимает много времени, создает высокую нагрузку на дисковую подсистему и менее надежен по сравнению с нативными средствами SQL Server.
Этот метод является классическим и наиболее надежным. Он не требует стороннего ПО и работает на уровне встроенного планировщика SQL Agent. Разберем по шагам создание цепочки заданий.
Шаг 1. Создание резервной копии на источнике. На основном сервере создаем Job, который выполняет следующий скрипт:
BACKUP DATABASE [Work_Base]
TO DISK = N'\\NetworkShare\Backups\Work_Base_daily.bak'
WITH INIT, COMPRESSION, STATS = 10;
Обратите внимание на параметр COMPRESSION. В версиях SQL Server 2016 Standard и Enterprise это значительно уменьшает размер файла и ускоряет его передачу по сети. Параметр INIT перезаписывает файл, что удобно для ежедневного цикла.
Шаг 2. Восстановление базы на приемнике. На резервном сервере создаем Job, который запускается с временным лагом или по сигналу с первого сервера. Ключевой момент здесь — использование конструкции MOVE, так как пути к файлам .mdf и .ldf на разных серверах могут отличаться.
USE [master];
-- Переводим базу в однопользовательский режим, чтобы разорвать активные соединения
ALTER DATABASE [Test_Base] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
RESTORE DATABASE [Test_Base]
FROM DISK = N'\\NetworkShare\Backups\Work_Base_daily.bak'
WITH REPLACE,
MOVE 'Work_Base_Data' TO 'D:\SQLData\Test_Base.mdf',
MOVE 'Work_Base_Log' TO 'L:\SQLLogs\Test_Base.ldf',
RECOVERY;
-- Возвращаем многопользовательский режим
ALTER DATABASE [Test_Base] SET MULTI_USER;
Шаг 3. Исправление владельца и пользователей. После восстановления база на новом сервере может иметь «осиротевших» пользователей (Orphaned Users). Проанализируем, как это исправить программно. Используем современный подход вместо устаревшего sp_change_users_login:
USE [Test_Base];
ALTER AUTHORIZATION ON DATABASE::[Test_Base] TO [sa];
-- Сопоставление пользователя базы с логином сервера
ALTER USER [v8_user] WITH LOGIN = [v8_user];
Если мы хотим избежать написания громоздких SQL-скриптов, воспользуемся современным стандартом автоматизации — модулем dbatools. Рассмотрим, как это упрощает жизнь системному администратору. Команда Restore-DbaDatabase автоматически берет на себя сопоставление путей к файлам и исправление прав.
Пример скрипта PowerShell, который можно запускать через планировщик задач:
$sourceFile = "\\NetworkShare\Backups\Work_Base_daily.bak"
$destinationServer = "Backup-SQL-Server"
Restore-DbaDatabase -SqlInstance $destinationServer `
-DatabaseName "Test_Base" `
-Path $sourceFile `
-WithReplace `
-OutputScriptOnly | Out-File "C:\Scripts\LastRestore.sql" # Опционально для логов
# Исправление прав пользователей одной командой
Repair-DbaDbOrphanUser -SqlInstance $destinationServer -Database "Test_Base"
Выясним преимущество этого метода: он гораздо гибче обрабатывает ошибки и позволяет динамически определять структуру файлов внутри бэкапа без жесткого прописывания имен логических файлов.
Восстановить базу в SQL — это только половина дела. Чтобы она была полностью работоспособна, ее нужно зарегистрировать в консоли администрирования 1С на втором сервере. Рассмотрим подробнее, как автоматизировать этот этап с помощью утилиты rac (Remote Administration Client).
После успешного RESTORE в SQL, выполним скрипт на сервере приложений:
Пример команды для регистрации базы через rac:
rac infobase --cluster=cluster-id create --name=Test_Base --dbms=MSSQLServer --db-server=Backup-SQL-Server --db-name=Test_Base --db-user=sa --db-pwd=password --license-distribution=allow
Критически важно: Сразу после развертывания базы на приемнике необходимо отключить в ней РегламентныеЗадания. Это предотвратит случайную отправку реальных писем контрагентам или синхронизацию с внешними системами из тестовой копии. Это можно сделать через ту же утилиту rac, установив параметр --scheduled-jobs-deny=on.
Проанализируем ситуацию, когда база растет, и ежедневное копирование полного бэкапа начинает занимать слишком много времени. Посмотрим на способы ускорения:
Perform volume maintenance tasks. Это позволит SQL Server не забивать нулями место на диске при создании файлов базы, что ускоряет восстановление в несколько раз.Linked Server запускает Job на приемнике: EXEC [RESERVE-SQL].[msdb].[dbo].[sp_start_job] @job_name = 'Restore_1C_Base'.Мы разобрали комплексный подход к автоматизации. Идеальная схема выглядит так: задание на основном сервере делает сжатый бэкап, копирует его по сети и дает команду резервному серверу начать восстановление. Резервный сервер выполняет RESTORE с параметром REPLACE, исправляет владельца базы через ALTER AUTHORIZATION и блокирует регламентные задания 1С, чтобы копия оставалась безопасной для бизнес-логики. Такой подход исключает человеческий фактор и гарантирует наличие актуальной и рабочей копии информационной системы каждое утро.