Rate this post

В эпоху облачных трансформаций вопрос «как делать бэкап» сменился на «как делать его максимально дешево, быстро и без нагрузки на локальные диски». Если ваш сервер в Azure или on-premise забит данными под завязку, а свободное место стремится к нулю, стандартные методы могут подвести.

В этой статье мы разберем 4 проверенных способа бэкапа MS SQL в облако Azure, их плюсы, минусы и конкретные сценарии использования.

1. SQL Server Backup to URL (Native)

Это «родной» способ для SQL Server, начиная с версии 2012 SP1 CU2. Суть проста: сервер общается напрямую с Azure Blob Storage через HTTPS.

  • Как работает: Вы создаете SQL Credential с ключом от Storage Account и указываете путь URL = 'https://storage.blob.core.windows.net/...'.
  • Кому подходит: Идеально для SQL Server 2016+ при наличии поддержки TLS 1.2 в системе.
  • Главный плюс: Не требует промежуточного места на диске. Данные «стримятся» сразу в облако.
  • Критический нюанс: Требует идеальной настройки TLS. Если ваша ОС старая (Windows 2012), вы можете столкнуться с ошибками аутентификации.

2. Azure File Share (SMB 3.0) — «Облачный диск»

Если Backup to URL капризничает из-за настроек безопасности или старой версии SQL, на помощь приходит монтирование сетевого диска через протокол SMB.

  • Как работает: Вы создаете File Share в Azure и подключаете его как диск Z: или используете UNC-путь \\mystorage.file.core.windows.net\backups.
  • Кому подходит: Тем, кому нужна простота. Для SQL Server это выглядит как обычный бэкап на диск.
  • Пример команды:

    1. Включить xp_cmdshell

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

    -- 1. Разрешаем изменение расширенных настроек 
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE; 
GO 
-- 2. Включаем саму процедуру 
EXEC sp_configure 'xp_cmdshell', 1; 
RECONFIGURE; 
GO

    2. Теперь пробуем подключить диск и сделать бэкап

    После выполнения шага выше попробуйте снова подключить диск для службы SQL Server:

    -- Подключаем Azure File Share 
EXEC xp_cmdshell 'net use Z: \\mystorage.file.core.windows.net\backups\ /u:AZURE\backup [ВАШ_КЛЮЧ] /persistent:yes';
-- Проверяем, видит ли SQL содержимое диска 
EXEC xp_cmdshell 'dir Z:';

    Если в результате выполнения dir Z: вы увидели список папок — победа! Можно запускать бэкап:

    BACKUP DATABASE [MainDB] TO DISK = '\\mystorage.file.core.windows.net\backups\db.bak' WITH COMPRESSION, BLOCKSIZE = 65536;

    Важно: Для стабильной работы в Azure Files обязательно используйте параметр BLOCKSIZE = 65536.

3. Стриминг через AzCopy (Pipe)

Самый мощный и гибкий метод, когда на сервере 0 байт свободного места, а порты SMB (445) заблокированы провайдером.

  • Как работает: Данные передаются через «трубу» (Pipe). SQL Server выдает поток данных, а утилита AzCopy подхватывает его и отправляет в Blob Storage по порту 443 (HTTPS).
  • Кому подходит: Сложные инфраструктуры, закрытые фаерволы, системы с критическим дефицитом места.
  • Плюс: AzCopy — самая быстрая утилита для передачи данных в Azure.
# --- НАСТРОЙКИ ПОДКЛЮЧЕНИЯ ---
$DatabaseName = "YOUR_DATABASE_NAME"      # Имя базы данных
$StorageAccount = "yourstorageaccount"    # Имя вашего Storage Account в Azure
$Container = "your-container-name"        # Имя контейнера для бэкапов
$SasToken = "?sv=2022-..."                # SAS Token с правами Write/Create

# --- ФОРМИРОВАНИЕ ПУТЕЙ ---
$Timestamp = Get-Date -Format "yyyyMMdd_HHmm"
$BlobName = "${DatabaseName}_full_${Timestamp}.bak"
$UploadUrl = "https://$StorageAccount.blob.core.windows.net/$Container/$BlobName$SasToken"

Write-Host ">>> Запуск процесса резервного копирования: $DatabaseName" -ForegroundColor Cyan

# --- ПРЯМАЯ ПЕРЕДАЧА ДАННЫХ (PIPE) ---
# 1. sqlcmd инициирует бэкап и выводит поток данных в STDOUT (стандартный вывод)
# 2. Оператор '|' передает этот поток на вход AzCopy
# 3. AzCopy принимает поток и загружает его в Azure как PipeBlob

& sqlcmd -S "." -E -Q "BACKUP DATABASE [$DatabaseName] TO DISK = 'STDOUT' WITH COMPRESSION, STATS = 10" `
| & azcopy copy "$UploadUrl" --from-to PipeBlob

if ($LASTEXITCODE -eq 0) {
    Write-Host ">>> Бэкап успешно загружен в Azure: $BlobName" -ForegroundColor Green
} else {
    Write-Error ">>> Ошибка при выполнении бэкапа или загрузки."
}

 

4. Azure Backup (Recovery Services Vault)

Это решение уровня Enterprise. Не просто скрипт, а полноценный сервис управления бэкапами.

  • Как работает: Внутри виртуальной машины Azure устанавливается расширение, которое делает моментальные снимки (snapshots) базы данных.
  • Кому подходит: Крупным компаниям с сотнями баз, где важен централизованный мониторинг.
  • Плюс: Возможность восстановления на определенный момент времени (Point-in-time recovery).

Сводная таблица: что выбрать?

Метод Сложность настройки Порты Требование к дислокации
Backup to URL Средняя 443 (HTTPS) SQL 2016 + TLS 1.2
Azure File Share Низкая 445 (SMB) Любой SQL, открытый порт 445
AzCopy (Pipe) Высокая 443 (HTTPS) Любая версия, критический дефицит места
Azure Backup Низкая (PaaS) Внутренние Только для Azure VM

Вердикт

Для оптимизации IT-затрат и обеспечения отказоустойчивости, мы рекомендуем:

  1. Если сервер в Azure — используйте Azure Backup.
  2. Если сервер on-premise и места нет — используйте AzCopy.
  3. Если нужно быстро «скинуть» копию вручную — Azure File Share.

Помните: бэкап считается выполненным только тогда, когда вы попробовали его восстановить.

Нужна помощь в настройке конкретного скрипта под вашу инфраструктуру?