Partager via

Sauvegarder et restaurer dans Azure Database pour MySQL - Serveur flexible

  • Article

S’APPLIQUE À : Azure Database pour MySQL – Serveur flexible

Le serveur flexible Azure Database pour MySQL 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 point dans le temps. La sauvegarde et la restauration sont une partie essentielle de toute stratégie de continuité d’activité, dans la mesure où elles protègent vos données des corruptions et des suppressions accidentelles.

Présentation de la sauvegarde

Le serveur flexible Azure Database pour MySQL prend en charge deux types de sauvegardes pour offrir une flexibilité accrue pour maintenir les sauvegardes des données critiques pour l’entreprise.

Sauvegarde automatisée

Le serveur flexible Azure Database pour MySQL 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 stocka dans un stockage localement redondant. Celles-ci vous permettent de restaurer un serveur à n’importe quel point dans le temps au sein de votre période de rétention de sauvegarde configurée. La période de rétention de sauvegarde par défaut est de sept jours. Vous pouvez éventuellement configurer la sauvegarde de la base de données de 1 à 35 jours. Toutes les sauvegardes sont chiffrées à l’aide du chiffrement AES 256 bits pour les données stockées au repos.

Sauvegarde à la demande

Le serveur flexible Azure Database pour MySQL 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 point dans le temps, avec une réduction des temps de restauration allant jusqu’à 90 %. La période de rétention de sauvegarde par défaut est de sept jours. Vous pouvez éventuellement 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 à l’aide du 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 un serveur flexible Azure Database pour MySQL. 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 captures instantanées. La première sauvegarde de captures instantanées 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 cinq 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.

Remarque

  • Si le serveur est soumission à 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 à l’aide d’une mise à niveau des versions principales.

Options de redondance de sauvegarde

Le serveur flexible Azure Database pour MySQL 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. Le serveur flexible Azure Database pour MySQL 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 de serveur flexible Azure Database pour MySQL est localement redondant pour les serveurs avec haute disponibilité de même zone ou aucune configuration de haute disponibilité, et redondant interzone pour les serveurs avec une configuration 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 le serveur flexible Azure Database pour MySQL étend trois options aux utilisateurs :

  • Stockage de sauvegarde redondant localement : lorsque 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 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 : lorsque les sauvegardes sont stockées dans un stockage de sauvegarde redondant interzone, plusieurs copies ne sont pas uniquement stockées dans la zone de disponibilité dans laquelle votre serveur est hébergé, mais 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 : lorsque 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 associée géographiquement. Cela 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 l’une des régions Azure appairées.

Notes

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.

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

Vous pouvez déplacer votre stockage de sauvegarde existant vers 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 HA redondants interzone peuvent également être restaurés en tant que serveur géoredondant de la même façon que le stockage de sauvegarde sous-jacent est redondant localement.

  • Passer d’un stockage redondant interzone à un stockage de sauvegarde géoredondant - Le serveur flexible Azure Database pour MySQL ne prend pas en charge le stockage redondant interzone vers la conversion de stockage géoredondant par le biais des paramètres de calcul + stockage une fois le serveur approvisionné. Pour déplacer votre stockage de sauvegarde du stockage redondant interzone vers un stockage géoredondant, il existe deux options : a) Utiliser PITR (restauration à un point dans le temps) pour restaurer le serveur avec la configuration souhaitée. b) Créez un serveur avec la configuration souhaitée et migrez les données à l’aide de vidage et de 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 avec une période de rétention par défaut de sept 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 à l’aide du 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 des 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

Le serveur flexible Azure Database pour MySQL 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 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 Stockage de sauvegarde utilisé dans Azure MoniTor disponible dans le portail Azure pour surveiller le stockage de sauvegarde consommé par un serveur. La métrique utilisée Stockage de sauvegarde 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 se produisent à partir du serveur de base de données principal, car la surcharge est minime avec des sauvegardes de capture instantanée.

Afficher 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 afficher les horodateurs d’achèvement 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 à l’aide de ces sauvegardes complètes. La liste des sauvegardes disponibles comprend toutes les sauvegardes complètes dans la période de conservation, un horodatage indiquant l’achèvement de l’opération, un horodatage indiquant la durée de conservation d’une sauvegarde et une action de restauration.

