Matrice de support pour Azure PostgreSQL flexible server et elastic cluster vaulted backup (v2) (aperçu)

Sauvegarde Azure vous permet de protéger les serveurs flexibles et clusters élastiques Azure PostgreSQL avec des sauvegardes physiques (instantanés de disque). Cet article résume les régions, scénarios, configurations et limitations prises en charge de l’expérience v2.

Régions prises en charge pour Azure PostgreSQL serveur flexible et sauvegarde vaulted en cluster élastique (v2)

Les sauvegardes voûtées sont disponibles dans toutes les régions publiques sauf l’Indonésie centrale, la Malaisie Sud, le Mexique central, le Qatar central, le sud-est des États-Unis et l’ouest de l’Inde.

Sources de données et configurations prises en charge pour Azure PostgreSQL flexible server et Elastic cluster vaulted backup (v2)

Le tableau suivant liste les sources de données et configurations prises en charge pour le serveur flexible Azure PostgreSQL et la sauvegarde vaulted vaulted en cluster élastique (v2) :

Scénarios de sauvegarde pris en charge pour Azure PostgreSQL flexible server et Elastic cluster vaulted backup (v2)

Azure PostgreSQL serveur flexible et sauvegarde élastique en cluster (v2) prend en charge les scénarios de sauvegarde suivants :

• L’ensemble du serveur ou cluster est sauvegardé. La sauvegarde de bases de données individuelles n’est pas prise en charge.
• Un cluster élastique jusqu’à 8 nœuds est pris en charge.
• La première sauvegarde d’une source de données est une sauvegarde complète ; chaque sauvegarde après cela est incrémentale. Sauvegarde Azure effectue à nouveau une réplication initiale automatiquement si la chaîne d’instantanés est rompue.
• Des plannings de sauvegarde quotidiens ou hebdomadaires sont pris en charge, avec un objectif minimum de points de récupération d’un jour.
• La rétention peut être fixée de 7 jours à 10 ans, avec des durées de conservation indépendantes pour les points de récupération quotidiens, hebdomadaires, mensuels et annuels.
• Les sauvegardes à la demande (ad hoc) sont prises en charge après la configuration de la protection.
• Une instance de sauvegarde est prise en charge par source de données. La protection multiple du même serveur n’est pas prise en charge, donc un serveur est protégé soit par la pile v1, soit par la pile v2, jamais les deux.
• La politique de sauvegarde associée à une instance de sauvegarde peut être modifiée après la configuration de la protection.
• Un travail de sauvegarde est marqué Réussi une fois que l’instantané disque géré a été copié dans le coffre-fort.
• Les métadonnées des points de récupération, y compris la version PostgreSQL sur laquelle la sauvegarde a été effectuée, sont visibles sur chaque point de récupération.
• Les sauvegardes immuables WORM sont prises en charge. Lorsque l’immuabilité est activée et verrouillée sur le coffre de sauvegarde, les points de récupération ne peuvent pas être modifiés, écrasés ou supprimés avant l’expiration de leur période de conservation configurée, par aucun utilisateur, y compris un administrateur du coffre.

Scénarios de restauration pris en charge pour Azure PostgreSQL flexible server et elastic cluster vaulted backup (v2)

Azure PostgreSQL serveur flexible et sauvegarde élastique en cluster vaulted (v2) prennent en charge les scénarios de restauration suivants :

• Les restaurations sont effectuées sous le nom de Restauration en tant que serveur vers un emplacement alternatif. Le serveur flexible cible ou le cluster élastique doit être créé avant que la restauration ne soit déclenchée.
• Les données dans les tables non enregistrées ne sont pas préservées et sont perdues lors de la restauration.
• La cible peut être dans un abonnement différent au sein du même locataire.
• La restauration inter-régions est prise en charge.
• Les opérations de restauration à partir de sauvegardes effectuées sur des versions PostgreSQL qui ne sont plus prises en charge ne sont pas garanties.
• La restauration est prise en charge même après la suppression de la source de données.
• Une restauration n’est marquée Réussie que lorsque l’ensemble du point de récupération a été rétabli.
• Un point de récupération pris sur un serveur SSD Premium v1 restaure vers une cible SSD Premium v1. Un point de récupération pris sur un serveur SSD Premium v2 le restaure vers une cible SSD Premium v2.

Exigences ciblées pour la restauration

Le serveur flexible cible ou le cluster élastique doit répondre à tous les critères suivants, que Sauvegarde Azure valide avant le début de l’opération de restauration :

• Le serveur ou le cluster doit être vide.
• Le serveur ou le cluster ne doit pas être dans la couche de calcul Burstable.
• Le serveur ou cluster cible doit utiliser la même version majeure de PostgreSQL que le serveur source lors de la sauvegarde. La restauration échoue si les versions ne correspondent pas.
• Le serveur ou cluster cible doit avoir la même taille de disque que le serveur source. La restauration échoue si la taille du disque cible est inférieure à la taille du disque source, même si le point de récupération nécessite moins d’espace sur le disque cible.
• Le serveur ou le cluster ne doit pas avoir de haute disponibilité configurée.
• Le serveur ou le cluster ne doit pas avoir de géo-réplique configurée, et il ne doit pas lui-même être une géo-réplice.
• Le serveur ou le cluster doit se trouver dans la même région que le coffre-fort de sauvegarde.

Limitations pour Azure PostgreSQL flexible server et Elastic cluster vaulted backup (v2)

L’expérience v2 présente les limitations suivantes :

• La sauvegarde et la restauration au niveau de l’objet ne sont pas prises en charge. Vous ne pouvez pas sauvegarder ou restaurer une base de données, une table ou un objet individuel.
• Burstable Compute Tier n’est pas pris en charge. La configuration de la sauvegarde sur un serveur Burstable échoue à cause d’une erreur utilisateur. Mettez d’abord le serveur en mode Usage Général ou Mémoire Optimisée.
• PostgreSQL 14 et les versions antérieures ne sont pas prises en charge. La configuration de sauvegarde échoue pour les serveurs utilisant ces versions. Vous devez mettre à jour vers une version majeure prise en charge avant de configurer la sauvegarde, ou continuer à protéger le serveur avec la version 1.
• La sauvegarde n’est prise en charge que pour les serveurs principaux. On ne peut pas configurer de sauvegarde pour les répliques de lecture ou les géo-répliques. Si vous essayez de configurer une sauvegarde pour une réplique, l’opération échoue avec une erreur utilisateur.
• L’objectif du point de récupération d’un jour (RPO) n’est pas garanti dans tous les scénarios. La sauvegarde initiale et la réplication initiale qui s’ensuit transfèrent l’intégralité du contenu du disque et peuvent prendre plus d’une journée pour les grands serveurs et clusters. Les sauvegardes peuvent également dépasser une journée pour les serveurs avec des taux de désabonnement quotidiens élevés ou ceux utilisant un SSD Premium v2.
• Déplacer un objet protégé de v1 à v2 est une façon. Pour revenir à la version 1, arrêtez la protection et reconfigurez la sauvegarde sur la pile v1.
• La configuration de sauvegarde ne s’applique pas automatiquement au nouveau serveur principal après un basculement géographique prévu. La configuration de sauvegarde existante reste associée au serveur principal précédent, et ses sauvegardes commencent à échouer après le basculement. Pour protéger le nouveau serveur principal, configurez une sauvegarde sur ce serveur.

Étape suivante

• À propos d’Azure PostgreSQL flexible server et Elastic cluster vaulted backup (v2) (aperçu).

Contenu connexe

• Support matrix for Azure Database pour PostgreSQL - Flexible Server (v1)..