Partager via

Sauvegarde continue avec restauration à un instant dans le passé dans Azure Cosmos DB

S’APPLIQUE À : NoSQL MongoDB Gremlin Tableau

La fonctionnalité de limite de restauration dans le temps d’Azure Cosmos DB vous aide dans plusieurs scénarios, notamment :

  • Effectuer une récupération suite à une opération d’écriture ou de suppression accidentelle dans un conteneur.
  • Restauration d’un compte, d’une base de données ou d’un conteneur supprimés.
  • Effectuer une restauration dans n’importe quelle région (où les sauvegardes existent) à un instant dans le passé.

Azure Cosmos DB effectue la sauvegarde des données en arrière-plan sans consommer de débit (RU) approvisionné supplémentaire et sans affecter les performances ou la disponibilité de votre base de données. Les sauvegardes continues sont effectuées dans chaque région où le compte existe. Par exemple, un compte peut avoir une région d’écriture USA Ouest et comme régions de lecture USA Est et USA Est 2. Ces régions de réplica peuvent ensuite être sauvegardées vers un compte de stockage Azure distant dans chaque région respective. Par défaut, chaque région stocke la sauvegarde dans les comptes de stockage localement redondants. Si la région a des zones de disponibilité activées, la sauvegarde est stockée dans des comptes de stockage redondant interzone.

Diagramme illustrant la façon dont un conteneur est sauvegardé dans plusieurs régions.

La fenêtre de temps disponible pour la restauration (également appelée période de rétention) est la valeur inférieure des deux options suivantes : 30 jours et 7 jours.

L’option sélectionnée dépend du niveau choisi de sauvegarde continue. Le point dans le temps de restauration peut être n’importe quel timestamp dans la période de rétention non plus loin que le point où la ressource a été créée. En mode d’uniformité forte, les sauvegardes prises dans la région d’écriture sont plus à jour par rapport aux régions lues. Les régions lues peuvent prendre du retard en raison de problèmes réseau ou autres problèmes d’origine. Lors de la restauration, vous pouvez obtenir le dernier timestamp pouvant être restauré pour une ressource donnée dans une région spécifique. La référence au dernier timestamp restaurable permet de confirmer que les sauvegardes de ressources sont conformes au timestamp donné et qu’elles peuvent être restaurées dans cette région.

Actuellement, vous pouvez restaurer le contenu d’un compte Azure Cosmos DB (API pour NoSQL ou MongoDB, API pour Table, API pour Gremlin) à un moment donné vers un autre compte. Vous pouvez effectuer cette opération de restauration via le portail Azure, Azure CLI, Azure PowerShell ou les modèles Azure Resource Manager.

Redondance du stockage de sauvegarde

Par défaut, Azure Cosmos DB stocke les données de sauvegarde en mode continu dans des objets blob de stockage localement redondants. Pour les régions pour lesquelles la redondance de zone est configurée, la sauvegarde est stockée dans des objets blob de stockage redondants interzone. Dans le mode de sauvegarde continue, vous ne pouvez pas mettre à jour la redondance du stockage de sauvegarde.

Différentes façons de restaurer

Le mode de sauvegarde continue prend en charge deux façons de restaurer des conteneurs et des bases de données supprimés. Ils peuvent être restaurés dans un nouveau compte ou dans un compte existant. Le choix entre ces deux modes dépend des scénarios. Dans la plupart des cas, il est préférable de restaurer des conteneurs et des bases de données supprimés dans un compte existant. Cela évite le coût du transfert de données requis lors de la restauration vers un nouveau compte. Pour les scénarios où la modification accidentelle des données a été effectuée, la restauration dans un nouveau compte peut être l’option préférée.

Quels éléments sont restaurés dans un nouveau compte ?

Dans un état stable, toutes les mutations effectuées sur le compte source (notamment les bases de données, conteneurs et éléments) sont sauvegardées de façon asynchrone dans les 100 secondes. Si le support de sauvegarde (stockage Azure) est en panne ou indisponible, les mutations sont conservées localement jusqu’à ce que le média soit disponible. Les mutations sont ensuite vidées pour éviter toute perte de fidélité des opérations qui peuvent être restaurées.