Restaurer

Dans le serveur flexible Azure Database pour MySQL, 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 point dans le temps est disponible avec les deux options de redondance de la sauvegarde et elle crée un serveur dans la même région que votre serveur d’origine.
  • Géo-restauration : est disponible uniquement 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-jumelée ou toute autre région prise en charge par Azure où un 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 d’activité de transactions impliqués ;
  • la quantité d’activité devant être relue pour effectuer une récupération au point de restauration ;
  • 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 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 non haute disponibilité (haute disponibilité désactivée) après la restauration pour la restauration à un point dans le temps et la géorestauration.

Restauration à un instant donné

Dans le serveur flexible Azure Database pour MySQL, l’exécution d’une restauration dans le temps 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 de sauvegarde et l’option de redondance de sauvegarde. De plus, les étiquettes et les paramètres, par exemple, de réseau virtuel et de pare-feu, sont hérités du serveur source. Le niveau de calcul et de stockage du serveur restauré, la configuration et les paramètres de sécurité 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 à partir du serveur principal) après l’opération de restauration

  • time_zone : valeur à affecter à la valeur par défaut SYSTEM
  • event_scheduler : Pour les serveurs MySQL version 5.7, le paramètre serveur event_scheduler est automatiquement désactivé (OFF) lorsque 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 à l’aide d’une mise à niveau des versions principales.

La restauration à un point dans le temps 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 d’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, le point de restauration personnalisé et le point de restauration le plus rapide (restauration à l’aide d’une sauvegarde complète) via le portail Azure.

  • Dernier point de restauration : l’option de dernier point de restauration vous permet de restaurer le serveur au timestamp une fois l’opération de restauration 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 récupérer une erreur de l’utilisateur.
  • Point de restauration le plus rapide: cette option permet aux utilisateurs de restaurer le serveur dans le temps le plus rapide possible pendant 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 accomplie. 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 l’heure de la restauration. La récupération du journal des transactions est la partie la plus longue du processus de restauration. Si l’heure de restauration choisir 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 de serveur flexible Azure Database pour MySQL configurée avec une haute disponibilité redondante interzone, le serveur restauré est configuré dans la même région et zone que votre serveur principal, et déployé en tant que serveur unique en mode non HA. Pour un serveur flexible, consultez Haute disponibilité redondante interzone.

Important

Vous pouvez récupérer une ressource de serveur flexible Azure Database pour MySQL 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. À l’issue du déploiement, pour protéger les ressources du serveur d’une suppression accidentelle ou de changements inattendus, les administrateurs peuvent utiliser des verrous de gestion.

La géorestauration

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

La géorestauration constitue l’option de récupération par défaut lorsque 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 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 être jusqu’à une heure. Par conséquent, si une catastrophe se produit, il peut 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. Consultez restaurer un serveur flexible Azure Database pour MySQL avec Azure CLI pour en savoir plus sur la géorestauration d’un serveur avec Azure CLI.

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

Remarque

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

Important

Lorsque la région primaire est en panne, vous ne pouvez pas créer de serveurs géoredondants dans la région géo-jumelée respective, car le stockage ne peut pas être provisionné dans la région primaire. Il faut attendre que la région principale soit en service pour provisionner des serveurs géoredondants dans la région associée géographiquement. Lorsque la région principale est hors service, vous pouvez toujours géorestaurer le serveur source vers la région associée géographiquement en désactivant l’option de géoredondance dans les paramètres Calcul + Stockage (Configurer le serveur) dans l’expérience du portail de restauration et 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.
  • Configurez les alertes, selon les besoins.

Conservation à long terme (préversion)

