Sauvegarder et restaurer dans Azure Database pour PostgreSQL - Serveur flexible

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Les sauvegardes constituent une partie essentielle de toute stratégie de continuité de l’activité. Elles aident à protéger les données contre toute altération ou suppression accidentelle.

Azure Database pour PostgreSQL : le serveur flexible effectue automatiquement une sauvegarde régulière de votre serveur. Vous pouvez ensuite effectuer une récupération jusqu’à une date et heure (PITR) au cours d’une période de rétention que vous spécifiez. La durée globale d’une restauration et d’une récupération dépend de la taille des données et du taux de récupération à effectuer.

Présentation de la sauvegarde

Le serveur flexible Azure Database pour PostgreSQL effectue des sauvegardes de captures instantanées des fichiers de données et les stocke en toute sécurité dans le stockage redondant interzone ou dans un stockage localement redondant en fonction de la région. Le serveur sauvegarde également les journaux des transactions lorsque le fichier de journalisation en écriture anticipée (WAL) est prêt à être archivé. Ces sauvegardes vous permettent de restaurer un serveur à n’importe quel point dans le temps au cours de votre période de rétention des sauvegardes configurée.

La période de rétention des sauvegardes par défaut est de 7 jours, mais vous pouvez étendre la période à un maximum de 35 jours. Toutes les sauvegardes sont chiffrées à l’aide du chiffrement AES 256 bits pour les données stockées au repos.

Ces fichiers de sauvegarde ne peuvent pas être exportés ou utilisés pour créer des serveurs en dehors du serveur flexible Azure Database pour PostgreSQL. À cet effet, vous pouvez utiliser les outils PostgreSQL pg_dump et pg_restore/psql.

Fréquence de sauvegarde

Les sauvegardes sur les instances de serveur flexible Azure Database pour PostgreSQL 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 sont actuellement effectuées une fois par jour. Si aucune autre modification n’est apportée à des bases de données sur le serveur après le dernier instantané, les sauvegardes d’instantanés sont temporairement suspendues. Dès qu’une base de données sur le serveur est modifiée, un nouvel instantané est immédiatement pris pour capturer les dernières modifications. Le premier instantané est une sauvegarde complète et les instantanés consécutifs sont des sauvegardes différentielles.

Les sauvegardes de fichier journal des transactions ont lieu à une fréquence variable, en fonction de la charge de travail et du moment où le fichier WAL est rempli et prêt à être archivé. En général, le retard RPO (objectif de point de récupération) peut aller jusqu’à 5 minutes.

Options de redondance de sauvegarde

Le serveur flexible Azure Database pour PostgreSQL stocke plusieurs copies de vos sauvegardes pour vous aider à protéger vos données des événements planifiés et non planifiés. Ces événements peuvent inclure des défaillances matérielles ou du réseau temporaires ou des pannes de courant et des catastrophes naturelles. La redondance de sauvegarde permet de garantir que votre base de données est conforme à ses objectifs de disponibilité et de durabilité, même en cas d’erreurs.

Le serveur flexible Azure Database pour PostgreSQL offre trois options :

• Stockage de sauvegarde redondant interzone : cette option est sélectionnée automatiquement pour les régions qui prennent en charge les zones de disponibilité. Lorsque des sauvegardes sont stockées dans un stockage de sauvegarde géoredondant, trois copies des données sont conservées dans la région où votre serveur est hébergé. En outre, les données sont répliquées dans une région jumelée pour une protection ajoutée.

  Cette option fournit de la disponibilité de données de sauvegarde entre les zones de disponibilité et restreint la réplication des données dans un pays ou une région pour répondre aux exigences de résidence pour les données. Cette option offre au moins 99,9999999999 % (12 neuf) de durabilité des objets de sauvegarde sur une année.

• Stockage de sauvegarde redondant localement : cette option est sélectionnée automatiquement pour les régions qui ne prennent pas encore en charge les zones de disponibilité. 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. Cette option offre au moins 99,999999999 % (11 neuf) de durabilité des objets de sauvegarde sur une année.

  Par défaut, le stockage de sauvegarde pour les serveurs avec une configuration haute disponibilité dans la même zone ou une configuration sans haute disponibilité est défini sur redondant localement.

