Sytuacja kobiet w IT w 2024 roku
29.01.20217 min
Dawid Sieczka

Dawid SieczkaJunior Full-Stack DeveloperPirum-Technology

Jak zautomatyzować tworzenie backupów bazy danych MS SQL w Azure

Dowiedz się, jak możesz zautomatyzować tworzenie kopii zapasowych bazy danych MS SQL w chmurze Azure.

Jak zautomatyzować tworzenie backupów bazy danych MS SQL w Azure

W tym artykule opisuję, jak w prosty sposób zautomatyzować tworzenie kopii zapasowych bazy danych MS SQL i przechowywać je na chmurze Azure. Sposób ten wymaga od nas pewnych przygotowań, którymi zajmiemy się w pierwszych etapach artykułu. 

Poniżej posługuję się Powershellem, aczkolwiek można uzyskać to samo za pomocą dowolnego narzędzia, które ma możliwość zarządzania zawartością Azure.

Zanim zaczniesz

Przed rozpoczęciem tworzenia naszego Backupa musimy się upewnić, że mamy wymagane narzędzia do tego.

  • Powershell
    • Do instalacji należy jedynie wywołać tę komendę:

      Install-Module -Name Az -AllowClobber -Scope CurrentUser​
    • Opcjonalna jest wersja Powershell 7 lub późniejsza, gdyż będziemy używać Powershell ISE – wbudowanego narzędzia na systemach Windows 10. Odsyłam w poniższym linku do instalacji najnowszej wersji.
    • Aby mieć pełną swobodę w zarządzaniu naszą chmurą, zalecam instalację Azure Az Module
  • Azure
    • Oczywiście potrzebujemy posiadać konto oraz subskrypcję na chmurze i w związku z tym, że to są proste kroki, pozwolę sobie je pominąć.
  • Database
    • Chcąc robić kopię zapasową, musimy mieć przygotowaną bazę danych ?.


Zaczynamy

Azure

Najpierw utworzymy za pomocą Powershella wszystkie potrzebne nam zasoby w chmurze oraz wygenerujemy token, który posłuży nam później do zrobienia połączenia SQL Server Agenta z serwisem Storage Account.

Poniższy skrypt możemy wykonać zarówno w konsoli, jak i w programie Windows Powershell ISE. Przed uruchomieniem należy uzupełnić zmienne swoimi wartościami. 

Poniższy kod wywoła poniższe polecenia:

  1. Inicjalizacja zmiennych (należy zmodyfikować do swoich potrzeb)
  2. Logowanie do Azure
  3. Utworzenie Resource Group jeżeli nie istnieje
  4. Utworzenie Storage Account jeżeli nie istnieje (Warto zwrócić uwagę na typ storage account)
  5. Pobranie kluczy dostępu do Storage Account
  6. Utworzenie Storage Account Context z użyciem kluczy dostępu
  7. Utworzenie Container w Blob Storage Account jeżeli nie istnieje
  8. Utworzenie policy dla Container jeżeli nie istnieje
  9. Generowanie Shared Access Signature Token dla Container
  10. Uzyskanie szczegółów dotyczących Container
  11. Wypisanie w konsoli komendy sql, którą kopiujemy jako query do wywołania w MS SQL


Opis parametrów, które należy zmienić lub dostosować do swoich potrzeb:

  • $subscriptionID- jest to ID subskrypcji w Azure, w której tworzą się wszystkie serwisy oraz resource group.
  • $locationName- nazwa lokacji. Dostosowujemy do swoich upodobań.
  • $resourceGroupName- nazwa zbioru naszych serwisów w chmurze - zasób zwany Resource Group.
  • $storageAccountName- nazwa naszego serwisu w Azure.
  • $storageAccountType- typ serwisu (Replication Type), który określa możliwości serwisu jak i wpływa na jego koszty.
  • $containerName- nazwa kontenera w którym będa trzymane kopie zapasowe. Kontener znajduje się w serwisie Storage Account.
  • $policyName- nazwa policy, dzięki której credentiale w bazie danych będą miały dostęp do dodawania kopii zapasowych do kontenera w storage account.
  • $containerPolicyPermissions- zmienna zawierająca pierwsze litery od rodzajów dostępu do kontenera. Jest częścią policy.
    • r - read
    • a - add
    • c - create
    • w - write
    • d - delete
    • l - list
  • $databaseName- nazwa naszej bazy danych.