Vous pouvez choisir de restaurer le compte entier ou toute combinaison de conteneurs de débit provisionnés ou de bases de données de débit partagées. L’action de restauration restaure toutes les données et leurs propriétés d’index dans un nouveau compte. Le processus de restauration garantit que toutes les données restaurées dans un compte, une base de données ou un conteneur sont cohérentes jusqu’à l’heure de restauration spécifiée. La durée de restauration dépend de la quantité de données qui doivent être restaurées. Le paramètre de cohérence du compte de base de données nouvellement restauré est identique aux paramètres de cohérence du compte de base de données source.

Remarque

Avec le mode de sauvegarde continue, les sauvegardes sont effectuées dans chaque région où votre compte Azure Cosmos DB est disponible. Les sauvegardes effectuées pour chaque compte de région sont localement redondantes par défaut et redondantes interzone si la fonctionnalité de zone de disponibilité de votre compte est activée pour cette région. L’action de restauration restaure toujours les données dans un nouveau compte.

Qu’est-ce qui n’est pas restauré ?

Les configurations suivantes ne sont pas restaurées après la restauration à un instant dans le passé :

  • Il n’est pas possible de restaurer un sous-ensemble de conteneurs sous une base de données à débit partagé. La base de données entière peut être restaurée dans son ensemble.
  • Pare-feu, réseau virtuel, contrôle d’accès en fonction du rôle du plan de données ou paramètres de point de terminaison privé.
  • Toutes les régions du compte source.
  • Procédures stockées, déclencheurs, fonctions définies par l’utilisateur.
  • Affectations de contrôle d’accès en fonction du rôle.

Vous pouvez ajouter ces configurations au compte restauré une fois la restauration terminée.

Horodatage restaurable pour les comptes actifs

Pour restaurer des comptes Azure Cosmos DB qui ne sont pas supprimés, il est conseillé de toujours identifier le dernier horodatage restaurable du conteneur. Vous pouvez ensuite utiliser cet horodatage pour restaurer la dernière version du compte.

Scénarios de restauration

La fonctionnalité de restauration dans le temps prend en charge les scénarios suivants. Les scénarios 1 à 3 montrent comment déclencher une restauration si l’horodatage de restauration est connu au préalable. Toutefois, il existe des scénarios dans lesquels vous ne connaissez pas l’heure exacte de la suppression ou de l’altération accidentelle des données. Les scénarios 4 et 5 montrent comment découvrir l’horodatage de restauration à l’aide des nouvelles API de flux d’événements sur la base de données ou les conteneurs pouvant être restaurés.

Diagramme montrant les événements de cycle de vie avec des horodatages pour un compte restaurable.

  • Scénario 1 - Restaurer un compte supprimé : tous les comptes supprimés que vous pouvez restaurer sont visibles dans le volet Restauration . Par exemple, si le Compte A est supprimé à l’horodatage T3. Dans ce cas, l’horodatage juste avant T3, l’emplacement, le nom du compte cible, le groupe de ressources et le nom du compte cible sont suffisants pour effectuer une restauration à partir du portail Azure, de PowerShell ou de l’interface CLI.

    Événements de cycle de vie avec horodatages pour une base de données et un conteneur pouvant être restaurés.

  • Scénario 2 : restaurer des données d’un compte dans une région particulière : par exemple, si le compte A existe dans deux régions USA Est et USA Ouest à timestamp T3. Si vous avez besoin d’une copie du compte A dans la région USA Ouest, vous pouvez effectuer une restauration à un point dans le temps à partir du portail Azure, de PowerShell ou de l’interface CLI avec USA Ouest comme emplacement cible.

  • Scénario 3 : Récupérer à partir d’une opération d’écriture ou de suppression accidentelle dans un conteneur avec un horodatage de restauration connu : par exemple, si vous savez que le contenu du conteneur 1 dans la base de données 1 a été modifié accidentellement au timestamp T3. Vous pouvez effectuer une restauration à un point dans le temps à partir du portail Azure, de PowerShell ou de l’interface CLI dans un autre compte au timestamp T3 pour récupérer l’état souhaité du conteneur.

  • Scénario 4 - Restaurer un compte à un point précédent dans le temps avant la suppression accidentelle de la base de données : dans le portail Azure, vous pouvez utiliser le volet flux d’événements pour déterminer quand une base de données a été supprimée et trouver l’heure de restauration. Avec l’interface Azure CLI et PowerShell, vous pouvez également découvrir l’événement de suppression de la base de données en énumérant le flux des événements de la base de données, puis déclencher la commande de restauration avec les paramètres requis.

  • Scénario 5 : Restaurez un compte à un point précédent avant la suppression accidentelle ou la modification des propriétés du conteneur : dans le portail Azure, vous pouvez utiliser le volet flux d’événements pour déterminer quand un conteneur a été créé, modifié ou supprimé pour trouver l’heure de restauration. Avec l’interface Azure CLI et PowerShell également, vous pouvez découvrir tous les événements de conteneur en énumérant le flux des événements de conteneur, puis déclencher la commande de restauration avec les paramètres requis.

