В епоху хмарних трансформацій питання «як робити бекап» змінилося на «як робити його максимально дешево, швидко та без навантаження на локальні диски». Якщо ваш сервер в 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.
Пам’ятайте: бекап вважається виконаним тільки тоді, коли ви спробували його відновити.
Потрібна допомога в налаштуванні конкретного скрипта під вашу інфраструктуру?