• Stockage de sauvegarde géoredondant : vous pouvez choisir cette option au moment de la création du serveur. Lorsque les sauvegardes sont stockées dans un stockage de sauvegarde géo-redondant, les copies multiples sont non seulement stockées dans la région où votre serveur est hébergé, mais également répliquées dans une région appairée géographiquement.

  Cette option vous permet de restaurer votre serveur dans une région différente en cas d’urgence. Il fournit également une durabilité d’au moins 99,99999999999999 % (16 neuf) des objets de sauvegarde sur une année.

  La géo-redondance est prise en charge pour les serveurs hébergés dans l’une des régions appairées Azure.

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

Vous pouvez configurer le stockage géo-redondant pour la sauvegarde uniquement lors de la création du serveur. Une fois le serveur configuré, vous ne pouvez pas modifier l’option de redondance du stockage de sauvegarde.

Rétention des sauvegardes

Les sauvegardes sont conservées en fonction de la période de rétention définie pour le serveur. Vous pouvez sélectionner une période de rétention comprise entre 7 (par défaut) et 35 jours. Vous pouvez définir la période de rétention lors de la création du serveur, ou la mettre à jour ultérieurement. Les sauvegardes sont conservées même pour les serveurs arrêtés.

La période de rétention des sauvegardes régit la période à partir de laquelle une restauration à un instant dans le passé (PITR) peut être récupérée à l’aide 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 récupération à une date et heure au cours de la période de rétention des sauvegardes sont conservées dans le stockage de sauvegarde. Par exemple, si la période de rétention des sauvegardes est définie sur 7 jours, la fenêtre de récupération est celle des 7 derniers jours. Dans ce scénario, toutes les données et tous les journaux d’activité nécessaires à la restauration et à la récupération du serveur au cours des 7 derniers jours sont conservés.

Coût du stockage de sauvegarde

Le serveur flexible Azure Database pour PostgreSQL fournit jusqu’à 100 % du stockage de votre stockage serveur configuré en tant que stockage de sauvegarde sans coût supplémentaire. Tout stockage de sauvegarde supplémentaire que vous utilisez est facturé en gigaoctets par mois.

Par exemple, si vous avez configuré un serveur avec 250 Gio de stockage, vous avez une capacité de stockage de sauvegarde de 250 Gio sans coût supplémentaire. Si l’utilisation quotidienne de la sauvegarde est de 25 Gio, vous pouvez avoir jusqu’à 10 jours de stockage de sauvegarde gratuit. Une consommation de stockage de sauvegarde supérieure à 250 Gio est facturée selon le modèle de prix.

Si vous avez configuré votre serveur avec une sauvegarde géo-redondante, les données de sauvegarde sont également copiées dans la région appairée Azure. La taille de votre sauvegarde sera donc deux fois supérieure à celle de la copie de sauvegarde locale. La facturation est calculée en tant que ((2 x taille de sauvegarde locale) - taille de stockage approvisionné) x prix @ Go/mois.

Vous pouvez utiliser la métrique Stockage de sauvegarde utilisé sur le portail Azure afin de surveiller le stockage de sauvegarde qui est consommé par un serveur. La métrique Stockage de sauvegarde utilisé 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 rétention des sauvegardes définie pour le serveur.

Notes

Quelle que soit la taille de la base de données, une activité transactionnelle importante sur le serveur génère plus de fichiers WAL. Le nombre de fichiers en hausse augmente à son tour le stockage de sauvegarde.

Récupération jusqu'à une date et heure

Dans le serveur flexible Azure Database pour PostgreSQL, l'exécution d'une récupération jusqu'à une date et heure crée un nouveau serveur dans la même région que votre serveur source, mais vous pouvez choisir la zone de disponibilité. Il est créé avec la configuration du serveur source pour le niveau tarifaire, la génération de calcul, le nombre de vCores, la taille de stockage, la période de rétention des sauvegardes et l’option de redondance de sauvegarde.

