Sauvegarde et restauration
Dans des organisations, petites ou grandes, des accidents et des incidents peuvent se produire. C’est pourquoi vous devez toujours disposer d’un plan de restauration de vos systèmes s’ils connaissent des dysfonctionnements. Dans SQL Server, si vous voulez restaurer une base de données à un point dans le temps, vous ne pouvez le faire que si vous fonctionnez en mode de récupération complète. En mode de récupération utilisant les journaux de transactions, il est plus probable de devoir récupérer la base de données à la fin de la sauvegarde de fichier journal.
Un des avantages d’Azure SQL est qu’Azure peut s’occuper de tout cela pour vous. Étant donné qu’Azure SQL gère vos sauvegardes et s’exécute en mode de récupération complète, il peut restaurer votre base de données à n’importe quel point dans le temps. Vous pouvez même restaurer une base de données supprimée dans la stratégie de conservation configurée. Microsoft chiffre également automatiquement vos sauvegardes si TDE est activé sur le serveur logique ou sur l’instance.
Par défaut, une sauvegarde complète de bases de données est effectuée une fois par semaine. Des sauvegardes de fichier journal sont effectuées toutes les 5 à 10 minutes et des sauvegardes différentielles, toutes les 12 à 24 heures. Les fichiers de sauvegarde sont stockés dans le Stockage Azure dans le stockage géo-redondant avec accès en lecture (RA-GRS) par défaut. Toutefois, vous pouvez également choisir d’avoir vos sauvegardes dans un stockage redondant interzone (ZRS) ou un stockage localement redondant (LRS). L’équipe d’ingénierie d’Azure SQL teste automatiquement et en continu la restauration de sauvegardes de bases de données automatiques placées dans des serveurs logiques et des pools de bases de données élastiques. Pour les migrations vers Azure SQL Managed Instance, une sauvegarde initiale automatique avec somme de contrôle des bases de données restaurées avec la commande RESTORE native ou avec Azure Database Migration Service est effectuée. Dans Azure SQL Managed Instance, vous pouvez éventuellement effectuer une sauvegarde en copie seule native et la stocker dans Stockage Blob Azure.
Créer une stratégie de sauvegarde avec Azure SQL Managed Instance et Azure SQL Database
Azure SQL prend en charge ce travail assez lourd, mais il est néanmoins important de comprendre comment les sauvegardes sont stockées et traitées, et quelles sont vos options pour la conservation et la restauration. Au final, vous êtes toujours responsable de la stratégie globale quand il s’agit de la restauration à un instant dans le passé, de la conservation à long terme et de la géorestauration.
Limite de restauration dans le temps
Dans Azure SQL Database et Azure SQL Managed Instance, vous avez la possibilité de procéder à une restauration libre-service. Vous pouvez choisir le point exact dans le temps vers lequel vous souhaitez restaurer et démarrer le processus à l’aide du Portail Azure, des API PowerShell/Azure CLI ou REST. La restauration à un instant dans le passé va créer une nouvelle base de données (avec un nom différent) dans le même serveur logique. Si vous devez remplacer la base de données d’origine par la base de données de restauration à un instant dans le passé, vous devrez renommer à la fois la base de données d’origine et la nouvelle base de données pour revenir à un fonctionnement normal. Vous n’avez pas besoin de mettre à jour les chaînes de connexion.
La rétention de la restauration à un instant dans le passé varie entre 1 et 35 jours. Par défaut, la période de conservation (pour tous les niveaux de service et toutes les options de déploiement) est de sept jours. Dans la plupart des options de déploiement et des niveaux de service, vous pouvez configurer la stratégie pour une durée de 1 à 35 jours, en fonction des exigences de votre scénario. Par exemple, vous pouvez avoir besoin d’un seul jour pour une base de données de test, mais vous pouvez choisir un maximum de 35 jours pour une base de données stratégique.
Conservation à long terme (LTR)
Si 35 jours ne suffisent pas pour répondre aux besoins ou aux exigences de conformité de votre organisation, vous pouvez opter pour la conservation à long terme (LTR). Cette option vous permet de créer automatiquement des sauvegardes complètes de bases de données stockées dans un stockage RA-GRS, ZRS ou LRS pendant 10 ans. Pour Azure SQL Database, LTR est mis à la disposition générale. Pour Azure SQL Managed Instance, LTR est disponible dans une préversion publique limitée.
Géorestauration
En cas de catastrophe, votre organisation doit être en mesure de récupérer. Vos sauvegardes sont stockées automatiquement dans RA-GRS (sauf si vous optez pour ZRS ou LRS), ce qui signifie que vos sauvegardes seront stockées dans la région appairée. Ainsi, si une région entière tombe en panne et que vos bases de données ou instances gérées se trouvent dans cette région, vous êtes protégé. Vous pouvez effectuer une géorestauration vers une autre région à partir de la sauvegarde géorépliquée la plus récente. Cette sauvegarde peut être un peu en retard par rapport au serveur principal, car il faut du temps pour répliquer le blob d’Azure vers une autre région. Vous pouvez effectuer facilement une géorestauration en utilisant le Portail Azure, les API PowerShell/Azure CLI ou REST.