Sauvegarde et restauration dans un serveur flexible Azure Database pour PostgreSQL

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

Azure Database pour PostgreSQL effectue automatiquement des sauvegardes régulières 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. Le temps global de restauration et de récupération dépend généralement de la taille des données et de la quantité de récupération à effectuer.

Présentation de la sauvegarde

Azure Database pour PostgreSQL effectue des sauvegardes d’instantanés de fichiers de données et les stocke en toute sécurité dans un stockage redondant interzone ou 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é. Utilisez ces sauvegardes pour restaurer un serveur à n’importe quel point dans le temps dans 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, 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.

Vous ne pouvez pas exporter ces fichiers de sauvegarde ni les utiliser pour créer des serveurs en dehors de votre instance de 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 vous n’apportez aucune modification supplémentaire aux bases de données sur le serveur après la dernière sauvegarde d’instantané, le système suspend temporairement les sauvegardes d’instantanés. Dès que vous modifiez une base de données sur le serveur, le système prend immédiatement un nouvel instantané pour capturer les dernières modifications. Le premier instantané est une sauvegarde complète et des 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 règle générale, le délai de RPO (objectif de point de reprise) peut aller jusqu’à cinq minutes.

Options de redondance de sauvegarde

Azure Database pour PostgreSQL stocke plusieurs copies de vos sauvegardes pour protéger vos données contre les é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.

Azure Database pour PostgreSQL offre trois options :

  • Stockage de sauvegarde redondant interzone : Azure Database pour PostgreSQL sélectionne automatiquement cette option pour les régions qui prennent en charge les zones de disponibilité. Lorsque vous stockez des sauvegardes dans un stockage de sauvegarde redondant interzone, le service conserve trois copies des données dans la zone de disponibilité où votre serveur est hébergé. En outre, le service réplique les données vers une autre zone de disponibilité pour une protection supplémentaire.

    Cette option fournit une disponibilité des données de sauvegarde dans les zones de disponibilité et limite la réplication des données dans un pays ou une région pour répondre aux exigences de résidence des données. Il offre une durabilité d’au moins 99,9999999999 % (12 neufs) des objets de sauvegarde sur un an.

  • Stockage de sauvegarde localement redondant : Azure Database pour PostgreSQL sélectionne automatiquement cette option pour les régions qui ne prennent pas encore en charge les zones de disponibilité. Lorsque vous stockez des sauvegardes dans un stockage de sauvegarde localement redondant, le service stocke plusieurs copies de sauvegardes 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 service configure le stockage de sauvegarde des serveurs avec haute disponibilité dans la même zone, ou sans configuration de haute disponibilité, comme étant localement redondant.

  • Stockage de sauvegarde géoredondant : vous pouvez choisir cette option au moment de la création du serveur. Lorsque vous stockez des sauvegardes dans le stockage de sauvegarde géoredondant, en plus de trois copies de données stockées dans la région où votre serveur est hébergé, le service réplique les données dans une région géo-jumelée.

    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 chiffres neuf) des objets de sauvegarde sur un an.

    La géoredondance est prise en charge pour les serveurs hébergés dans l’une des régions jumelé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

Le serveur conserve les sauvegardes en fonction de la période de rétention que vous avez définie. Vous pouvez sélectionner une période de rétention comprise entre 7 (par défaut) et 35 jours. Définissez la période de rétention pendant la création du serveur ou modifiez-la ultérieurement. Le serveur conserve les sauvegardes même pour les serveurs arrêtés.

La période de rétention des sauvegardes détermine la période de récupération d’une restauration à un point dans le temps (PITR) à partir des sauvegardes disponibles. Vous pouvez également considérer la période de rétention de sauvegarde comme une fenêtre de récupération du point de vue de la restauration.

Le stockage de sauvegarde conserve toutes les sauvegardes requises pour effectuer un PITR au cours de la période de rétention des sauvegardes. Par exemple, si vous définissez la période de rétention de sauvegarde sur 7 jours, la fenêtre de récupération est les 7 derniers jours. Dans ce scénario, le stockage de sauvegarde conserve toutes les données et journaux requis pour restaurer et récupérer le serveur au cours des 7 derniers jours.

Coût du stockage de sauvegarde

Azure Database pour PostgreSQL fournit jusqu’à 100 % de votre stockage de serveur approvisionné en tant que stockage de sauvegarde sans frais supplémentaires. Vous payez pour tout stockage de sauvegarde supplémentaire que vous utilisez en gigaoctets par mois.