Les fichiers de la base de données physique sont d’abord restaurés à partir des sauvegardes d’instantanés à l’emplacement des données du serveur. La sauvegarde appropriée qui a été effectuée avant le point dans le temps souhaité est automatiquement choisie et restaurée. Un processus de récupération est ensuite lancé à l’aide des fichiers WAL pour ramener la base de données à un état cohérent.

Par exemple, supposons que les sauvegardes soient effectuées à 23h00, chaque nuit. Si le point de restauration est le 15 août à 10h00, la sauvegarde quotidienne du 14 août est restaurée. La base de données sera récupérée jusqu’au 15 août, 10h00, à l’aide de la sauvegarde de fichier journal du 14 août, 23h00, au 15 août, 10h00.

Pour restaurer votre serveur de base de données, consultez ces étapes.

Important

Une opération de restauration sur un serveur flexible Azure Database pour PostgreSQL crée toujours un nouveau serveur de base de données avec le nom que vous fournissez. Il ne remplace pas la base de données existante.

La récupération jusqu`à une date et heure est utile dans des scénarios, tels que les suivants :

• Un utilisateur supprime accidentellement des données, une table ou une base de données.
• Une application remplace accidentellement des données correctes par des données incorrectes à cause d’un défaut de l’application.
• Vous souhaitez cloner votre serveur pour le test, le développement ou pour la vérification des données.

Grâce à la sauvegarde continue des journaux des transactions, vous pouvez restaurer la dernière transaction. Vous pouvez choisir entre les options de restauration suivantes :

• Dernier point de restauration (maintenant) : il s'agit de l'option par défaut, qui vous permet de restaurer le serveur selon le dernier instant dans le passé.

• Point de restauration personnalisé : cette option vous permet de choisir n’importe quel point dans le temps au cours de la période de rétention définie pour cette instance de serveur flexible Azure Database pour PostgreSQL. Par défaut, l’heure UTC la plus récente est automatiquement sélectionnée. La sélection automatique est utile si vous souhaitez restaurer la dernière transaction effectuée à des fins de test. Vous pouvez éventuellement choisir d’autres jours et heures.

• Point de restauration rapide : cette option permet aux utilisateurs de restaurer le serveur le plus rapidement possible pendant la période de rétention définie pour leur instance de serveur flexible Azure Database pour PostgreSQL. La restauration la plus rapide est possible en choisissant directement le timestamp dans la liste des sauvegardes. Cette opération de restauration approvisionne un serveur et restaure simplement la sauvegarde d’instantané complète, et ne nécessite pas une 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 timestamp de sauvegarde supérieur au point de restauration le plus ancien dans le temps.

Le temps nécessaire à la récupération à l’aide des options de points de restauration les plus récentes et personnalisées varie en fonction de facteurs tels que le volume des journaux de transactions à traiter depuis la dernière sauvegarde et le nombre total de bases de données restaurées simultanément dans la même région. Le temps de récupération global est généralement de quelques minutes à quelques heures.

Si vous configurez votre serveur au sein d’un réseau virtuel, vous pouvez effectuer la restauration vers le même réseau virtuel ou vers un autre réseau virtuel. Cependant, vous ne pouvez pas effectuer une restauration sur un accès public. De la même façon, si vous avez configuré votre serveur avec un accès public, vous ne pouvez pas restaurer sur un accès réseau virtuel privé.

Important

Il est possible de restaurer des serveurs supprimés. Si vous supprimez le serveur, vous pouvez suivre nos instructions dans Restaurer une base de données Azure pour le serveur flexible Azure Database pour PostgreSQL afin de le restaurer. Utilisez le verrouillage des ressources Azure pour éviter la suppression accidentelle de votre serveur.

Sauvegarde et restauration géoredondantes

Pour activer la sauvegarde géo-redondante à partir du volet Calcul + Stockage sur le portail Azure, consultez le Guide de démarrage rapide.

Important

La sauvegarde géo-redondante ne peut être configurée qu’au moment de la création du serveur.

Une fois que vous avez configuré votre serveur avec une sauvegarde géo-redondante, vous pouvez le restaurer dans une région jumelée géographiquement. Pour plus d’informations, consultez les régions prises en charge pour la sauvegarde géo-redondante.

Lorsque le serveur est configuré avec une sauvegarde géo-redondante, les données de sauvegarde et journaux des transactions sont copiés de façon asynchrone dans la région appairée à l’aide de la réplication de stockage. Après la création du serveur, attendez au moins une heure avant de lancer une géo-restauration. Cela permet de répliquer le premier jeu de données de sauvegarde dans la région jumelée.

Ensuite, les journaux des transactions et les sauvegardes quotidiennes sont copiés de façon asynchrone dans la région jumelée. Il peut y avoir jusqu’à une heure de retard dans la transmission des données. Par conséquent, vous pouvez attendre jusqu’à une heure de RPO lorsque vous restaurez. Vous pouvez restaurer uniquement les dernières données de sauvegarde disponibles dans la région appairée. Actuellement, la récupération jusqu’à une date et heure de sauvegardes géo-redondantes n’est pas disponible.

La durée estimée de récupération du serveur RTO (objectif de temps de récupération) dépend de facteurs, tels que la taille de la base de données, l’heure de la dernière sauvegarde de la base de données et la quantité de WAL à traiter jusqu’à la dernière sauvegarde reçue. La durée de récupération totale est généralement comprise entre quelques minutes et quelques heures.

Lors de la géo-restauration, les configurations de serveur qui peuvent être modifiées incluent les paramètres de réseau virtuel et la possibilité de supprimer la sauvegarde géo-redondante à partir du serveur restauré. La modification d’autres configurations de serveur, telles que le calcul, le stockage ou le niveau tarifaire (Burstable, Usage général ou À mémoire optimisée), lors de la géo-restauration, n’est pas prise en charge.

Pour plus d’informations sur l’exécution d’une géo-restauration, consultez le Guide pratique.

Important

Lorsque la région principale est hors service, vous ne pouvez pas créer de serveurs géo-redondants dans la région appairée géographiquement, car le stockage ne peut pas être approvisionné dans la région principale. Il faut attendre que la région principale soit en service pour configurer des serveurs géo-redondants dans la région appairée géographiquement.

Si la région principale est hors service, vous pouvez toujours géo-restaurer le serveur source vers la région appairée géographiquement. Pour plus d’informations sur l’exécution d’une géo-restauration, consultez le Guide pratique. Vous devez utiliser des géoréplicas comme stratégie de récupération d’urgence si vous avez besoin de configurer la récupération d’urgence dans une quelconque région ou si la région primaire ne prend pas en charge les sauvegardes géoredondantes

Restauration et mise en réseau

Récupération jusqu'à une date et heure

Si votre serveur source est configuré avec un réseau d'accès public, vous pouvez uniquement effectuer une restauration vers un accès public.

Si votre serveur source est configuré avec un réseau virtuel avecaccès privé, vous pouvez effectuer une restauration sur le même réseau virtuel ou sur un autre réseau virtuel. Vous ne pouvez pas effectuer de récupération jusqu’à une date et heure à travers les accès publics et privés.

Géorestauration

Si votre serveur source est configuré avec un réseau d'accès public, vous pouvez uniquement effectuer une restauration vers un accès public. Les règles de pare-feu existantes du serveur source sont copiées sur le serveur restauré. Les points de terminaison privés ne sont pas transférés. Une fois l’opération de restauration terminée, vérifiez si vous devez ajuster les règles de pare-feu transférées et créez les points de terminaison privés dont vous avez besoin.

Si votre serveur source est configuré avec un réseau virtuel avecaccès privé, vous pouvez uniquement effectuer une restauration vers un autre réseau virtuel, car les réseaux virtuels ne peuvent pas couvrir plusieurs régions. Vous ne pouvez pas effectuer de géo-restauration à travers les accès publics et privés.

Tâches de post-restauration

Après avoir restauré le serveur, vous pouvez effectuer les tâches suivantes pour sauvegarder et exécuter vos utilisateurs et applications :

• Si le nouveau serveur est censé remplacer le serveur d’origine, redirigez les clients et les applications clientes vers le nouveau serveur. Modifiez le nom du serveur de votre chaîne de connexion pour qu’il pointe vers le nouveau serveur.

• Les valeurs de tous les paramètres de serveur sur le serveur d’origine ne sont pas automatiquement appliquées au nouveau serveur. Vérifiez que tous les paramètres du nouveau serveur sont reconfigurés conformément aux exigences de ce nouveau serveur.

• Vérifiez que les règles appropriées de pare-feu, de points de terminaison privés et de réseau virtuel au niveau serveur sont en place pour les connexions des utilisateurs. Dans le réseau d’accès public, les règles sont copiées depuis le serveur d’origine, mais elles peuvent ne pas être celles qui sont requises dans l’environnement restauré. Ajustez-les donc en fonction de vos besoins. Les points de terminaison privés ne sont pas transférés. Créez les points de terminaison privés dont vous avez besoin dans le serveur restauré. Dans le réseau virtuel d’accès privé, la restauration ne copie pas les artefacts d’infrastructure réseau de la source vers les réseaux du serveur restauré. Vous devez vous occuper de tout ce qui est lié à la configuration du VNET (réseau virtuel), des sous-réseaux ou des groupes de sécurité réseau dans le cadre d’une tâche postérieure à la restauration.

• Augmentez ou réduisez la taille du calcul du serveur restauré en fonction des besoins.

• 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.

• Si le serveur source à partir duquel vous avez restauré a été configuré avec une haute disponibilité et que vous souhaitez configurer le serveur restauré avec une haute disponibilité, vous pouvez suivre ces étapes.

• Si le serveur source à partir duquel vous avez restauré a été configuré avec des réplicas en lecture et que vous souhaitez configurer des réplicas en lecture sur le serveur restauré, vous pouvez suivre ces étapes.

Sauvegardes à la demande (préversion)

Le serveur flexible Azure Database pour PostgreSQL génère automatiquement des instantanés de volume de stockage de l’ensemble de votre instance de base de données, couvrant toutes les bases de données, dans le cadre de ses sauvegardes planifiées. En outre, vous pouvez créer une sauvegarde à la demande chaque fois que nécessaire, ce qui est idéal pour les scénarios tels que la préparation d’une opération potentiellement risquée ou l’exécution d’actualisations périodiques en dehors de la planification de sauvegarde habituelle.

Les sauvegardes à la demande peuvent être effectuées en plus des sauvegardes automatiques planifiées. Ces sauvegardes sont conservées en fonction de votre fenêtre de rétention de sauvegarde. Vous pouvez supprimer ces sauvegardes à la demande à tout moment si elles ne sont plus nécessaires. Pour lancer une sauvegarde à la demande, sélectionnez simplement l’instance de base de données que vous souhaitez sauvegarder et spécifiez un nom de sauvegarde. Ces sauvegardes sont stockées en même temps que les sauvegardes automatisées, mais seules les sauvegardes à la demande peuvent être supprimées par les utilisateurs, car les sauvegardes automatisées sont gérées et conservées par le service serveur flexible pour répondre aux exigences de rétention des sauvegardes.

Pour obtenir plus d’informations sur l’exécution d’une sauvegarde à la demande, consultez le guide pratique.

Limites

La fonctionnalité de sauvegarde à la demande n’est actuellement pas prise en charge avec le niveau de calcul de serveur Burstable.

Problèmes connus

Nous sommes conscients de l’existence d’un bogue qui permet d’effectuer des sauvegardes à la demande sur les réplicas, même si récupération jusqu`à une date et heure (PITR) n’est pas prise en charge dans ce contexte. Ce problème sera résolu pour s’assurer que les sauvegardes à la demande ne peuvent être effectuées que sur le serveur principal.

