Stratégie de sauvegarde et de restauration pour Windows Azure SQL Database

La question du Backup/Restore «Windows Azure SQL Database» est un sujet très fréquemment abordé par nos clients. Une récente évolution de notre offre (Windows Azure July Updates) permet aujourd’hui d’y répondre beaucoup plus simplement. Voilà donc une bonne occasion de revenir sur cette problématique et d’expliquer le principe de cette nouveauté…

Quoique bénéficiant de mécanismes intégrés de tolérance aux pannes permettant de garantir le backup de l’infrastructure sous-jacente et de se prémunir contre les pannes matérielles, le service «Windows Azure SQL Database» n’échappe pas à la nécessité de mettre en place une stratégie de sauvegarde. L’objectif est alors de se protéger de la perte de données causée par des erreurs administratives, des erreurs d'application ou de la perte totale d'un Datacenter.

Une stratégie de sauvegarde ne se limite pas aux modalités techniques de sa mise en application : il faut en effet définir le type et la fréquence des sauvegardes, la nature et la vitesse requise, comment tester la restauration des données, où et comment doivent être stockés les fichiers correspondants (en prenant en compte les considérations de sécurité), qui est responsable d'effectuer ces restaurations, comment les restaurations doivent être effectuées pour atteindre les objectifs de disponibilité de la base de données et pour minimiser la perte de données…

Azure SQL Database propose deux approches pour l’implémentation de cette stratégie : la copie de Database et l’utilisation du service d’Import-Export des données au format «.BACPAC». Ces deux mécanismes sont documentés ici : Windows Azure SQL Database Backup and Restore. D’un point de vue technique, l’approche recommandée est de fonder sa stratégie de sauvegarde sur la mise en œuvre combinée de ces deux mécanismes.

En effet, un fichier «.BACPAC» est un document composite compressé qui contient des métadonnées ainsi qu'un ensemble de fichiers «BCP» pour chacune des tables de la base de données. L’opération d'export effectue une copie individuelle en bloc des données de chaque table dans la base de données, mais ne garantit donc pas la cohérence transactionnelle des données : Import and Export a Database (Windows Azure SQL Database). Pour obtenir une copie cohérente, il est nécessaire de procéder en amont à l’export d'une base de données qui n'est pas en cours d’utilisation.

La meilleure façon d'obtenir cette base de données avant export est de créer une base de données avec une commande Transact-SQL telle que «CREATE DATABASE Database1B AS COPY OF Database1A;». Cette commande crée une nouvelle base de données copie cohérente d’un point de vue transactionnel avec la base de données copiée. Il est ensuite possible d’utiliser les options d'exportation pour obtenir un fichier «.BACPAC», que l’on peut stocker localement ou dans le Cloud.

Diverses considérations techniques sont à prendre en compte dans la mise en œuvre d’une copie de base de données Azure SQL Database. La copie peut se faire sur le même serveur ou sur un autre serveur (Copying Databases in Windows Azure SQL Database).

       

Une sous-région Azure SQL Database peut être constituée de plusieurs clusters physiques et il est impossible aujourd’hui de copier une base de données entre deux groupes de serveurs différents. Il faut donc s’assurer que les serveurs sont sur le même cluster en suivant la procédure documentée à l’adresse suivante : Copy Your Databases (Windows Azure SQL Database).

En outre, la copie de base de données affecte les performances du ou des serveurs impliqués dans le processus de copie. Enfin, la connexion au service Windows Azure SQL Database peut parfois être fermée pour différentes raisons (utilisation excessive de ressources et throttling provoquant une «Transient Error»), inactivité de la connexion sur une période supérieure à 30 mn, serveur hors service). Lorsque cette situation se produit, dans la plupart des cas, il suffit de fermer et ouvrir une nouvelle connexion : Connection Management in SQL Azure. Mais, il peut aussi être nécessaire de redémarrer le processus de copie…

[Dans un souci d’exhaustivité dans l’exposé des solutions existantes, je précise qu’il existe également d’autres solutions permettant l’import/export des données pour Windows Azure SQL Database, notamment le pilotage par script d’un utilitaire comme BCP : ces solutions sont soumises aux mêmes contraintes que celles exposées précédemment. Leur mise en oeuvre nécessite donc le respect de bonnes pratiques (Best Practices for loading data to SQL Azure) : découper les données en de multiples flux parallèles, adapter la taille du batch BCP au réseau et aux dataset, ajout d’index non clusterisés après le chargement des données vers Azure SQL Database…]

Auparavant, il était possible d'automatiser ce processus (et de piloter les deux mécanismes de copie de base de données et d’export) par scripting. Depuis juillet 2013, cette démarche s’est considérablement simplifiée. En effet, Windows Azure SQL Database prend désormais en charge une fonction automatisée d'export de base de données (en version «Preview»). Lorsque l’on active cette fonction (sous l'onglet « Configuration » de la base de données), Windows Azure fait une copie complète de la base de données cible vers une base de données temporaire avant de créer le fichier «.BACPAC». Cette copie de la base de données est alors automatiquement supprimée une fois l'exportation terminée. Ainsi, cette fonction offre la possibilité de configurer la fréquence des sauvegardes, le stockage cible, et, la durée de rétention, tout en garantissant la cohérence des données exportées.

Sachant que les bases de données Windows Azure SQL Database sont facturées à la journée, si l’export est réalisé quotidiennement, les coûts de base de données seront théoriquement doublés (voire triplés si la sauvegarde a lieu aux environs de minuit…). Il faut également veiller à localiser le compte de stockage de destination pour les fichiers «.BACPAC» dans la même région que celle du serveur SQL, afin d’éviter les frais liés à la consommation de bande passante. Ne reste alors que la facturation Windows Azure Storage des fichiers «.BACPAC» conservés sur le compte de stockage…