Sauvegarde et restauration dans Azure Database pour MySQL

Azure Database pour MySQL – Serveur flexible crée automatiquement des sauvegardes de serveur et les stocke de manière sécurisée dans un stockage localement redondant au sein de la région. Les sauvegardes peuvent être utilisées pour restaurer votre serveur à un instant dans le passé. La sauvegarde et la restauration sont une partie essentielle de toute stratégie de continuité d’activité, car elles protègent vos données des altérations et des suppressions accidentelles.

Vue d’ensemble de la sauvegarde

Azure Database pour MySQL – Serveur flexible prend en charge deux types de sauvegardes pour offrir une flexibilité accrue de façon à conserver les sauvegardes des données critiques pour l’entreprise.

Sauvegarde automatisée

Azure Database pour MySQL – Serveur flexible effectue des sauvegardes d’instantanés des fichiers de données et les stocke dans un stockage redondant local. Le serveur effectue également une sauvegarde des journaux des transactions qu’il stocke dans un stockage localement redondant. Ces sauvegardes vous permettent de restaurer un serveur à n’importe quel instant dans le passé de la période de rétention des sauvegardes qui a été configurée. La période de rétention des sauvegardes par défaut est de 7 jours. Vous pouvez éventuellement configurer la sauvegarde de la base de données de 1 à 35 jours. Toutes les sauvegardes sont chiffrées en utilisant le chiffrement AES 256 bits pour les données stockées au repos.

Sauvegarde à la demande

Azure Database pour MySQL – Serveur flexible vous permet également de déclencher des sauvegardes à la demande de la charge de travail de production, en plus des sauvegardes automatisées effectuées par le service et de les stocker en alignement avec la stratégie de rétention de sauvegarde du serveur. Vous pouvez utiliser ces sauvegardes comme moyen le plus rapide de restaurer à un instant dans le passé, avec une réduction des temps de restauration allant jusqu’à 90 %. La période de rétention des sauvegardes par défaut est de 7 jours. Si vous le souhaitez, vous pouvez configurer la sauvegarde de la base de données de 1 à 35 jours. Vous pouvez déclencher un total de 50 sauvegardes à la demande à partir du portail. Toutes les sauvegardes sont chiffrées en utilisant le chiffrement AES 256 bits pour les données stockées au repos.

Vous ne pouvez pas exporter ces fichiers de sauvegarde. Les sauvegardes ne peuvent être utilisées que pour les opérations de restauration dans Azure Database pour MySQL – Serveur flexible. Vous pouvez également utilisermysqldump à partir d’un client MySQL pour copier une base de données.

Fréquence de sauvegarde

Les sauvegardes sur des serveurs flexibles sont basées sur des instantanés. La première sauvegarde d’instantané est planifiée immédiatement après la création d’un serveur. Les sauvegardes de captures instantanées interviennent une fois par jour. Les sauvegardes des journaux des transactions se produisent toutes les 5 minutes.

En cas d’échec d’une sauvegarde planifiée, notre service de sauvegarde tente de sauvegarder toutes les 20 minutes, jusqu’à ce qu’une sauvegarde soit effectuée. Ces échecs de sauvegarde sont dus à des charges de production transactionnelles lourdes sur l’instance du serveur.

Pour améliorer la fréquence des sauvegardes quotidiennes automatisées, vous pouvez augmenter l’intervalle de sauvegarde. Cet ajustement est particulièrement utile lors de l’anticipation de transactions volumineuses, car il réduit considérablement le temps de restauration en cas de défaillance. Pour modifier l’intervalle de sauvegarde, accédez à la section Calcul des paramètres > + Stockage et définissez le champ Intervalle de sauvegarde en conséquence. Pendant que l’intervalle par défaut est défini sur 24 heures, il peut être ajusté à 12 ou 6 heures. La rétention de ces sauvegardes est déterminée par la période de rétention configurée au niveau du serveur.

Actuellement, cette fonctionnalité est en préversion et est limitée aux régions USA Est, USA Centre Ouest, Japon Est et Asie Est .

Remarque

• Si le serveur est soumis à une charge élevée de transactions, aboutissant à des fichiers binlog plus grands et d’une croissance plus rapide, le service de sauvegarde effectue plusieurs sauvegardes par jour pour garantir une restauration fiable et plus rapide en utilisant ces sauvegardes.
• Pour les serveurs 5.7, les transactions longues/volumineuses peuvent empêcher l’acquisition d’un verrou au niveau de l’instance globale, ce qui est nécessaire pour une sauvegarde quotidienne réussie. Dans de tels scénarios, les sauvegardes quotidiennes peuvent échouer. Pour résoudre ce problème, arrêtez la transaction longue OU redémarrez le serveur. Pour garantir un fonctionnement plus fluide, il est recommandé de mettre à niveau vos serveurs MySQL 5.7 vers la version 8.0 en utilisant une mise à niveau de version majeure.