Conservation à long terme (préversion)

La Sauvegarde Azure et les services de serveur flexible Azure Database pour PostgreSQL ont créé une solution de sauvegarde à long terme de classe entreprise pour les instances de serveur flexible Azure Database pour PostgreSQL qui conservent les sauvegardes jusqu’à 10 ans. Vous pouvez utiliser la conservation à long terme (LTR) indépendamment ou en plus de la solution de sauvegarde automatisée proposée par un serveur flexible Azure Database pour PostgreSQL, qui offre une rétention allant jusqu’à 35 jours. Les sauvegardes automatisées sont des sauvegardes physiques 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 à répondre à vos besoins en matière de conformité, sont plus granulaires et sont prises en tant que sauvegardes logiques à l’aide de pg_dump natives. Outre la rétention à long terme, la solution offre les fonctionnalités suivantes :

• Sauvegarde planifiée et demande contrôlée par le client au niveau de la base de données individuelle.
• Surveillance centralisée de toutes les opérations et de tous les travaux.
• 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).
• L’utilisation de pg_dump permet une plus grande flexibilité dans la restauration des données entre différentes versions de base de données.
• Les coffres de sauvegarde Azure prennent en charge les fonctionnalités d’immuabilité et de suppression réversible (préversion), ce qui protège vos données.
• Prise en charge de la sauvegarde LTR pour les serveurs compatibles CMK