Autorisations

Azure Cosmos DB vous permet d’isoler et de restreindre les autorisations de restauration pour le compte de sauvegarde continue à un rôle ou à un principal spécifique. Pour plus d’informations, consultez Gérer les autorisations pour restaurer un compte Azure Cosmos DB.

Comprendre la restauration de compte d’écriture multirégion

Les écritures effectuées dans la région hub sont immédiatement confirmées et sauvegardées de manière asynchrone dans les 100 secondes. Dans les comptes à plusieurs écritures, toutes les mutations effectuées sur la région satellite sont envoyées à la région hub pour confirmation. La région hub vérifie si une résolution de conflit est nécessaire, affecte un horodatage de résolution de conflit après la résolution des conflits et renvoie le document à la région satellite. La région satellite sauvegarde uniquement les documents une fois la confirmation reçue du hub. En bref, le processus de restauration ne restaure que les documents confirmés par la région hub au moment du point de restauration.

Que se passe-t-il lors de la restauration d'un compte d’écriture multirégion ?

  • Les mutations qui ne sont pas encore confirmées par l’horodatage de restauration ne sont pas restaurées.
  • Les collections avec une stratégie de résolution de conflit personnalisée sont réinitialisées au dernier enregistreur en fonction du timestamp.

Remarque

La restauration à partir d’une région satellite est plus lente que celle effectuée dans la région hub, dans le cadre d’un compte multi-régions, pour permettre de valider localement les écritures provisoires ou de prendre les mesures nécessaires pour les annuler.

Pour en savoir plus sur la compréhension des horodatages dans un compte activé pour écriture multiple, consultez Compréhension des horodatages.

Exemple de scénario : Dans le cas d’un compte régional à écritures multiples comprenant deux régions, USA Est et USA Ouest, dont USA Est est la région pivot, la séquence d’événements suivante est prise en considération :

  • T1 : Le client écrit un document Doc1 vers la région USA Est (étant donné que usa Est est la région hub, l’écriture est immédiatement confirmée)

  • T2 : Le client écrit un document Doc2 vers l'Ouest des États-Unis

  • T3 : USA Ouest envoie Doc2 à USA Est pour confirmation

  • T4 : Les États-Unis de l'Est ont reçu Doc2, confirment le document et renvoient Doc2 aux États-Unis de l'Ouest.

  • T5 : USA Ouest reçoit la documentation confirmée Doc2

Dans ce scénario, si l’horodatage de restauration fourni est T3 pour la région hub en tant que source, seul Doc1 est restauré. Doc2 n’a pas été confirmé par hub par T3. Uniquement si l’horodatage de restauration est supérieur à T4, doc2 est restauré, car la restauration à T4 dans le satellite contient uniquement doc1, puisque doc2 n’est pas encore confirmé.

Tarifs

Le compte Azure Cosmos DB avec une sauvegarde continue de 30 jours a un coût mensuel supplémentaire pour stocker la sauvegarde. Le niveau de sauvegarde continue 30 jours ou 7 jours entraîne des frais pour restaurer vos données. Le coût de restauration est ajouté chaque fois que l’opération de restauration est lancée. Si vous configurez un compte avec la sauvegarde continue, mais que vous ne restaurez pas les données, seul le coût de stockage de la sauvegarde est facturé.

L’exemple suivant se base sur le prix d’un compte Azure Cosmos DB déployé dans la région USA Ouest. Le tarif et le calcul varient en fonction de la région. Pour connaître les dernières informations tarifaires, consultez la page des tarifs Azure Cosmos DB.

  • Tous les comptes activés avec la politique de sauvegarde continue avec 30 jours impliquent une charge mensuelle pour le stockage de la sauvegarde qui est calculée comme suit :

    0,20 USD/Go x taille des données en Go dans le compte x nombre de régions

  • Chaque appel d’API de restauration entraîne des frais ponctuels. Les frais sont une fonction de la quantité de données restaurées :

    0,15 USD/Go x taille des données en Go