Options de redondance de sauvegarde

Azure Database pour MySQL – Serveur flexible stocke plusieurs copies de vos sauvegardes afin que vos données soient protégées contre les événements planifiés et non planifiés, notamment les défaillances matérielles temporaires, les pannes réseau ou les pannes de courant, et les catastrophes naturelles massives. Azure Database pour MySQL – Serveur flexible offre la possibilité de choisir entre le stockage de sauvegarde localement redondant, redondant interzone ou géoredondant dans les niveaux De base, Usage général et Critique pour l’entreprise. Par défaut, le stockage de sauvegarde d’Azure Database pour MySQL – Serveur flexible est localement redondant pour les serveurs avec une configuration de haute disponibilité de même zone ou sans haute disponibilité, et redondant interzone pour les serveurs avec une configuration de haute disponibilité redondante interzone.

La redondance des sauvegardes garantit que votre base de données répond à ses objectifs de disponibilité et de durabilité même en cas d’échecs, et Azure Database pour MySQL – Serveur flexible étend trois options aux utilisateurs :

• Stockage de sauvegarde redondant localement : quand les sauvegardes sont stockées dans un stockage de sauvegarde redondant localement, plusieurs copies des sauvegardes sont stockées dans le même centre de données. Cette option protège vos données contre les défaillances de disque et de rack du serveur. Cela fournit également une durabilité d’au moins 99,999999999 % (11 9) des objets Sauvegardes sur une année donnée. Par défaut, le stockage de sauvegarde pour les serveurs avec une configuration de haute disponibilité (HA) dans la même zone ou une configuration sans haute disponibilité est défini sur redondant localement.

• Stockage de sauvegarde redondant interzone : quand les sauvegardes sont stockées dans un stockage de sauvegarde redondant interzone, plusieurs copies sont non seulement stockées dans la zone de disponibilité dans laquelle votre serveur est hébergé, mais elles sont également répliquées vers une autre zone de disponibilité dans la même région. Cette option peut être utilisée pour les scénarios qui nécessitent une haute disponibilité ou pour limiter la réplication des données au sein d’un pays ou d’une région afin de répondre aux exigences en matière de résidence des données. Cela fournit également une durabilité d’au moins 99,9999999999 % (12 9) des objets Sauvegardes sur une année donnée. Vous pouvez sélectionner l’option Haute disponibilité redondante interzone au moment de la création du serveur pour garantir un stockage de sauvegarde redondant interzone. La haute disponibilité d’un serveur peut être désactivée après la création, mais le stockage de sauvegarde reste redondant interzone.

• Stockage de sauvegarde géoredondant : quand les sauvegardes sont stockées dans un stockage de sauvegarde géoredondant, les copies multiples sont non seulement stockées dans la région où votre serveur est hébergé, mais elles sont également répliquées dans la région géographiquement appairée. Ceci permet de bénéficier d’une meilleure protection et de la possibilité de restaurer votre serveur dans une région différente en cas de sinistre. En outre, cela permet de fournir une durabilité au moins égale à 99,99999999999999 % (16 chiffres 9) des objets de sauvegarde sur une année donnée. Vous pouvez activer l’option de géoredondance au moment de la création du serveur pour garantir un stockage de sauvegarde géoredondant. De plus, vous pouvez passer du stockage localement redondant au stockage géoredondant après la création du serveur. La géoredondance est prise en charge pour les serveurs hébergés dans les régions Azure appairées.

Remarque

La haute disponibilité redondante interzone pour prendre en charge la redondance de zone est actuellement exposée comme une opération au moment de la création uniquement. Actuellement, pour un serveur à haute disponibilité redondante interzone, la géoredondance ne peut être activée/désactivée qu’au moment de la création du serveur.

Migrer à partir d’autres options de stockage de sauvegarde vers un stockage de sauvegarde géoredondant

Vous pouvez faire passer votre stockage de sauvegarde existant à un stockage géoredondant en appliquant les méthodes suggérées suivantes :

• Migration à partir d’un stockage de sauvegarde redondant localement vers un stockage de sauvegarde géoredondant : pour déplacer votre stockage de sauvegarde à partir d’un stockage redondant localement vers un stockage géoredondant, vous pouvez modifier la configuration du serveur Calcul + Stockage à partir du portail Azure afin d’activer la géoredondance pour le serveur source redondant localement. Les serveurs à haute disponibilité redondants dans les mêmes zones peuvent également être restaurés en tant que serveurs géoredondants d’une façon similaire, car le stockage de sauvegarde sous-jacent est pareillement redondant localement.