Limitations et considérations

• Les restaurations LTR sont actuellement disponibles uniquement sous « Restaurer en tant que fichiers » sur des comptes de stockage, avec la fonctionnalité « Restaurer en tant que serveur » prévue pour l’avenir.
• LTR sauvegarde toutes les bases de données dans des instances de serveur flexibles et les bases de données individuelles ne peuvent pas être sélectionnées pour la configuration LTR.
• La sauvegarde LTR n’est pas prise en charge sur les géoréplicas, mais elle peut être effectuée à partir de serveurs principaux.
• La taille maximale de la base de données prise en charge pour les sauvegardes LTR (Long-Term Retention) est de 4 Tio. Il est possible de tenter des sauvegardes sur des serveurs de plus de 4 Tio, mais celles-ci ne sont pas officiellement prises en charge et le succès des sauvegardes LTR pour de tels serveurs ne peut pas être garanti.
• Les sauvegardes LTR peuvent être planifiées toutes les semaines, tous les mois ou tous les ans. La planification quotidienne des sauvegardes n’est actuellement pas prise en charge.

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

Forum aux questions

Questions relatives à la sauvegarde

• Comment Azure gère la sauvegarde de mon serveur ?

  Par défaut, le serveur flexible Azure Database pour PostgreSQL active les sauvegardes automatisées de l’ensemble de votre serveur (englobant toutes les bases de données créées) avec une période de rétention par défaut de 7 jours. Les sauvegardes automatisées incluent une capture instantanée incrémentielle quotidienne de la base de données. Les fichiers journaux (WAL) sont archivés en continu dans le Stockage Blob Azure.

