Sauvegarder des BDD MS SQL sur des comptes de stockage Azure

Bonjour à tous,

Je voulais, dans cet article, vous partager une solution que nous avons mise en place pour un de nos clients qui souhaitait sauvegarder des bases de données Microsoft SQL hébergées sur ses VM Azure.

Lorsque ce client nous a sollicités sur le sujet, nous lui avons d’abord proposé d’utiliser la ressource « Coffres Recovery Services« . Sauf qu’avec cette solution, il nous faudra un coffre par région Azure où se trouvent les VM. De plus, les restaurations inter-régions ne sont pas possibles. Chose qui était primordiale pour notre client.

Voyant que la première solution proposée n’a pas fait mouche, nous lui avons proposé de sauvegarder ses bases de données sur des comptes de stockage Azure.

Pour ce faire, nous avons réalisé l’architecture ci-dessous :

Alors, voyons comment tout cela s’agence.

Script Storage Account

C’est un compte de stockage Azure dans lequel nous importons le script (a) qui s’exécutera sur les VM pour lancer la sauvegarde des bases de données Microsoft SQL. Le script, c’est essentiellement les commandes ci-dessous :

$backupUrlContainer = "https://<nom_compte_stockage_cible>.blob.core.windows.net/<nom_vm>/"
$Query = "BACKUP DATABASE "+$database+" TO URL = N'$backupUrlContainer';"
Invoke-SqlCmd -ServerInstance $instance -Database $database.Name -Query $Query -Querytimeout 0 -ErrorAction Stop

Accessoirement, le script ajoute une entrée au fichier de log (b) après la sauvegarde de chaque base de données indiquant l’état de terminaison de celle-ci (succès ou échec).

Runbook

On rédige un Runbook Azure qui permet de charger le script (a) du compte de stockage précédent puis de le lancer sur une liste de VM SQL Azure. L’essentiel du code du Runbook est donné ci-dessous :

Get-AzStorageBlobContent -Blob $BlobName -Container $ContainerName  -Context $ctx -Destination "C:\ScriptToRun1.ps1" -Force
$result = Invoke-AzVMRunCommand -ResourceGroupName $rgname -Name $vmname -CommandId 'RunPowerShellScript' -ScriptPath "C:\ScriptToRun1.ps1"

Machines virtuelles

Il s’agit de machines virtuelles SQL dans Azure. Il faudra penser à :

• Attribuer le rôle sysadmin SQL au compte « NT Authority\SYSTEM » sur la console SQL Server Management Studio.
• Créer un Credential de type SAS (Shared Access Signature) pour le compte de stockage cible sur la console SQL Server Management Studio. Évidemment, en amont de cela, on génère la chaine SAS depuis le compte de stockage cible.

Local Storage Account

Il s’agit du compte de stockage cible dans lequel seront stockés les fichiers .bak résultants des sauvegardes. Ce compte de stockage possède un « private endpoint« , ainsi, le transfert des .bak depuis les VM Azure vers le compte de stockage dit cible ne passera pas par internet. Il faut aussi bien s’assurer que la résolution du nom du compte de stockage (nom_compte_stockage_cible.blob.core.windows.net) depuis les VM à sauvegarder retourne l’adresse IP privée du « private endpoint« .

Log Analytics Workspace

L’idée est de créer une table de Custom Log qui récupère grâce à la Data Collection Rule le contenu du fichier de log (b). Ainsi, on pourra créer une règle d’alerte qui requête ladite tabKusto Ql à la recherche d’entrées comportant la mention echecléchec pour être prévenue en cas d’échec dans la sauvegarde d’une base de données.

Jira

On parle ici de l’outil de ticketing Jira Service Desk. Pour ne pas faire de favoritisme, je citerai aussi GLPI. L’idée est de faire en sorte que l’action de la règle d’alerte soit l’envoi d’un email vers une boite aux lettres visitée par le collecteur de Jira qui créera un ticket support afin que les agents du support puissent intervenir en cas d’échec d’une sauvegarde.

Maintenant, qu’on a exposé le fonctionnement de la solution, il reste quelques considérations et pas des moindres ! Nous allons parler de sauvegarde, chose que nous n’avons pas encore abordée jusqu’ici. Notamment :

Comment est géré la rétention des .bak dans le compte de stockage ?

Eh bien, on utilise pour cela les règles Lifecycle management du compte de stockage.

Comment sécuriser un peu plus tout ça ?

Eh bien, les comptes des stockages possèdent une panoplie d’outils qui peuvent être d’une grande aide dans cette entreprise. On citera :

• la désactivation du « public network access » afin de rendre le compte de stockage non accessible depuis internet,
• le chiffrement au repos, soit avec une clé de chiffrement managée par Microsoft ou bien on chiffre le compte de stockage avec sa propre clé qu’on aura au préalable chargée dans un key vault,
• l’activation du « secure transfert » pour que le transfert de données depuis et vers le compte de stockage se fasse à l’aide d’un protocole chiffré (HTTPS, SMBv3),
• l’activation du « soft delete » qui créé une sorte de corbeille depuis laquelle on pourra restaurer des blobs ou containers supprimés par mégarde,
• la redondance (ZRS : les données du compte de stockage seront ainsi hébergées dans plusieurs centres de données de la région Azure, GRS : dans 2 régions paires d’Azure), etc.

Voilà, j’espère que l’article vous aura plu !