# Predefined parameters
 
$subscriptionID = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx'
$locationName = 'westeurope'
$resourceGroupName = 'rg-Sieczka'
$storageAccountName = 'stsieczkabackup'
$storageAccountType = 'Standard_LRS'
$containerName  = 'fullbackup'
$policyName = 'policy'
$containerPolicyPermissions = 'racwdl'
$databaseName = 'Master'


Resztę kodu można wywołać bez zmian. Jeżeli dany zasób już istnieje, to poniższy skrypt nie będzie tworzył drugiego takiego samego. Warto zwrócić uwagę na komentarze, jeśli chcielibyśmy dokonać modyfikacji. 

# Sign in to Azure
Connect-AzAccount
 
# Select subscription content
Set-AzContext -SubscriptionId $subscriptionID
 
# Create a resource group if doesn't exist
$isResourceGroupExisting= Get-AzResourceGroup -Name $resourceGroupName -Location $locationName -ErrorAction SilentlyContinue -WarningAction SilentlyContinue
if(!$isResourceGroupExisting){
    New-AzResourceGroup -Name $resourceGroupName -Location $locationName
} 
 
# Create a storage account if doesn't exist
$isStorageAccountExisting = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName -ErrorAction SilentlyContinue -WarningAction SilentlyContinue
if(!$isStorageAccountExisting){
    New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName   
}
 
# Get the access keys for storage account  
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName  
 
# Create a new storage account context using the storage account key 
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].Value
 
# Create a container in blob storage account if doesn't exist 
$isContainerExisting = Get-AzStorageContainer -Context $storageContext -Name $containerName -ErrorAction SilentlyContinue -WarningAction SilentlyContinue
if(!$isContainerExisting){
    $container = New-AzStorageContainer -Context $storageContext -Name $containerName  
}
 
# Sets up a Stored Access Policy and a Shared Access Signature for the new container  
$policy = Get-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ErrorAction SilentlyContinue -WarningAction SilentlyContinue
if(!$policy){
    $policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -StartTime $(Get-Date).ToUniversalTime().AddMinutes(-5) -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission $containerPolicyPermissions
}
 
# Gets the Shared Access Signature for the policy  
$sas = New-AzStorageContainerSASToken -name $containerName -Policy $policyName -Context $storageContext
 
# Get container details
$container = Get-AzStorageContainer -Context $storageContext -Name $containerName
$blobContainerDetails = $container.CloudBlobContainer 
 
# Writes the create credential command for copy into sql
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $blobContainerDetails.Uri,$sas.Substring(1)
Write-Host "USE $($databaseName)"   
Write-Host $tSql 
Write-Host 'GO'

MS SQL

W tym etapie przechodzimy już do Microsoft SQL Server Management, w którym logujemy się na konto posiadające dostęp do SQL Server Agenta, np. używając Windows Authentication.

Otwieramy okno zapytań (Ctrl+N) i wklejamy skopiowaną komendę z poprzedniego kroku.

Zanim ją wywołamy, warto się upewnić, czy nie ma w niej żadnych błędów, jak spacja w środku stringa.

Po jej udanym wywołaniu możemy zauważyć że Credentiale utworzyły się w eksploratorze po lewej stronie w folderze Security > Credentials.

Musimy się upewnić że nasz SQL Server Agent jest włączony. Znajdziemy go na dole w eksploratorze.

Następnie przechodzimy do folderu Management, a w nim klikając PPM na Maintenance Plans wybieramy Maintenance Plan Wizard.

W tym oknie konfigurujemy nasz plan. W pierwszych etapach musimy określić jego nazwę. W moim przypadku nazwa planu składa się z nazwy bazy danych, rodzaju backupa i nazwy swojego zadania.

Możemy również zdefiniować automatyczne wywoływanie planu klikając przycisk Change przy sekcji Schedule.  