• Puis-je configurer des sauvegardes automatisées pour conserver les données à long terme ?

  Non. Actuellement, le serveur flexible Azure Database pour PostgreSQL prend en charge un maximum de 35 jours de rétention. Vous pouvez effectuer des sauvegardes manuelles et les utiliser pour les besoins de rétention à long terme en utilisant Sauvegarde Azure.

• Comment sauvegarder manuellement mes instances de serveur flexible Azure Database pour PostgreSQL ?

  Vous pouvez prendre manuellement un instantané physique à l’aide de la fonctionnalité de sauvegarde à la demande, vous pouvez également effectuer des sauvegardes logiques à l’aide de l’outil PostgreSQL pg_dump. Pour obtenir des exemples, consultez Migration de la base de données de votre serveur flexible Azure Database pour PostgreSQL à l’aide de la sauvegarde et de la restauration.

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

  Azure gère les fenêtres de sauvegarde, et vous ne pouvez pas les personnaliser. La première sauvegarde de capture instantanée complète est planifiée immédiatement après la création d’un serveur. Les sauvegardes de captures instantanées suivantes sont incrémentielles et sont effectuées une fois par jour.

• Mes sauvegardes sont-elles chiffrées ?

  Oui. Toutes les données et sauvegardes pour le serveur flexible Azure Database pour PostgreSQL ainsi que les fichiers temporaires créés pendant l’exécution d’une requête sont chiffrés en utilisant le chiffrement AES (Advanced Encryption Standard) 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 sur un serveur ?

  La restauration d’une ou plusieurs bases de données ou de tables n’est pas directement prise en charge. Toutefois, vous pouvez restaurer l’ensemble du serveur sur un nouveau serveur, puis supprimer les tables ou les bases de données dont vous n’avez pas besoin sur le nouveau serveur.