Par exemple, si vous approvisionnez un serveur avec 250 gibibytes (Gio) de stockage, vous obtenez 250 Gio de capacité de stockage de sauvegarde sans frais supplémentaires. Si l’utilisation quotidienne des sauvegardes est de 25 Gio, vous pouvez avoir jusqu’à 10 jours de stockage de sauvegarde gratuit. Vous payez pour la consommation de stockage de sauvegarde qui dépasse 250 Gio tel que défini dans le modèle tarifaire.

Si vous configurez votre serveur avec une sauvegarde géoredondante, les données de sauvegarde sont également copiées dans la région jumelée Azure. Par conséquent, la taille de votre sauvegarde est deux fois la taille de la copie de sauvegarde locale. La facturation est calculée en tant que ((2 x taille de sauvegarde locale) - taille de stockage approvisionnée) x prix @ gigaoctets par mois.

Utilisez la métrique De stockage de sauvegarde utilisée dans le portail Azure pour surveiller le stockage de sauvegarde qu’un serveur consomme. 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.

Note

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 une instance de serveur flexible Azure Database pour PostgreSQL, l’exécution d’un PITR crée un 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 par instantané vers l’emplacement de 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 est récupérée jusqu’à 10h00 du 15 août à l’aide de la sauvegarde du journal des transactions du 14 août 11h00 au 15 août 10h00.

Pour restaurer votre serveur de base de données, consultez l’une des rubriques suivantes :

Important

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

PITR est utile dans des scénarios comme ceux-ci :

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

En utilisant la sauvegarde continue des journaux des transactions, vous pouvez effectuer une restauration vers 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 restaure le serveur au dernier point dans le temps.

  • 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 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 restaure le serveur dans le temps le plus rapide possible au cours de 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 provisionne un serveur et restaure simplement la sauvegarde complète des instantanés. Il ne nécessite aucune récupération de journaux, ce qui le rend rapide. Sélectionnez un horodatage de sauvegarde supérieur au point de restauration le plus ancien dans le temps pour une opération de restauration réussie.

Le temps nécessaire à la récupération à l’aide des options de point 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 récupérées simultanément dans la même région. Le temps de récupération global prend 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

Vous pouvez restaurer des serveurs supprimés. Si vous supprimez le serveur, suivez les instructions de restauration d’un serveur supprimé pour récupérer. Utilisez le verrouillage des ressources Azure pour éviter la suppression accidentelle de votre serveur.

Sauvegarde et restauration géoredondantes

Pour activer la sauvegarde géoredondante à partir du volet Calcul + stockage dans le portail Azure, consultez Créer une base de données Azure pour PostgreSQL.

Important

Vous pouvez configurer la sauvegarde géoredondante uniquement lorsque vous créez le serveur.

Après avoir configuré votre serveur avec une sauvegarde géoredondante, vous pouvez le restaurer dans une région géo-jumelée. Pour plus d’informations, consultez les régions prises en charge pour la sauvegarde géoredondante.

Lorsque vous configurez le serveur avec une sauvegarde géoredondante, les données de sauvegarde et les journaux des transactions sont copiés de manière asynchrone dans la région jumelée via la réplication de stockage. Après la création du serveur, attendez au moins une heure avant de lancer une géo-restauration. Cette période d’attente permet au premier ensemble de données de sauvegarde d’être répliqué vers 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, le PITR des sauvegardes géoredondantes 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.

Pendant la géorestauration, vous pouvez modifier les configurations de serveur qui incluent des paramètres de réseau virtuel et la possibilité de supprimer la sauvegarde géoredondante du serveur restauré. La modification d’autres configurations du serveur - telles que le calcul, le stockage ou le niveau tarifaire (Burstable, Usage général ou Mémoire optimisée) - n’est pas prise en charge lors d’une géorestauration.

Pour plus d’informations, consultez Restaurer vers une région jumelée (géo-restauration).

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, consultez Restaurer vers une région jumelée (géo-restauration). Utilisez des réplicas géographiques comme stratégie de récupération d’urgence (DR) si vous devez configurer la DR pour n’importe quelle région, ou si la région primaire ne prend pas en charge les sauvegardes géoredondantes.

Utilisez des points de terminaison virtuels pour vos charges de travail stratégiques, car ils fournissent un point de connexion stable pour les applications, ce qui garantit une interruption minimale. Si vous avez un point de terminaison virtuel mappé à votre serveur principal, supprimez le point de terminaison virtuel du serveur principal. Une fois supprimé, ajoutez le même point de terminaison virtuel au serveur nouvellement créé. Ce processus garantit que la connectivité des applications reste cohérente et réduit les temps d’arrêt. Pour plus d’informations, consultez l’utilisation de points de terminaison virtuels pour un nom d’hôte cohérent pendant PITR.