• Passer d’un stockage redondant interzone à un stockage de sauvegarde géoredondant – Azure Database pour MySQL – Serveur flexible ne prend pas en charge la conversion du stockage redondant interzone en stockage géoredondant via une modification des paramètres Calcul + stockage une fois le serveur approvisionné. Pour faire passer votre stockage de sauvegarde du stockage redondant interzone au stockage géoredondant, il existe deux options : a) Utiliser PITR (restauration à un instant dans le passé) pour restaurer le serveur avec la configuration souhaitée. b) Créer un serveur avec la configuration souhaitée et migrer les données en utilisant un vidage et une restauration.

Rétention des sauvegardes

Les sauvegardes sont conservées en fonction du paramètre de période de rétention de sauvegarde sur le serveur. Vous pouvez sélectionner une période de rétention comprise entre 1 et 35 jours, la période de rétention par défaut étant de 7 jours. Vous pouvez définir la période de rétention lors de la création du serveur ou ultérieurement en mettant à jour la configuration de la sauvegarde en utilisant le portail Azure.

La période de rétention de sauvegarde détermine jusqu’à quelle date une opération de restauration à un instant dans le passé peut être effectuée, dans la mesure où elle est basée sur les sauvegardes disponibles. La période de rétention de sauvegarde peut également être traitée comme une fenêtre de récupération du point de vue de la restauration. Toutes les sauvegardes requises pour effectuer une restauration à un instant dans le passé au cours de la période de rétention de sauvegarde sont conservées dans le stockage de sauvegarde. Par exemple, si la période de conservation des sauvegardes est définie sur sept jours, la fenêtre de récupération est considérée comme les sept derniers jours. Dans ce scénario, toutes les sauvegardes nécessaires pour la restauration du serveur au cours des sept derniers jours sont conservées. Avec une fenêtre de rétention de sauvegarde de sept jours, les captures instantanées de base de données et les sauvegardes du journal des transactions sont stockées pour les huit derniers jours (1 jour avant la fenêtre).

Coût du stockage de sauvegarde

Azure Database pour MySQL – Serveur flexible fournit jusqu’à 100 % de votre stockage de serveur approvisionné en tant que stockage de sauvegarde sans coût supplémentaire. Tous les stockages de sauvegarde supplémentaires utilisés sont facturés en Go par mois. Par exemple, si vous avez configuré un serveur avec 250 Go de stockage, vous disposez de 250 Go de stockage pour les sauvegardes du serveur sans frais supplémentaires. Si l’utilisation quotidienne de la sauvegarde est de 25 Go, vous pouvez bénéficier de jusqu’à 10 jours de stockage de sauvegarde gratuit. Le stockage utilisé pour les sauvegardes de plus de 250 Go est facturé conformément au modèle de tarification.

Vous pouvez utiliser la métrique Surveiller Azure Database pour MySQL – serveur flexible dans Azure Monitor disponible dans le portail Azure pour surveiller le stockage de sauvegarde consommé par un serveur. La métrique Stockage de sauvegarde utilisée représente le total du stockage consommé par l’ensemble des sauvegardes de base de données et des sauvegardes de journaux qui sont conservées, en fonction de la période de conservation des sauvegardes définie pour le serveur. Une activité transactionnelle importante sur le serveur peut entraîner une augmentation de l’utilisation du stockage de sauvegarde, quelle que soit la taille totale de la base de données. Le stockage de sauvegarde utilisé pour un serveur géoredondant est le double de celui d’un serveur redondant localement.

Le principal moyen de contrôler le coût du stockage de sauvegarde consiste à définir la période de rétention de sauvegarde appropriée. Vous pouvez sélectionner une période de rétention comprise entre 1 et 35 jours.

Important

Les sauvegardes à partir d’un serveur de base de données configuré dans une configuration de haute disponibilité redondante interzone sont effectuées à partir du serveur de base de données principal, car la surcharge est minime avec des sauvegardes d’instantanés.

Voir les sauvegardes complètes disponibles

Le panneau Sauvegarde et restauration dans le portail Azure fournit une liste complète des sauvegardes complètes disponibles à un point dans le temps donné. Ceci inclut les sauvegardes automatisées ainsi que les sauvegardes à la demande. Vous pouvez utiliser ce panneau pour voir les horodatages de réalisation de toutes les sauvegardes complètes disponibles au cours de la période de rétention du serveur, et pour effectuer des opérations de restauration en utilisant ces sauvegardes complètes. La liste des sauvegardes disponibles comprend toutes les sauvegardes complètes dans la période de rétention, un horodatage indiquant la réalisation de l’opération, un horodatage indiquant la durée de rétention d’une sauvegarde et une action de restauration.

Restaurer