• Mon serveur est-il disponible pendant que la sauvegarde est en cours ?

  Oui. Les sauvegardes sont des opérations en ligne qui utilisent des captures instantanées. L’opération de capture instantanée 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 du serveur, dois-je prendre en compte la fenêtre de sauvegarde ?

  Non. Les sauvegardes sont déclenchées en interne dans le cadre du service géré et n’ont pas d’incidence sur la fenêtre de maintenance.

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

  Le serveur flexible Azure Database pour PostgreSQL crée automatiquement les sauvegardes et les stocke dans :

  • Stockage redondant interzone, dans les régions où plusieurs zones sont prises en charge.
  • Stockage redondant localement, dans les régions qui ne prennent pas encore en charge plusieurs zones.
  • La région jumelée, si vous configurez la sauvegarde géo-redondante.

  Ces fichiers de sauvegarde ne peuvent pas être exportés.

  Vous pouvez utiliser des sauvegardes uniquement pour restaurer votre serveur à un point dans le temps. Par défaut, la période de conservation des sauvegardes est de 7 jours. Vous pouvez si vous le souhaitez configurer la conservation des sauvegardes jusqu’à 35 jours.

• Avec la sauvegarde géo-redondante, à quelle fréquence la sauvegarde est-elle copiée dans la région appairée ?

  Lorsque le serveur est configuré avec une sauvegarde géo-redondante, les données de sauvegarde sont stockées sur un compte de stockage géo-redondant. Le compte de stockage copie les fichiers de données dans la région appairée lorsque la sauvegarde quotidienne se produit sur le serveur principal. Les fichiers WAL sont sauvegardés lorsqu’ils sont prêts à être archivés.

  Ces données de sauvegarde sont copiées de façon asynchrone en continu vers la région appairée. La réception des données de sauvegarde peut avoir jusqu’à une heure de retard.