Restauration et mise en réseau

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

Si vous configurez votre serveur source avec un réseau d’accès public , vous pouvez uniquement restaurer l’accès public.

Si vous configurez votre serveur source avec un réseau virtuel d’accè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.

La géorestauration

Si vous configurez votre serveur source avec un réseau d’accès public , vous pouvez uniquement restaurer l’accès public. En outre, vous devez appliquer des règles de pare-feu une fois l’opération de restauration terminée.

Si vous configurez votre serveur source avec un réseau virtuel d’accès privé , vous pouvez uniquement restaurer sur un autre réseau virtuel, car les réseaux virtuels ne peuvent pas s’étendre sur des 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, effectuez les tâches suivantes pour remettre vos utilisateurs et vos applications en service :

  • Si le nouveau serveur remplace 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 sur le serveur d’origine ne sont pas automatiquement appliquées au nouveau serveur. Veillez à reconfigurer tous les paramètres sur le nouveau serveur en fonction des exigences de ce nouveau serveur.

  • Vérifiez que les règles de pare-feu appropriées au niveau du serveur, les points de terminaison privés et les règles de réseau virtuel sont en place pour les connexions utilisateur. Ces règles ne sont pas copiées à partir du serveur d’origine.

  • 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é, procédez comme suit.

  • 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é, suivez les instructions dans Créer un réplica en lecture.

Sauvegardes à la demande

Votre instance de 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. Cette option est idéale 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.

Effectuez des sauvegardes à la demande en plus des sauvegardes automatiques planifiées. La fenêtre de rétention de sauvegarde détermine la durée de conservation de ces sauvegardes. Vous pouvez supprimer des sauvegardes à la demande à tout moment si elles ne sont plus nécessaires. Pour lancer une sauvegarde à la demande, sélectionnez l’instance de base de données que vous souhaitez sauvegarder et spécifiez un nom de sauvegarde. Ces sauvegardes sont stockées avec des sauvegardes automatisées, mais seuls les utilisateurs peuvent supprimer des sauvegardes à la demande. Le service gère et conserve les sauvegardes automatisées pour répondre aux exigences de rétention des sauvegardes.

Pour plus d’informations, consultez Effectuer des sauvegardes à la demande.

Limites

  • Le niveau de calcul du serveur burstable ne prend pas en charge la fonctionnalité de sauvegarde à la demande.
  • Le niveau de stockage SSDv2 ne prend pas en charge la fonctionnalité de sauvegarde à la demande.
  • Vous pouvez effectuer jusqu’à sept sauvegardes à la demande par instance de serveur flexible. La fenêtre de rétention de sauvegarde détermine la durée de conservation de ces sauvegardes.

Rétention à long terme

Sauvegarde Azure et les services Azure Database pour PostgreSQL fournissent une solution de sauvegarde à long terme de classe entreprise pour Azure Database pour PostgreSQL instances de serveur flexible qui conservent les sauvegardes pendant 10 ans maximum. Vous pouvez utiliser la rétention à long terme (LTR) indépendamment ou en même temps que la solution de sauvegarde automatisée proposée par 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 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 :

  • Sauvegardes planifiées et à la demande gérées par le client au niveau de chaque base de données.
  • 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 offre une plus grande flexibilité pour restaurer des données dans 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 (version préliminaire), protégeant vos données.
  • Prise en charge de la sauvegarde LTR pour les serveurs activés pour CMK

Limitations et considérations

  • Testez votre sauvegarde et restauration LTR immédiatement après la configuration pour vous assurer qu’elles répondent à vos besoins métier.
  • Les restaurations LTR sont actuellement disponibles uniquement sous forme de Restaurer en tant que fichiers dans des comptes de stockage, la fonctionnalité Restaurer en tant que serveur étant prévue pour l’avenir.
  • LTR sauvegarde toutes les bases de données dans les instances de serveur flexible, et vous ne pouvez pas sélectionner de bases de données individuelles pour la configuration LTR.
  • La sauvegarde LTR n’est pas prise en charge sur les réplicas, mais vous pouvez l’effectuer sur les serveurs principaux.
  • La taille de base de données maximale prise en charge pour les sauvegardes de conservation à long terme (LTR) est de 1 Tio.
  • Vous pouvez planifier des sauvegardes LTR hebdomadaires, mensuelles ou annuelles. La planification de sauvegarde quotidienne n’est actuellement pas prise en charge.
  • Les sauvegardes LTR ne prennent pas en charge les tables contenant une ligne avec une longueur BYTEA supérieure à 500 Mo.
  • Lorsque vous restaurez des rôles pour Microsoft Entra utilisateurs, vérifiez que l'authentification Microsoft Entra est activée et que vous êtes connecté en tant qu'administrateur Microsoft Entra pour créer des utilisateurs supplémentaires. La tentative de création de rôles Entra en tant qu’utilisateur normal entraîne des erreurs.

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