Dans Azure Database pour MySQL – Serveur flexible, l’exécution d’une restauration crée un serveur à partir des sauvegardes du serveur d’origine. Deux types de restauration sont disponibles :

• La restauration à un instant dans le passé est disponible avec les deux options de redondance des sauvegardes et elle crée un serveur dans la même région que votre serveur d’origine.
• Géorestauration : disponible seulement si vous avez configuré votre serveur pour le stockage géoredondant et qu’il vous permet de restaurer votre serveur dans une région géo-appairée ou toute autre région prise en charge par Azure où Serveur flexible est disponible.

La durée estimée pour la récupération du serveur dépend de plusieurs facteurs :

• la taille des bases de données ;
• le nombre de journaux des transactions impliqués
• la quantité d’activité qui doit être relue pour effectuer une récupération au point de restauration
• la bande passante du réseau si la restauration s’effectue vers une autre région
• le nombre de demandes de restauration simultanées en cours de traitement dans la région cible
• la présence d’une clé primaire dans les tables de la base de données. Pour accélérer la récupération, envisagez d’ajouter une clé primaire pour toutes les tables de votre base de données.

Remarque

Un serveur à haute disponibilité devient un serveur sans haute disponibilité (haute disponibilité désactivée) après la restauration pour la restauration à un instant dans le passé et pour la géorestauration.

Restauration à un instant dans le passé

Dans Azure Database pour MySQL – Serveur flexible, l’exécution d’une restauration à un instant dans le passé crée un serveur à partir des sauvegardes du serveur flexible dans la même région que votre serveur source. Il est créé avec la configuration du serveur d’origine pour le niveau de calcul, le nombre de vCores, la taille de stockage, la période de rétention des sauvegardes et l’option de redondance des sauvegardes. De plus, les étiquettes et les paramètres, comme ceux des réseaux virtuels et du pare-feu, sont hérités du serveur source. Le niveau de calcul et de stockage, la configuration et les paramètres de sécurité du serveur restauré peuvent être modifiés une fois la restauration terminée.

Remarque

Il existe deux paramètres de serveur qui sont réinitialisés aux valeurs par défaut (et qui ne sont pas copiés depuis le serveur principal) après l’opération de restauration :

• time_zone : cette valeur est définie sur la valeur PAR DÉFAUT SYSTEM
• event_scheduler : pour les serveurs MySQL version 5.7, le paramètre serveur event_scheduler est désactivé automatiquement (OFF) quand la sauvegarde est lancée, et le paramètre serveur event_scheduler est réactivé (ON) une fois la sauvegarde terminée. Dans la version 8.0 de MySQL pour Serveurs flexibles Azure Database pour MySQL, event_scheduler reste inchangé pendant les sauvegardes. Pour garantir un fonctionnement plus fluide, il est recommandé de mettre à niveau vos serveurs MySQL 5.7 vers la version 8.0 en utilisant une mise à niveau de version majeure.

La restauration à un instant dans le passé est utile dans plusieurs scénarios. Vois des cas d’utilisation courants :

• Un utilisateur supprime accidentellement des données de la base de données
• Un utilisateur supprime une table ou une base de données importantes
• Une application utilisateur remplace accidentellement des données correctes par des données incorrectes en raison d’un défaut de l’application.

Vous pouvez choisir entre le dernier point de restauration, un point de restauration personnalisé et le point de restauration le plus rapide (une restauration en utilisant une sauvegarde complète) via Restauration à un instant dans le passé dans Azure Database pour MySQL – Serveur flexible avec le portail Azure.

• Dernier point de restauration : l’option de dernier point de restauration vous permet de restaurer le serveur à l’horodatage correspondant au moment où l’opération de restauration a été déclenchée. Cette option est utile pour restaurer rapidement le serveur à l’état le plus à jour.
• Point de restauration personnalisé : cette option vous permet de choisir n’importe quel point dans le temps dans la période de rétention définie pour ce serveur. Cette option est utile pour restaurer le serveur à un point précis dans le temps afin de récupérer d’une erreur de l’utilisateur.
• Point de restauration le plus rapide : cette option permet aux utilisateurs de restaurer le serveur dans le délai le plus rapide possible pour un jour donné dans la période de rétention définie pour leur serveur. La restauration la plus rapide est possible en choisissant le point de restauration dans le temps auquel la sauvegarde complète est effectuée. Cette opération de restauration restaure simplement la sauvegarde d’instantané complète, et ne garantit pas la restauration ou la récupération des journaux, ce qui la rend rapide. Pour une opération de restauration réussie, nous vous recommandons de sélectionner un horodatage de sauvegarde complète supérieur au point de restauration le plus ancien dans le temps.