• Puis-je effectuer des récupération jusqu`à une date et heure dans la région distante ?

  Non. Les données sont récupérées sur les dernières données de sauvegarde disponibles au niveau de la région distante.

• Comment les sauvegardes sont-elles effectuées dans des serveurs activés pour la haute disponibilité ?

  Les volumes de données du serveur flexible Azure Database pour PostgreSQL sont sauvegardés en utilisant des captures instantanées incrémentielles de disques managés du serveur principal. La sauvegarde WAL est effectuée à partir du serveur principal ou du serveur de secours.

• Comment vérifier que les sauvegardes sont effectuées sur mon serveur ?

  La meilleure façon de vérifier les sauvegardes consiste à effectuer une récupération jusqu’à une date et heure périodique et à vous assurer que les sauvegardes sont valides et qu’elles peuvent être restaurées. Les opérations ou les fichiers de sauvegarde ne sont pas exposés aux utilisateurs finaux.

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

  Dans le portail Azure, sous Surveillance, sélectionnez Métriques. Dans Stockage de sauvegarde utilisé, vous pouvez surveiller l’utilisation totale de la sauvegarde.

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

  Si vous supprimez un serveur, toutes les sauvegardes qui appartiennent au serveur sont également supprimées et ne peuvent pas être restauré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.

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

• Comment mes sauvegardes sont-elles facturées ?

  Le serveur flexible Azure Database pour PostgreSQL fournit jusqu’à 100 % du stockage de votre stockage serveur configuré en tant que stockage de sauvegarde sans coût supplémentaire. Tout stockage de sauvegarde supplémentaire que vous utilisez est facturé en gigaoctets par mois, comme défini dans le modèle de tarification.

  La période de rétention de sauvegarde et l’option de redondance de sauvegarde que vous sélectionnez, ainsi que l’activité transactionnelle sur le serveur, affectent directement la facturation et le stockage de sauvegarde total.

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

  Pendant que votre instance de serveur est arrêtée, aucune nouvelle sauvegarde n’est effectuée. Vous êtes facturé pour le stockage approvisionné 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. Toutes les données de sauvegarde excédentaires seront facturées en fonction du prix de la sauvegarde.

• J’ai configuré mon serveur avec une haute disponibilité redondante dans une zone. Effectuez-vous deux sauvegardes et serez-vous facturé deux fois ?

  Non. Que les serveurs soient ou non à haute disponibilité, un seul jeu de copies de sauvegarde est conservé. Vous n’êtes facturé qu’une seule fois.

Questions relatives à la restauration

• Comment restaurer mon serveur ?

  Azure prend en charge la récupération jusqu’à une date et heure pour tous les serveurs. Les utilisateurs peuvent effectuer une restauration à partir du dernier point de restauration ou d’un point de restauration personnalisé à l’aide du portail Azure, d’Azure CLI et de l’API.

  Pour restaurer votre serveur à partir des sauvegardes effectuées manuellement en utilisant des outils comme pg_dump, vous pouvez d’abord créer une instance de serveur flexible Azure Database pour PostgreSQL, puis restaurer vos bases de données sur le serveur en utilisant pg_restore.

• Est-ce que je peux effectuer une restauration vers une autre zone de disponibilité au sein de la même région ?

  Oui. Si la région prend en charge plusieurs zones de disponibilité, la sauvegarde est stockée sur un compte de stockage redondant interzone et vous permet d’effectuer une restauration dans une autre zone.

• Combien de temps une récupération jusqu’à une date et heure prend-elle ? Pourquoi ma restauration prend-elle autant de temps ?

  L’opération de restauration des données à partir d’une capture instantanée ne dépend pas de la taille des données. La durée du processus de récupération qui applique les journaux d’activité (activités de transaction à réappliquer) peut varier en fonction de la sauvegarde précédente effectuée à la date/heure demandée et de la quantité de journaux à traiter. Ceci s’applique à la fois à la restauration de données au sein de la même zone ou dans une autre zone.

• Si je restaure mon serveur activé pour la haute disponibilité, le serveur de restauration est-il automatiquement configuré avec la haute disponibilité ?

  Non. Le serveur est restauré en tant qu’instance de serveur flexible Azure Database pour PostgreSQL. Une fois la restauration terminée, vous pouvez si vous le souhaitez configurer le serveur avec la haute disponibilité.

• J’ai configuré mon serveur au sein d’un réseau virtuel. Puis-je effectuer une restauration vers un autre réseau virtuel ?

  Oui. Au moment de la restauration, choisissez un autre réseau virtuel pour la restauration.

• Puis-je restaurer mon serveur d’accès public sur un réseau virtuel ou vice versa ?

  Non. Actuellement, le serveur flexible Azure Database pour PostgreSQL ne prend pas en charge la restauration de serveurs entre accès public et privé.

• Comment faire le suivi de mon opération de restauration ?

  Actuellement, il n’existe aucun moyen d’effectuer le suivi de l’opération de restauration. Vous pouvez consulter le journal d’activité pour déterminer si l’opération est en cours ou terminée.

Étapes suivantes

• Découvrir la continuité de l’activité.
• Découvrir la haute disponibilité redondante interzone.
• Découvrez comment effectuer une restauration.