Questions fréquemment posées

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

    Par défaut, Azure Database pour PostgreSQL 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 sept 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, Azure Database pour PostgreSQL prend en charge un maximum de 35 jours de rétention. Utilisez des sauvegardes manuelles pour une exigence de rétention à long terme à l’aide de Sauvegarde Azure.

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

    Vous pouvez effectuer 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 Migrer votre base de données Azure Database pour PostgreSQL à l’aide du vidage 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 ?

    Yes. Toutes les données d’instance de serveur flexible Azure Database pour PostgreSQL, les sauvegardes et les fichiers temporaires créés pendant l’exécution des requêtes sont chiffrés via 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 base de données unique ou quelques bases de données dans un serveur ?

    La restauration d’une base de données unique ou de quelques bases de données ou 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 qu’une sauvegarde est en cours ?

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

  • Quand je configure la fenêtre de maintenance du serveur, dois-je tenir compte de 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 ?

    Votre instance de serveur flexible Azure Database pour PostgreSQL crée automatiquement des sauvegardes de serveur 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.

    Vous ne pouvez pas exporter ces fichiers de sauvegarde, car ils sont stockés dans des comptes de stockage gérés par Microsoft. Vous disposez d’un accès en lecture seule pour restaurer ces fichiers, mais vous ne pouvez pas les modifier ni les supprimer. Les fichiers de sauvegarde sont automatiquement supprimés après la période de rétention.

    Vous pouvez utiliser des sauvegardes uniquement pour restaurer votre serveur à un point dans le temps. La période de rétention de sauvegarde par défaut est de sept jours. Vous pouvez si vous le souhaitez configurer la conservation des sauvegardes jusqu’à 35 jours.

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

    Lorsque vous configurez le serveur avec une sauvegarde géoredondante, les données de sauvegarde sont stockées dans un compte de stockage géoredondant. 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 faire pitR 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 à haute disponibilité ?

    Les volumes de données d’une instance de serveur flexible Azure Database pour PostgreSQL sont sauvegardés via des captures instantanées incrémentielles de disque managé à partir du serveur principal. La sauvegarde WAL est effectuée à partir du serveur principal ou du serveur de secours.

  • Comment puis-je 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 de sauvegarde ou les fichiers ne sont pas exposés aux utilisateurs finaux.

  • Où puis-je voir l’utilisation de la sauvegarde ?

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

  • Que se passe-t-il pour 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. Le service conserve toutes les sauvegardes plus anciennes (dans la fenêtre de rétention) au moment de l’arrêt du serveur 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 me sont-elles facturées ?

    Azure Database pour PostgreSQL fournit jusqu’à 100 % de votre stockage de serveur approvisionné en tant que stockage de sauvegarde sans frais supplémentaires. Vous payez pour tout stockage de sauvegarde supplémentaire que vous utilisez, qui est facturé en gigaoctets par mois, tel que défini dans le modèle tarifaire.

    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 payez 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. Vous payez les données de sauvegarde excédentaires en fonction du prix de sauvegarde.

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

    Non. Qu’il s’agisse de serveurs HA ou non-HA, le service ne conserve qu’un seul jeu de copies de sauvegarde. Vous ne payez qu’une seule fois.

  • Comment restaurer mon serveur ?

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

    Pour restaurer votre serveur à partir de sauvegardes manuelles à l’aide d’outils tels que 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 à l’aide de pg_restore.

  • Puis-je effectuer une restauration vers une autre zone de disponibilité dans la même région ?

    Yes. 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. Toutefois, le minutage du processus de récupération qui applique les journaux (activités de transaction à relire) peut varier en fonction de la sauvegarde précédente de la date et de l’heure demandées et du nombre de journaux à traiter. Cette condition s’applique à la restauration dans la même zone et à la restauration des données dans une autre zone.

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

    Non. Le serveur est restauré en tant qu'instance de serveur flexible unique 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 ?

    Yes. 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 inversement ?

    Non. Actuellement, Azure Database pour PostgreSQL ne prend pas en charge la restauration de serveurs sur l’accès public et privé.

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

Contenu connexe

  • Last updated on