Teraz możemy w łatwy sposób ustalić kiedy tworzymy backup. Najbardziej może nas interesować ustalenie Schedule type, Frequency i Daily frequency.

Po zamknięciu okna i przejściu dalej musimy określić, jakie zadania będzie pełnił nasz plan. W tym przypadku naszym celem jest pełny zapis bazy danych (full). Alternatywnie możemy zaznaczyć diff, który jest częściowym zapisem naszej bazy danych. Tworząc go, należy pamiętać, że przed jego tworzeniem musimy posiadać backup full w celu referencji. 

Jeżeli mamy kilka zaznaczonych tasków, to następnym krokiem jest określenie kolejności ich wykonywania i pozwolę sobie to pominąć.

Pojawi się teraz na naszych oczach konfiguracja taska, w której będziemy musieli wybrać, której bazie danych robimy backup oraz gdzie ta kopia ma trafić.

Wybieramy bazę danych

Wybieramy również miejsce docelowe naszej kopii. Ze względu na to, że robimy backup do chmury, będzie to URL.

Przechodząc do drugiej zakładki Destination, określamy szczegóły naszego miejsca docelowego.

W sekcji SQL credential wybieramy utworzone przez nas wcześniej poświadczenia. W Azure storage container wybieramy nazwę naszego kontenera.

W URL prefix uzupełniamy link o nazwe naszego storage account oraz nazwę kontenera. W zakładce Options zaznaczamy Verify backup integrity oraz modyfikujemy taska w razie potrzeby.

Ostatnim etapem tego okna jest określenie, w którym miejscu docelowym na naszej maszynie będą zapisywać się logi.

Teraz w naszym folderze Maintenance Plans widzimy nowo utworzony plan, na który należy dwa razy kliknąć i pojawi się okno z taskiem. Klikając PPM i wybierając properties, przechodzimy do okna po prawej stronie.

Teraz z pola CredentialName usuwamy zawartość i zapisujemy zmiany (Ctrl + S).

Nasz plan jest teraz gotowy do wywołania i możemy czekać na jego zaplanowane uruchomienie lub zrobić to manualnie. W eksploratorze klikamy PPM na nasz plan i wybieramy Execute.

W zależności od wielkości bazy, proces może się wykonywać do kilkunastu minut. W moim przypadku, jako że moja baza była pusta, potrwało to zaledwie 10 sekund. Wynik naszej pracy znajdziemy w Azure, wchodząc w resource group > storage account > containers > blob container. Tam znajdują się przechowywane kopie zapasowe.

Wykrywanie błędów

W toku naszej pracy mogliśmy popełnić błąd i do akcji wkracza Log File Viewer. Nasz SQL Server Agent zawiera folder jobs, który przechowuje wykonywane prace. Znajdują się tam szczegóły stworzonego przez nas planu i do nich teraz przejdziemy, wybierając PPM View History.

Okno, które nam się teraz pojawiło, przedstawia historie logów. Jak widać to na screenie, pojawiły się u mnie 2 logi: jeden pozytywny, drugi negatywny. W obu przypadkach wywoływałem plan manualnie, żeby sprawdzić, czy wszystko zostało poprawnie skonfigurowane. 

Przejdźmy zatem do szczegółów negatywnego loga, rozwijając jego listę tasków i zaznaczając jednego z nich. Na dole ukazują się nam szczegóły zaznaczonego wiersza, w których widzimy powód naszego niepowodzenia w tworzeniu backupa.

O ile te szczegóły może nie powiedzą nam za wiele, to jest to już jest dobry punkt zaczepienia w szukaniu powodu tego błędu w internecie. Ten konkretny błąd to źle nazwany kontener w szczegółach tworzenia miejsca docelowego przechowywania naszych kopii. Oczywiście można to łatwo naprawić, wchodząc w szczegóły planu i wybierając taska, w którym to miejsce docelowe określiliśmy i poprawić.

Ważnym jest pamiętać, aby przy każdej operacji na taskach zapisać je oraz upewnić się że CredentialName w jego właściwościach pozostaje pustym polem. 

<p>Loading...</p>