В эпоху облачных трансформаций вопрос «как делать бэкап» сменился на «как делать его максимально дешево, быстро и без нагрузки на локальные диски». Если ваш сервер в 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-затрат и обеспечения отказоустойчивости, мы рекомендуем:
- Если сервер в Azure — используйте Azure Backup.
- Если сервер on-premise и места нет — используйте AzCopy.
- Если нужно быстро “скинуть” копию вручную — Azure File Share.
Помните: бэкап считается выполненным только тогда, когда вы попробовали его восстановить.
Нужна помощь в настройке конкретного скрипта под вашу инфраструктуру?
