SQL Server 2014 – Backup vers une URL Azure

Bien que SQL Server 2014 ne soit disponible qu’en version beta CTP2 (en téléchargement public, donc possibilité de tester à loisir, ne vous en privez pas !), bon nombre des nouvelles fonctionnalités sont opérationnelles.

image

Après avoir exposé le chiffrement des sauvegardes, il est temps d’externaliser ces sauvegardes. Entendez par là que stocker à l’extérieur de son datacenter des sauvegardes fait partie des tâches que doit accomplit chaque DBA ou administrateur système. Notez que cette fonctionnalité est également inclue dans SQL Server 2012 SP1 CU2 et ultérieurs.

Pourquoi ?

Nous sommes tous d’accord que procéder à des sauvegardes régulières des bases de données, comme tout système, est important. Généralement, afin d’être performant, ces sauvegardes sont effectuées sur disque local (parfois même pas protégé par un simple RAID), un chemin UNC, une LUN sur une baie de disque ou une média amovible, tel qu’une bande. Je parle ici de sauvegardes, mais on peut tout à fait faire le parallèle avec l’archivage, n’oubliez pas non plus l’archivage, dont la durée de rétention sera bien plus importante que la sauvegarde, mais peut être avez vous réduit le RPO en ne donnant la possibilité de restaurer une base avec une granularité de 1 jour au delà de 6 mois (c’est un exemple).

Bref, autant la sauvegarde est importante, ne serait-ce que pour contenir la taille du journal de transactions en mode de récupération complet ou journalisé en bloc, l’archivage ‘l’est tout autant.

Ensuite, est-ce que la réflexion a été poussée au delà ? A savoir le disaster recovery ? Que se passe t’il si votre Datacenter principal n’est plus accessible, suite à un désastre majeur ? Ou votre salle principale, en fonction de la taille de votre infrastructure. Pouvez vous restaurer à partir de vos bandes sur un serveur fraichement installé dans une nouvelle salle machine ? Vos bandes sont elles exploitables ? Tiens, les testez vous régulièrement ? Combien de temps mettez vous pour installer votre serveur de sauvegarde afin de relire vos bandes précieusement conservées dans votre coffre, ou confiées à une société spécialisée ?

Il n’est pas rare que le RTO (Recovery Time Objective, ou le temps que vous vous accordez pour devenir opérationnel après un sinistre) oublie de prendre en compte le temps nécessaire au “désarchivage” ou à la reconstruction du serveur de sauvegarde si vous passez par des solutions tierces. Et, volontairement, je n’aborde pas ici la problématique de délai … Si votre salle brule ou est inondée, combien de temps faut il pour la remettre en état ou en concevoir une nouvelle, commander des serveurs, les recevoir, les installer ?

Oups, le disaster recovery semblerait presque un métier à part … Et si on le simplifiait ?

Avoir des sauvegardes natives SQL Server, stockée dans le cloud, facilement accessibles, 24h/24h (ah, mince ma société spécialisé en archivage de bande est fermée le WE !!!) permet un recovery assez rapide, que ce soit on-premise ou bien sur une VM dans Azure ou autre. En tant que particulier, vous utiliser probablement skydrive, dropbox ou google drive et autres acteur de ce marché.

SQL Server 2014 introduit ainsi la sauvegarde vers le stockage Azure, offrant ainsi de nouvelles possibilité en terme de DR. Je préfère parler de DR plutôt que de sauvegarde quotidienne car le principal problème est lié à la qualité et au débit de la ligne internet, bien évidement. Sauvegarder une base de plusieurs dizaines ou centaines de GB tous les jours sur internet parait irréalisable pour une grande majorité des sociétés, a l’heure actuelle. Mais pour une sauvegarde hebdomadaire ou mensuelle, pourquoi pas …

Comment ?

C’est très simple. En premier lieu, il convient de créer un compte de stockage dans votre portail azure.

image