Par exemple, si vous avez 1 To de données dans deux régions :

  • Le coût du stockage de sauvegarde est calculé comme 1000 * 0,20 * 2 = 400 $ par mois

  • Le coût de restauration est calculé comme 1000 * 0,15 = 150 $ par restauration

Conseil

Pour plus d’informations sur la mesure de l’utilisation actuelle des données de votre compte Azure Cosmos DB, consultez Explorer les insights Azure Monitor pour Azure Cosmos DB. Le niveau continu de 7 jours n’entraîne pas de frais de sauvegarde des données.

Niveau continu de 30 jours par rapport au niveau de 7 jours

  • La période de rétention d’un niveau est de 30 jours par rapport à 7 jours pour un autre niveau.
  • Le niveau de rétention de 30 jours est facturé pour le stockage de sauvegarde. Le niveau de rétention de sept jours n’est pas facturé.
  • La restauration est toujours facturée dans les deux niveaux

Durée de vie

  • Le processus de restauration par défaut restaure toutes les propriétés d’un conteneur, y compris sa configuration TTL par défaut. Cela peut entraîner la suppression de données si la restauration est effectuée sans désactiver le TTL. Pour empêcher la suppression, transmettez un paramètre pour désactiver TTL dans PowerShell (-DisableTtl $true) ou cli (--disable-ttl True) lors de la restauration.

Clés gérées par le client

Consultez Comment les clés gérées par le client affectent les sauvegardes continues pour découvrir :

  • la procédure de configuration de votre compte Azure Cosmos DB lors de l’utilisation de clés gérées par le client avec des sauvegardes continues ;
  • Comment les clés gérées par le client affectent les restaurations ?

Limites actuelles

Actuellement, la fonctionnalité de restauration dans le temps présente les limitations suivantes :

  • Les API Azure Cosmos DB pour SQL, MongoDB, Gremlin et Table prises en charge pour la sauvegarde continue. L’API pour Cassandra n’est pas pris en charge actuellement.

  • Azure Synapse Link pour les comptes de base de données utilisant le mode de sauvegarde continue est généralement disponible. La situation opposée, le mode de sauvegarde continue pour les comptes Synapse Link est en aperçu public. Les clients qui ont désactivé Synapse Link à partir des conteneurs ne peuvent pas migrer vers la sauvegarde continue. Et le magasin analytique n’est pas inclus dans les sauvegardes. Pour plus d’informations, consultez la sauvegarde de la base de données analytique.

  • Le compte restauré est créé dans la même région que celle où se trouve votre compte source. Vous ne pouvez pas restaurer un compte dans une région où le compte source n’existait pas.

  • La fenêtre de restauration est de seulement 30 jours pour le niveau continu de 30 jours et de sept jours pour le niveau continu de 7 jours. Il est possible de basculer d’un niveau à l’autre, mais les quantités réelles (7 ou 30) ne peuvent pas être modifiées. En outre, si vous passez du niveau 30 jours au niveau 7 jours, il existe un risque de perte de données au-delà du septième jour.

  • Les sauvegardes n’offrent pas automatiquement une géoreprise d’activité après sinistre. Une autre région doit être explicitement ajoutée pour la résilience du compte et de la sauvegarde.

  • Lorsqu’une restauration est en cours, ne modifiez pas et ne supprimez pas les stratégies de gestion des identités et des accès (IAM). Ces politiques accordent les autorisations pour que le compte puisse modifier n’importe quel réseau virtuel ou la configuration du pare-feu.

  • Les comptes Azure Cosmos DB pour MongoDB avec sauvegarde continue ne prennent pas en charge la création d’un index unique pour une collection existante. Pour ce compte, les index uniques doivent être créés en même temps que la collection, et cela doit être effectué uniquement à l’aide des commandes d’extension pour la création de collections.

  • Après la restauration, il est possible que pour certaines collections, l’index cohérent puisse être regénéré. Vous pouvez vérifier l’état de l’opération de régénération à l’aide de la propriété IndexTransformationProgress.

  • Les index uniques dans l’API pour MongoDB ne peuvent pas être ajoutés, mis à jour ou supprimés lorsque vous créez un compte en mode de sauvegarde continue. Ils ne peuvent également pas être modifiés lorsque vous migrez un compte d’un mode périodique vers le mode continu.

  • La restauration en mode continu peut ne pas restaurer le paramètre de débit valide à partir du point de restauration.

Étapes suivantes

  • Last updated on