La durée estimée de la récupération dépend de plusieurs facteurs, notamment les tailles des bases de données, la taille de sauvegarde du journal des transactions, la taille de calcul de la référence SKU et le moment de la restauration. La récupération du journal des transactions est la partie la plus longue du processus de restauration. Si le moment de la restauration choisi est plus proche de la planification de sauvegarde de l’instantané, les opérations de restauration sont plus rapides, car l’application du journal des transactions est minimale. Pour estimer le temps de récupération précis de votre serveur, nous vous recommandons vivement de le tester dans votre environnement, car il contient trop de variables spécifiques de l’environnement.

Important

Si vous restaurez une instance Azure Database pour MySQL – Serveur flexible configurée avec une haute disponibilité redondante interzone, le serveur restauré est configuré dans la même région et la même zone que votre serveur principal, et il est déployé en tant que serveur unique en mode de non-haute disponibilité. Pour un serveur flexible, consultez Haute disponibilité redondante interzone.

Important

Vous pouvez récupérer une ressource Azure Database pour MySQL – Serveur flexible supprimée dans les 5 jours suivant la suppression du serveur. Pour obtenir un guide détaillé sur la restauration d’un serveur supprimé, reportez-vous aux étapes documentées. Pour protéger les ressources serveur après le déploiement contre la suppression accidentelle ou des modifications inattendues, les administrateurs peuvent utiliser des verrous de gestion.

Géorestauration

Vous pouvez restaurer un serveur dans sa région géo-appairée où le service est disponible si vous avez configuré votre serveur pour des sauvegardes géoredondantes ou toute autre région prise en charge par Azure où Azure Database pour MySQL – Serveur flexible est disponible. La possibilité de restaurer dans n’importe quelle région non appairée prise en charge par Azure (sauf Brazil South, USGov Virginia et West US 3)) est appelée « Géorestauration universelle ».

La géorestauration est l’option de récupération par défaut quand votre serveur est indisponible en raison d’un incident dans la région où il est hébergé. Si un incident à grande échelle dans une région entraîne l’indisponibilité de votre application de base de données, vous pouvez restaurer un serveur à partir des sauvegardes géoredondantes sur un serveur situé dans n’importe quelle autre région. La géorestauration utilise la sauvegarde la plus récente du serveur. Il peut y avoir un certain délai entre le moment où une sauvegarde est effectuée et celui où elle est répliquée dans une autre région. Ce délai peut aller jusqu’à une heure : si une catastrophe se produit, il peut donc y avoir jusqu’à une heure de perte de données.

La géorestauration peut également être effectuée sur un serveur arrêté en tirant parti d’Azure CLI. Pour plus d’informations sur la géorestauration d’un serveur avec Azure CLI, consultez Restauration à un instant dans le passé dans Azure Database pour MySQL – Serveur flexible avec Azure CLI.

Le délai de récupération estimé dépend de plusieurs facteurs, notamment de la taille des bases de données, de la taille du journal des transactions, de la bande passante réseau et du nombre total de bases de données à récupérer dans la même région au même moment.

Remarque

Si vous géorestaurez une instance Azure Database pour MySQL – Serveur flexible configurée avec une haute disponibilité redondante interzone, le serveur restauré est configuré dans la région géo-appairée et la même zone que votre serveur principal, et il est déployé en tant qu’instance Azure Database pour MySQL – Serveur flexible unique en mode de non-haute disponibilité. Reportez-vous à haute disponibilité redondante interzone pour Azure Database pour MySQL – Serveur flexible.

Important

Quand la région principale est en panne, vous ne pouvez pas créer de serveurs géoredondants dans la région géo-appairée respective, car le stockage ne peut pas être approvisionné dans la région principale. Il faut attendre que la région principale soit opérationnelle pour approvisionner des serveurs géoredondants dans la région géo-appairée.
Quand la région principale est en panne, vous pouvez néanmoins toujours géorestaurer le serveur source vers la région géo-appairée en désactivant l’option de géoredondance dans les paramètres de configuration Calcul + stockage du serveur dans l’expérience du portail de restauration, puis restaurer en tant que serveur redondant localement pour garantir la continuité de l’activité.

Effectuer des tâches de post-restauration

Après une restauration à l’aide de l’un des mécanismes de récupération Dernier point de restauration ou Point de restauration personnalisé, vous devez effectuer les tâches suivantes afin que vos utilisateurs et applications soient de nouveau opérationnels :

• Si le nouveau serveur est destiné à remplacer le serveur d’origine, redirigez les clients et les applications clientes vers le nouveau serveur.
• Vérifiez que les règles de pare-feu et de réseau virtuel appropriées au niveau serveur sont en place pour permettre aux utilisateurs de se connecter.
• Assurez-vous que les connexions et les autorisations appropriées au niveau de la base de données sont en place.
• Configurer les alertes selon les besoins.

