Резервне копіювання MS SQL Server в Azure: Повний гайд

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

Зведена таблиця: що вибрати?

Вердикт

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

1. Якщо сервер в Azure — використовуйте Azure Backup.
2. Якщо сервер on-premise і місця немає — використовуйте AzCopy.
3. Якщо потрібно швидко “скинути” копію вручну — Azure File Share.

Пам’ятайте: бекап вважається виконаним тільки тоді, коли ви спробували його відновити.

Потрібна допомога в налаштуванні конкретного скрипта під вашу інфраструктуру?