Les services Sauvegarde Azure et serveur flexible Azure Database pour MySQL ont créé une solution de sauvegarde à long terme de qualité professionnelle pour les instances de serveur flexible Azure Database pour MySQL qui peut conserver des sauvegardes pendant 10 ans. Vous pouvez utiliser la conservation à long terme indépendamment ou en plus de la solution de sauvegarde automatisée proposée par le serveur flexible Azure Database pour MySQL 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 lorsque 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érez et monitorez toutes les opérations et tous les travaux liés à la sauvegarde dans des serveurs, groupes de ressources, emplacements, abonnements et tenants à d’un volet unique nommé 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 les comptes de stockage. La fonctionnalité RestoreasServer sera ajoutée à l’avenir.
  • Le support pour la création et la gestion de conservation à long terme via Azure CLI n’est actuellement pas pris en charge.

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

Sauvegarde et exportation à la demande (préversion)

Le serveur flexible Azure Database pour MySQL offre désormais 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)

  • Comment sauvegarder mon serveur ?

    Par défaut, le serveur flexible Azure Database pour MySQL active les sauvegardes automatisées de votre serveur entier (englobant 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 de serveur flexible Azure Database pour MySQL dans un stockage Blob, reportez-vous au blog de notre communauté technique : Sauvegarder un serveur flexible Azure Database pour MySQL 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 de captures instantanées est planifiée immédiatement après la création d’un serveur. Les sauvegardes d’instantanés sont effectuées une fois par jour. Les sauvegardes des journaux des transactions se produisent toutes les cinq minutes. Les fenêtres de sauvegarde sont par nature gérées par Azure et ne peuvent pas être personnalisées.

  • Mes sauvegardes sont-elles chiffrées ?

    Toutes les données de serveur flexible Azure Database pour MySQL, les sauvegardes et les fichiers temporaires créés pendant l’exécution des requêtes sont chiffrés à l’aide du chiffrement AES 256 bits. Le chiffrement de 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 point dans le temps, 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 une 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 ?

    Le serveur flexible Azure Database pour MySQL 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 de sauvegarde par défaut est de sept jours. Vous pouvez éventuellement configurer la sauvegarde de la base de données de 1 à 35 jours.

  • Comment vérifier mes sauvegardes ?

    Pour valider la disponibilité des sauvegardes terminées, la meilleure méthode consiste à afficher les sauvegardes automatisées complètes effectuées pendant la période de conservation dans le panneau Sauvegarde et restauration. Si une sauvegarde échoue, elle n’est pas répertoriée dans la liste des sauvegardes disponibles, et le service de sauvegarde essaie toutes les 20 minutes pour 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 - Métriques, vous trouverez stockage de sauvegarde utilisé métrique, qui peut vous aider à surveiller l’utilisation totale de la sauvegarde.

  • 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 les 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 nouveau serveur net qui a été restauré à l’aide 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. Toutefois, 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 du serveur configurée.

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

    Le serveur flexible Azure Database pour MySQL fournit jusqu’à 100 % de votre stockage de serveur approvisionné en tant que stockage de sauvegarde sans frais supplémentaires. Plus le stockage de sauvegarde utilisé est facturé en Go par mois conformément au modèle tarifaire. 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 total de sauvegarde utilisé directement.

  • 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 de sauvegarde pour le serveur actif est régie par sa fenêtre de rétention de sauvegarde.

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

    Pendant que votre instance de serveur est arrêtée, vous êtes facturé pour le stockage provisionné (y compris les IOPS provisionné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 uniquement aux serveurs actifs.

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

    Le serveur flexible Azure Database pour MySQL 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 ne peuvent être lues qu’à des fins de restauration et sont supprimées après la période de rétention. En outre, toutes les sauvegardes du serveur flexible Azure Database pour MySQL sont chiffrées à l’aide du chiffrement AES 256 bits pour les données stockées au repos.

  • Comment une opération de restauration à un point dans le temps 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.

  • Comment restaurer mon serveur ? Le portail Azure prend en charge la restauration à un point dans le temps pour tous les serveurs, ce qui permet aux utilisateurs de restaurer vers les 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 à l’aide de 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 devant ê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 à partir du 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.
    • 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 (point dans le temps de restauration), 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 heure PITR antérieure à l’heure à laquelle foreign_key_checks ont été désactivées. Nous vous recommandons de NE PAS modifier les variables de session pour qu’une opération de restauration à un point dans le temps réussisse.

Étapes suivantes