Les sauvegardes de nos bases de données ont souvent lieu en local ou sur un lecteur réseau. Cela permet de les avoir sous la main pour une restauration rapide ou une duplication dans un environnement hors-production. Mais parfois, trouver cette capacité disque pour stocker nos backups n’est pas si simple…
Par ailleurs, on peut vouloir les stocker dans un environnement externe, sécurisé, en cas de perte de notre solution de stockage principale.
Depuis SQL Server 2012 SP2, Microsoft propose une solution qui peut nous aider à résoudre ces problèmes : la sauvegarde vers un stockage dans le cloud Azure.
Création d’un Storage Account dans Azure
Le stockage dans le cloud Azure est une brique de service dans l’offre, bien vaste, que propose Microsoft. Celle-ci se trouve donc dans l’offre “Storage Account”.
Pour donner une idée du coût, il faut environ compter 20 € par mois et par To, pour du stockage redondant dans un seul Data Center Microsoft.
A partir du moment où vous possédez un abonnement Azure (d’évaluation ou autre), vous pouvez lancer la création d’un Storage Account. Vous serez facturés en fonction de l’espace consommé et du temps utilisé. Si vous utilisez 1 To pendant 15 jours, cela vous coûtera donc environ 10 €.
On commencera donc par créer une ressource de type “Storage Account” :
On lui donnera les paramètres qui définiront l’accès et les caractéristiques du service.
Le type de compte “General Purpose v2” est le plus polyvalent, et pourrait donc servir à d’autres usages : autant l’utiliser.
L’emplacement du data center à utiliser dépend de vos performances réseaux, mais attention : le coût varie légèrement d’un data center à l’autre.
Le niveau de performance nécessaire à faire des backups SQL Server est aujourd’hui uniquement le mode “standard” (disque physique classique et non pas SSD), mais étant donné le niveau de performance attendu, c’est suffisant.
L’ access tier hot/cold détermine le niveau de service attendu pour les fichiers déposés. Si vos fichiers ont vocation à rester au moins 30 jours stockés, il vaut mieux utiliser le sockage “cold”. Si au moins 6 mois, on peut même le passer en mode “archive” (sous réserve de ne pas avoir besoin de récupérer le backup sous 15 heures). Sinon, il vaut mieux utiliser le mode “hot. Pour plus d’information sur les catégories hot/cold/archive : https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-storage-tiers
Enfin, on exigera à ce que tous les transferts passent en HTTPs avec l’option “Secure transfer required”.
Afin de simplifier l’administration de ce service, on créera un Resource Group dédié.
Le Storage Account est présenté comme ci-dessous :
On peut désormais aller dans “blobs” et créer le conteneur de nos backups :
On créer donc un conteneur “mysqlserverbackups” qui ne disposera pas d’accès publique.
Les Storage Accounts gèrent la sécurité de leur accès par des “Access Keys”, qui sont des clés privées permettant des accès en lecture/écriture. Leur partage doit donc être très réfléchie.
Il existe toujours 2 clés, afin de permettre un renouvellement de la clé utilisé dans un applicatif sans générer d’indisponibilité (on reconfigure son appli pour utiliser la 2e clé, puis on génère une nouvelle clé principale, on reconfigure l’applicatif pour utiliser la première nouvellement générée).
Les deux Access Keys sont des éléments essentiels et critiques pour la sécurité de vos fichiers ! Ne les communiquez pas, ne les exposez pas de manière imprudente !
En parallèle des Access Keys, et afin de sécuriser leur usage, il existe une alternative : les Shared Access Signature (SAS). Une Shared Access Signature est une chaine de caractère, signée par une Access Key, permettant d’attribuer des droits spécifiques. On peut les créer dans la partie “Shared Access Signature” du Storage Account :
On peut donc définir à quel types de ressources la SAS servira, pour quel type d’action (lecture, ajout, suppression…), une durée de validité pour l’accès (ici 10 ans), et éventuellement une IP (celle, publique, par laquelle votre SQL Server sortira sur Internet). Une fois le bouton “Generate SAS and connection string” utilisé, on obtient le token suivant :
?sv=2017-11-09&ss=b&srt=co&sp=rwdlac&se=2028-08-22T16:59:59Z&st=2018-08-22T08:59:59Z&sip=1.2.3.4&spr=https&sig=pbi3JZvRjMP66nADkkNDI2R%2F8z70N4R4AwPL%2BVOo4AA%3D
Si jamais on tentait de modifier un des paramètre du token (comme la durée de validité, ou l’IP), la signature invaliderait ces paramètre, faisant échoué la connexion (sig=pbi3JZvRjMP66nADkkNDI2R%2F8z70N4R4AwPL%2BVOo4AA%3D).
Mise en place des sauvegardes
Il existe deux méthodes pour faire les sauvegardes dans un blob Azure : par l’Access Key, ou par une SAS. Même si nous recommandons d’utiliser une SAS, nous allons présenter les deux méthodes.
Sauvegarde par Access Key
- On créer un credential contenant l’Access Key
CREATE CREDENTIAL My_Azure_Cred_with_Access_Key WITH IDENTITY = 'storagecapdata', SECRET = '/lKjpEk9d/Ur3THH+1E9Dt5fGkSkYUsu93He0384b55v6pPLb7ZoRGxazDGNylARh2BkOOsKCDsZUUbS/ax3Qw==';
- On lance la sauvegarde avec le credential créé :
BACKUP DATABASE WideWorldImporters TO URL = 'https://storagecapdata.blob.core.windows.net/mysqlserverbackups/WideWorldImporters.bak' WITH CREDENTIAL = 'My_Azure_Cred_with_Access_Key', COMPRESSION, STATS = 10 ;
On remarquera que l’URL contient donc le nom du Storage Account, avant .blob.core.windows.net , ainsi que le nom d’un conteneur créer dans le Storage Account (ici mysqlerverbackups).
On voit désormais notre fichier présent, il est même possible de le télécharger depuis l’interface.
Sauvegarde par Shared Access Signature
- On créer le credential avec le token de la SAS souhaitée :
CREATE CREDENTIAL [https://storagecapdata.blob.core.windows.net/mysqlserverbackups] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = 'sv=2017-11-09&ss=b&srt=co&sp=rwdlac&se=2028-08-22T20:54:31Z&st=2018-08-22T12:54:31Z&spr=https&sig=mi0JCpl3yJB9inULL1m%2Blu4xyiFwMEzXJGRuM6OFQeQ%3D';
On note donc que le credential porte le nom de l’URL du conteneur, et surtout que le paramètre SECRET est le token de la SAS sans le “?” au début de la chaine de caractère pourtant donné dans le portail Azure !
- On lance la sauvegarde vers l’URL sans rien spécifier d’autre
BACKUP DATABASE WideWorldImporters TO URL = 'https://storagecapdata.blob.core.windows.net/mysqlserverbackups/WideWorldImporters_with_SAS.bak' COMPRESSION, STATS = 10 ;
On trouvera le fichier lui aussi dans l’interface d’Azure :
On remarquera également une petite subtilité sur laquelle je n’ai pas trouvé de documentation. Si on sauvegarde avec une Access Key, on sauvegarde sous la forme d’un Page Blob. Si on sauvegarde avec une SAS, on sauvegarde sous la forme d’un Block Blob.
Un Block Blob convient bien au gros fichiers et peuvent faire jusqu’à 4.75 To (à la date de l’écriture de l’article), tandis qu’un Page Blob est limité à 1 To. Une raison de plus d’utiliser une SAS plutôt qu’une Access Key. Par ailleurs, l’usage de la compression des backup est vivement recommandé.
Pour plus d’information sur les limitations des sauvegardes dans Azure : https://docs.microsoft.com/fr-fr/sql/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-2017#limitations
Restaurer une base de données depuis Azure
Une fois tout établi, c’est beaucoup plus simple. Vous pouvez déjà juste télécharger le fichier de sauvegarde depuis l’interface d’Azure, si vous le souhaitez. Sinon, pour lancer une restauration avec une SAS :
RESTORE DATABASE WideWorldImporters FROM URL = 'https://storagecapdata.blob.core.windows.net/mysqlserverbackups/WideWorldImporters_with_SAS.bak' with replace ;
Sans SAS, mais avec une Access Key :
RESTORE DATABASE WideWorldImporters FROM URL = 'https://storagecapdata.blob.core.windows.net/mysqlserverbackups/WideWorldImporters.bak' WITH CREDENTIAL = 'My_Azure_Cred_with_Access_Key', REPLACE ;
Backup à double destination
SQL Server propose aussi de faire des backups à double destination. C’est à dire qu’il n’y a qu’un seul processus de backup, mais la sortie de ce processus sera doublé à deux endroits. On peut donc avoir un backup en local, de manière “classique”, mais également un backup dans Azure, au cas où l’on venait à perdre le stockage local de sauvegarde. C’est un moyen d’externaliser ses backups à moindre coût.
BACKUP DATABASE WideWorldImporters TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\WideWorldImporters.bak', URL = 'https://storagecapdata.blob.core.windows.net/mysqlserverbackups/WideWorldImporters_with_SAS.bak'
Purge automatisée des backups dans Azure
Il n’existe aucune méthode T-SQL permettant de purger les fichiers se trouvant dans un Azure Blob Storage. Il existe différente méthodes, la plus simple étant un job PowerShell dans SQL Server. Pensez juste à installer le module Azure pour Powershell (Install-Module -Name AzureRM). Le code PowerShell aura cette forme :
$CleanupTime = [DateTime]::UtcNow.AddHours(-72)
$MySASToken = 'sv=2017-11-09&ss=b&srt=co&sp=rwdlac&se=2028-08-22T20:54:31Z&st=2018-08-22T12:54:31Z&spr=https&sig=mi0JCpl3yJB9inULL1m%2Blu4xyiFwMEzXJGRuM6OFQeQ%3D'
$MyStorageAccountName = 'storagecapdata'
$MycontainerName = "mysqlserverbackups"
$context = New-AzureStorageContext -StorageAccountName $MyStorageAccountName -SasToken $MySASToken
Get-AzureStorageBlob -Container $MycontainerName -Context $context | Where-Object { $_.LastModified.UtcDateTime -lt $CleanupTime -and $_.Name -like "*.bak"} |Remove-AzureStorageBlob
Cela peut paraitre obscure, mais il faut juste comprendre les quelques paramètres suivants :
$CleanupTime ==> Tous les fichiers de plus de 72 heures sont supprimés.
$MySASToken ==> Le token SAS, sans le point d’interrogation, comme dans le code T-SQL.
$MyStorageAccountName ==> Le nom du Storage Account dans Azure
$MycontainerName ==> Le nom du conteneur dans le Storage Account
Conclusion
Il y a énormément de choses à dire sur le Blob Storage dans Azure. Beaucoup de choses sont possibles, il faut tenir en compte pour connaitre avec exactitude ses coûts. Cependant, même avec une certaine marge d’erreur cela reste largement compétitif. On peut avoir une idée des coûts avec le calculateur de Microsoft.
Avec cette solution, on peut donc sécuriser ses données dans un cloud externe et ne pas craindre une perte du petit NAS qui pourrait héberger les données d’une PME, par exemple, mais aussi sécuriser des données légales dont la durée de rétention peut parfois se placer à l’échelle de la décennie.
Continuez votre lecture sur le blog :
- Stocker ses bases de données dans un Azure Blob Storage : l’impossible dilemme ? (Vincent Delabre) [AzureSQL Server]
- SQL Server 2022 Backup / Restore via un bucket S3 sous AWS (Louis PROU) [AWSSQL Server]
- Elastic Job Agent : l’Agent SQL Server pour le PaaS Azure (Vincent Delabre) [AzureSQL Server]
- PostgreSQL : Comparatif entre Barman et pgBackRest (Capdata team) [PostgreSQL]
- Restauration de bases Azure SQL Database (Vincent Delabre) [AzureSQL Server]