Conservation à long terme (préversion)

Remarque

La fonctionnalité en préversion « Conservation à long terme » pour la protection des serveurs flexibles Azure Database pour MySQL avec Sauvegarde Azure est actuellement suspendue. Évitez de configurer de nouvelles sauvegardes jusqu’à nouvel ordre. Soyez assuré que toutes les données des sauvegardes existantes sont en sécurité et disponibles pour la restauration.

Les services Sauvegarde Azure et Azure Database pour MySQL – Serveur flexible ont créé une solution de sauvegarde à long terme de qualité professionnelle pour les instances Azure Database pour MySQL – Serveur flexible qui peut conserver des sauvegardes pendant jusqu’à 10 ans. Vous pouvez utiliser la conservation à long terme indépendamment ou en plus de la solution de sauvegarde automatisée offerte par Azure Database pour MySQL – Serveur flexible, qui offre une rétention allant jusqu’à 35 jours. Les sauvegardes automatisées sont des sauvegardes d’instantanés adaptées aux récupérations opérationnelles, en particulier quand vous souhaitez effectuer une restauration à partir des dernières sauvegardes. Les sauvegardes à long terme vous aident dans le cadre de vos besoins en matière d’audit et de conformité. Outre la rétention à long terme, la solution offre les fonctionnalités suivantes :

• Sauvegardes planifiées et à la demande contrôlées par le client
• Gérer et surveiller toutes les opérations et tous les travaux liés à la sauvegarde pour des serveurs, groupes de ressources, emplacements, abonnements et locataires depuis un même emplacement appelé Centre de sauvegarde.
• Les sauvegardes sont stockées dans des domaines de sécurité et d’erreur distincts. Si le serveur ou l’abonnement source est compromis, les sauvegardes restent sécurisées dans le coffre de sauvegarde (dans les comptes de stockage managés de Sauvegarde Azure).

Limitations et considérations

• En préversion, la restauration LTR est actuellement disponible en tant que RestoreasFiles pour des comptes de stockage. La fonctionnalité RestoreasServer sera ajoutée dans le futur.
• Le support pour la création et la gestion de la conservation à long terme (LTR) via Azure CLI n’est actuellement pas pris en charge.

Pour plus d’informations sur l’exécution d’une sauvegarde à long terme, consultez le guide pratique.

Sauvegarde et exportation à la demande (préversion)

Remarque

La fonctionnalité « Sauvegarde et exportation à la demande » dans Azure Database pour MySQL – Serveur flexible actuellement en préversion a été temporairement suspendue. Cette décision a été prise pour résoudre certains problèmes techniques identifiés lors de la phase de préversion, et qui ont un impact sur la restauration des sauvegardes exportées. Par conséquent, l’exportation de sauvegardes vers des comptes de stockage externes ne sera pas disponible jusqu’à nouvel ordre.

Azure Database pour MySQL – Serveur flexible offre maintenant la possibilité de déclencher une sauvegarde physique à la demande et instantanée du serveur, et de l’exporter vers un compte de stockage Azure (Stockage Blob Azure). Une fois exportées, ces sauvegardes peuvent être utilisées pour la récupération, la migration et la redondance des données. Ces fichiers de sauvegarde physique exportés peuvent être utilisés pour restaurer sur un serveur MySQL local, pour répondre aux besoins d’audit, de conformité ou d’archivage d’une organisation. La fonctionnalité est actuellement en préversion publique et disponible uniquement dans les régions de cloud public.

Pour plus d’informations sur la sauvegarde d’exportation, consultez le guide pratique.

Forum Aux Questions (FAQ)

Questions relatives à la sauvegarde

• Comment sauvegarder mon serveur ?

  Par défaut, Azure Database pour MySQL – Serveur flexible active les sauvegardes automatisées de votre serveur entier (comprenant toutes les bases de données créées) avec une période de rétention par défaut de 7 jours. Vous pouvez également déclencher une sauvegarde manuelle en utilisant la fonctionnalité de sauvegarde à la demande. L’autre façon d’effectuer manuellement une sauvegarde est d’utiliser des outils de la communauté, comme mysqldump (documenté ici) ou mydumper (documenté ici). Si vous souhaitez sauvegarder une instance Azure Database pour MySQL – Serveur flexible dans un stockage Blob, reportez-vous au blog de notre communauté technique Sauvegarder Azure Database pour MySQL – Serveur flexible vers un stockage Blob.

• Puis-je configurer les sauvegardes automatiques pour qu’elles soient conservées à long terme ?

  Non, actuellement, nous ne prenons en charge qu’un maximum de 35 jours de rétention de sauvegarde automatisée. Vous pouvez effectuer des sauvegardes manuelles et les utiliser pour les besoins de rétention à long terme.