Le compte de stockage permet de supporter autant des sauvegardes SQL Server, que des images ou un site web, ce qui est mon cas. J’ajoute donc un nouveau compte. Définissez vos options d’emplacement et de géo-redondance.

image

Ensuite, on créé un conteneur :

image

Notez l’URL de stockage qui nous servira par la suite :

image

Passons à SQL Server à présent. La première étape consiste à donner à SQL Server la possibilité d’écrire sur ce stockage externe. Tout comme vous devez utiliser les credentials pour donner accès a des ressources externes à SQL Server (travaux SSIS d’import / export, étapes de types cmdexec), vous devez créer un credential pour accéder à azure.

Sur le portail, on pense à récupérer les clé d’accès :

imageimage

Que l’on positionne ensuite sur l’écran de création du credential (ou dans le TSQL correspondant)

image

USE [master]
GO
CREATE CREDENTIAL [AzureSQLBackup] 
WITH IDENTITY = N'sqlbackupconseilit', 
     SECRET = N'blablablabla'
GO

Reste à présent à sauvegarder votre base de donnée … Et ce n’est pas très compliqué. Notez que les options MIRROR TO, EXPIREDATE / RETAINDAYS, NOINIT / INIT,  NOSKIP | SKIP, BLOCKSIZE, MAXTRANSFERSIZE, REWIND / NOREWIND,  UNLOAD / NOUNLOAD ne sont pas disponibles. Tout les arguments tels que la compression, le chiffrement via certificat sont opérationnels. Et je vous encourage à les utiliser, du moins la compression, histoire de réduire la bade passante nécessaire et le temps de sauvegarde.

image

L’écran de sauvegarde de la base tient compte de la nouveauté. Il suffit de sélectionner URL en tant que destination, de choisir le credential et le conteneur. Ensuite on n’a plus qu’à recopier l’URL du compte de stockage et … c’est tout.

BACKUP DATABASE [AdventureWorks] 
TO  URL = N'https://sqlbackupconseilit.blob.core.windows.net/demobackup/AdventureWorks_Full.bak' 
WITH  CREDENTIAL = N'AzureSQLBackup' , 
      NAME = N'AdventureWorks-Full Database Backup', 
	  STATS = 10,
	  COMPRESSION
GO

Une fois la sauvegarde terminée, celle ci est visible dans Azure Storage Explorer et dans le portail Azure.

imageimage

En bonus, dans SSMS, il est également possible d’explorer le stockage Azure, en  fournissant le compte de stockage ainsi que la clé :

imageimageimage

La restauration d’une base a partir d’une sauvegarde faite sur Azure ne pose pas davantage de problème.

Que ce soit depuis le portail de gestion Azure ou bien depuis Azure Storage Explorer, notez qu’il est possible à tout moment de télécharger vos fichiers afin de les recopier encore ailleurs, si vous le souhaitez.

Bilan

Cette fonctionnalité n’est, à n’en pas douter, digne d’intérêt. Autant d’un point de vue simplicité de mise en œuvre, que souplesse et flexibilité. Les couts, par ailleurs se sont lié qu’à l’usage. A vous de déterminer la période de rétention sur ces sauvegardes ou archives. Seul bémol, probablement lié à la bande passante nécessaire pour effectuer les sauvegardes. Si vous ne disposez pas d’un minimum de 2 MB de bande passante montante, il y a fort à parier que vous serez confrontés à des problèmes de time out :

image

Bons backups …

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans SQL Server, Windows Azure, est tagué , . Ajoutez ce permalien à vos favoris.

4 commentaires pour SQL Server 2014 – Backup vers une URL Azure

  1. Ping : SQL Server 2014 – Fichiers de base de données dans Windows Azure | Christophe LAPORTE – Consultant SQL Server

  2. Ping : Sauvegarde managée vers Azure | Christophe LAPORTE – Consultant SQL Server

  3. Ping : SQL Server Backup to Windows Azure Tool | Christophe LAPORTE – Consultant SQL Server

  4. Ping : SQL Server 2014 RTM | Christophe LAPORTE – Consultant SQL Server

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s