Как настроить создание резервных копий SQL Server в несколько папок одновременно?

Вопрос организации надежного резервного копирования баз данных часто упирается в ограничение стандартных средств MS SQL Server, где план обслуживания (Maintenance Plan) по умолчанию позволяет указать только один целевой путь для сохранения файла бэкапа. Рассмотрим, как можно обойти это ограничение и обеспечить хранение копий в нескольких местах для повышения отказоустойчивости.

Использование зеркалирования медиа-наборов (для редакции Enterprise)

Если вы используете редакцию SQL Server Enterprise, вам доступен встроенный механизм зеркалирования резервных копий. Этот метод является наиболее надежным, так как запись в несколько мест происходит одновременно на уровне движка базы данных.

При использовании команды BACKUP DATABASE вы можете указать дополнительные пути через конструкцию MIRROR TO. Если запись в один из целевых каталогов завершится с ошибкой, процесс резервного копирования не будет прерван, пока доступен хотя бы один путь. Это гарантирует целостность данных без необходимости запуска дополнительных скриптов.

Автоматизация копирования с помощью пакетных (bat) файлов

Для большинства пользователей, работающих на версиях Standard или Express, наиболее доступным решением является использование сценариев командной строки. Суть метода заключается в том, что сначала стандартный план обслуживания создает бэкап в «основную» папку, а затем запускается пакетный файл, который копирует полученный файл в дополнительные хранилища.

Разберем процесс по шагам:

1. Создайте план обслуживания в SQL Server Agent, который выполняет задачу резервного копирования в первую папку.
2. Подготовьте bat-файл, который будет выполнять команду копирования, например, используя утилиту robocopy или простую команду copy.
3. Настройте выполнение этого bat-файла в SQL Server Agent сразу после выполнения основного шага резервного копирования.

Важное замечание: При написании скрипта убедитесь, что процесс копирования запускается только после завершения записи файла основным процессом, иначе вы получите ошибку доступа к файлу. Ниже приведен пример простой структуры команды в bat-файле:

@echo off
set source=D:\Backups\Main
set dest1=E:\Backups\Copy1
set dest2=\\NetworkStorage\Backups\Copy2

copy "%source%\MyDatabase.bak" "%dest1%\"
copy "%source%\MyDatabase.bak" "%dest2%\"

Использование PowerShell для гибкой настройки

Скрипты PowerShell предоставляют гораздо больше возможностей по сравнению с классическими bat-файлами. Мы рекомендуем использовать PowerShell, так как он позволяет:

• Проверять успешность выполнения задания через msdb.dbo.sysjobhistory перед началом копирования.
• Реализовать автоматическую ротацию файлов, удаляя старые бэкапы, чтобы не переполнять дисковое пространство.
• Добавить логирование действий для контроля процесса в случае сбоев.

Стороннее программное обеспечение

Если написание и поддержка собственных скриптов кажутся трудоемкими, можно воспользоваться специализированным ПО. Например, утилита Cobian Backup или специализированные решения типа SQLBackupAndFTP позволяют настраивать многопоточное резервное копирование с выбором нескольких направлений (локальные диски, сетевые папки или облачные хранилища) в интерфейсе программы.

Рекомендации по безопасности и производительности

При настройке процесса копирования бэкапов в сторонние папки обязательно учитывайте следующие аспекты:

• Права доступа: Учетная запись, под которой работает служба SQL Server Agent, должна обладать правами на запись во все целевые папки (особенно при работе с сетевыми ресурсами).
• Сетевая нагрузка: Копирование больших файлов через сеть может замедлить работу системы. Старайтесь выполнять бэкап сначала на быстрый локальный диск, а процесс переноса в удаленные папки запускать как фоновую задачу с низким приоритетом.
• Целостность данных: Всегда проверяйте, что процесс копирования не мешает основной задаче бэкапа, чтобы избежать ошибок блокировки файлов .bak.

Используя предложенные методы, вы сможете обеспечить надежное хранение резервных копий и быстро восстановить данные в случае выхода из строя основного хранилища.