• Quelles sont les fenêtres de sauvegarde pour mon serveur ? Puis-je apporter des personnalisations ?

  La première sauvegarde d’instantané est planifiée immédiatement après la création d’un serveur. Les sauvegardes d’instantané sont effectuées une fois par jour. Les sauvegardes des journaux des transactions se produisent toutes les 5 minutes. Les fenêtres de sauvegarde sont gérées nativement par Azure et ne peuvent pas être personnalisées.

• Mes sauvegardes sont-elles chiffrées ?

  Toutes les données, les sauvegardes et les fichiers temporaires d’Azure Database pour MySQL – Serveur flexible créés pendant l’exécution des requêtes sont chiffrés en utilisant le chiffrement AES 256 bits. Le chiffrement du stockage est toujours activé et ne peut pas être désactivé.

• Puis-je restaurer une ou plusieurs bases de données ?

  La restauration d’une ou plusieurs bases de données ou tables n’est pas prise en charge. Si vous souhaitez restaurer des bases de données spécifiques, effectuez une restauration à un instant dans le passé, puis extrayez les tables ou bases de données nécessaires.

• Mon serveur est-il disponible pendant la fenêtre de sauvegarde ?

  Oui. Les sauvegardes sont des opérations en ligne basées sur un instantané. L’opération d’instantané ne prend que quelques secondes et n’interfère pas avec les charges de travail de production, ce qui garantit la haute disponibilité du serveur.

• Lors de la configuration de la fenêtre de maintenance pour le serveur, devons-nous tenir compte de la fenêtre de sauvegarde ?

  Non, les sauvegardes sont déclenchées en interne dans le cadre du service managé et n’ont aucune incidence sur la fenêtre Maintenance managée.

• Où sont stockées mes sauvegardes automatisées et comment gérer leur conservation ?

  Azure Database pour MySQL – Serveur flexible crée automatiquement des sauvegardes de serveur et les stocke dans un stockage localement redondant configuré par l’utilisateur ou dans un stockage géoredondant. Ces fichiers de sauvegarde ne peuvent pas être exportés. La période de rétention des sauvegardes par défaut est de 7 jours. Si vous le souhaitez, vous pouvez configurer la sauvegarde de la base de données de 1 à 35 jours.

• Comment vérifier mes sauvegardes ?

  Pour valider la disponibilité des sauvegardes effectuées, la meilleure méthode consiste à visualiser les sauvegardes automatisées complètes effectuées pendant la période de rétention dans le panneau Sauvegarde et restauration. Si une sauvegarde échoue, elle ne figure pas dans la liste des sauvegardes disponibles, et le service de sauvegarde essaie toutes les 20 minutes d’effectuer une sauvegarde jusqu’à ce qu’une sauvegarde réussie soit effectuée. Ces échecs de sauvegarde sont dus à des charges de production transactionnelles lourdes sur le serveur.

• Où voir l’espace utilisé par les sauvegardes ?

  Dans le portail Azure, sous l’onglet Surveillance, dans la section Métriques, vous trouvez la métrique Surveiller Azure Database pour MySQL – Serveur flexible, qui peut vous aider à surveiller l’utilisation totale des sauvegardes.

• Qu’advient-il de mes sauvegardes si je supprime mon serveur ?

  Si vous supprimez le serveur, toutes les sauvegardes qui appartiennent au serveur sont également supprimées et ne peuvent pas être restaurées. Pour protéger les ressources serveur après le déploiement contre la suppression accidentelle ou des modifications inattendues, les administrateurs peuvent utiliser des verrous de gestion.

• Que se passe-t-il pour mes sauvegardes lorsque je restaure un serveur ?

  Si vous restaurez un serveur, cela entraîne toujours la création d’un tout nouveau serveur qui a été restauré en utilisant des sauvegardes du serveur d’origine. L’ancienne sauvegarde du serveur d’origine n’est pas copiée sur le serveur nouvellement restauré et reste avec le serveur d’origine. Cependant, pour le serveur nouvellement créé, la première sauvegarde d’instantané est planifiée immédiatement après la création d’un serveur, et le service garantit que les sauvegardes automatisées quotidiennes sont effectuées et stockées en fonction de la période de rétention configurée pour le serveur.

• Comment suis-je facturé pour mon utilisation des sauvegardes ?

  Azure Database pour MySQL – Serveur flexible fournit jusqu’à 100 % de votre stockage de serveur approvisionné en tant que stockage de sauvegarde sans frais supplémentaires. Le stockage de sauvegarde supplémentaire utilisé est facturé en Go par mois conformément au modèle de tarification. La facturation du stockage de sauvegarde est également régie par la période de rétention de sauvegarde sélectionnée et l’option de redondance de sauvegarde choisie, en dehors de l’activité transactionnelle sur le serveur, qui a un impact sur le stockage de sauvegarde total directement utilisé.

• Comment les sauvegardes sont-elles conservées pour les serveurs arrêtés ?

  Aucune nouvelle sauvegarde n’est effectuée pour les serveurs arrêtés. Toutes les sauvegardes plus anciennes (dans la fenêtre de rétention) au moment de l’arrêt du serveur sont conservées jusqu’à ce que le serveur soit redémarré, après quoi la rétention des sauvegardes pour le serveur actif est régie par sa fenêtre de rétention de sauvegarde.

• Comment suis-je facturé pour les sauvegardes d’un serveur arrêté ?

  Pendant que votre instance de serveur est arrêtée, vous êtes facturé pour le stockage approvisionné (y compris les IOPS approvisionnés) et le stockage de sauvegarde (sauvegardes stockées dans votre fenêtre de rétention spécifiée). Le stockage de sauvegarde gratuit est limité à la taille de votre base de données approvisionnée et s’applique seulement aux serveurs actifs.

• Comment mes données de sauvegarde sont-elles protégées ?

  Azure Database pour MySQL – Serveur flexible protège vos données de sauvegarde en bloquant les opérations susceptibles d’entraîner la perte de points de récupération pendant la durée de la période de rétention configurée. Les sauvegardes effectuées pendant la période de rétention peuvent être lues seulement à des fins de restauration et sont supprimées après la période de rétention. En outre, toutes les sauvegardes dans Azure Database pour MySQL – Serveur flexible sont chiffrées en utilisant le chiffrement AES 256 bits pour les données stockées au repos.

• Comment une opération de restauration à un instant dans le passé (PITR) affecte-t-elle l’utilisation des IOPS ?

  Pendant une opération PITR dans Azure Database pour MySQL – Serveur flexible, un nouveau serveur est créé et les données sont copiées du stockage du serveur source vers le stockage du nouveau serveur. Ce processus entraîne une utilisation accrue des IOPS sur le serveur source. Cette augmentation de l’utilisation des IOPS est une occurrence normale et n’indique aucun problème avec le serveur source ou l’opération PITR. Une fois l’opération PITR terminée, l’utilisation des IOPS sur le serveur source revient à ses niveaux habituels.

Questions relatives à la restauration

• Comment restaurer mon serveur ? Le portail Azure prend en charge la restauration à un instant dans le passé pour tous les serveurs, ce qui permet aux utilisateurs de restaurer à des points de restauration les plus récents ou personnalisés. Pour restaurer manuellement votre serveur à partir des sauvegardes effectuées par mysqldump/myDumper, consultez Restaurer votre base de données en utilisant myLoader.

• Pourquoi ma restauration prend-elle autant de temps ?

  La durée estimée pour la récupération du serveur dépend de plusieurs facteurs :

  • La taille des bases de données. Dans le cadre du processus de récupération, la base de données doit être alimentée à partir de la dernière sauvegarde physique et, dès lors, le temps nécessaire à la récupération est proportionnel à la taille de la base de données.
  • La portion active de l’activité de transaction qui doit être relue pour effectuer une récupération. La récupération peut prendre plus de temps en fonction de l’activité de transaction ajoutée depuis le dernier point de contrôle réussi.
  • La bande passante du réseau si la restauration s’effectue dans une autre région.
  • Le nombre de demandes de restauration simultanées en cours de traitement dans la région cible.
  • La présence de clés primaires dans les tables de la base de données. Pour une récupération plus rapide, envisagez d’ajouter des clés primaires pour toutes les tables de votre base de données.

• La modification des variables de base de données au niveau de la session aura-t-elle un impact sur la restauration ?

  La modification des variables de niveau session et l’exécution d’instructions DML dans une session cliente MySQL peut avoir un impact sur l’opération PITR (restauration à un instant dans le passé), car ces modifications ne sont pas enregistrées dans le journal binaire utilisé pour l’opération de sauvegarde et de restauration. Par exemple, foreign_key_checks sont une telle variable au niveau de la session, qui, si elle est désactivée pour l’exécution d’une instruction DML qui enfreint la contrainte de clé étrangère entraîne un échec PITR (point dans le temps de restauration). La seule solution de contournement dans ce scénario consiste à sélectionner une date/heure PITR antérieure à la date/heure à laquelle les contrôles foreign_key_checks ont été désactivés. Nous vous recommandons de NE PAS modifier les variables de session pour qu’une opération PITR réussisse.

Contenu connexe

• Continuité d’activité
• Haute disponibilité redondante interzone
• Sauvegarde et récupération