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

S’APPLIQUE À : NoSQL MongoDB Gremlin Table

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.
• Restaurer un compte, une base de données ou un conteneur supprimé.
• 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) provisionné 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 des comptes de stockage localement redondants. Si l’option Zones de disponibilité est activée pour la région, la sauvegarde est stockée dans des comptes de stockage redondants interzone.

Diagramme illustrant comment un conteneur avec une région d’écriture dans USA Ouest et des régions de lecture dans USA Est et USA Est 2 est sauvegardé. Le conteneur est sauvegardé dans un compte de Stockage Blob Azure distant dans chaque région d’écriture et de lecture respective.

La fenêtre de temps disponible pour la restauration (également appelée période de conservation) est la valeur inférieure parmi les deux éléments suivants : 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, comme indiqué ici, ou dans un compte existant, comme décrit ici. Le choix entre ces deux modes dépend des scénarios. Dans la plupart des cas, il est préférable de restaurer les conteneurs et les bases de données supprimés dans un compte existant. Cela permet d’éviter le coût du transfert de données nécessaire dans le cas où elles sont restaurées sur un nouveau compte. Dans le cas d’une modification accidentelle des données, la restauration sur un nouveau compte peut être l’option préférée.

Restauration des comptes d’écriture dans plusieurs régions (préversion)

Toutes les écritures effectuées sur la région hub sont immédiatement confirmées et sauvegardées de manière asynchrone dans les 100 secondes. Les mutations effectuées dans la région satellite (région qui ne résout pas les conflits) sont envoyées à la région centrale pour confirmation. La région hub vérifie si une résolution des conflits est nécessaire et affecte un timestamp résolu conflit après avoir résolu les conflits et les renvoie à la région satellite. La région satellite sauvegarde uniquement les entités une fois la confirmation reçue de la région hub.
En résumé, le processus de restauration ne restaure que les entités confirmées par le timestamp de résolution des conflits de la région pivot.

Remarque

Vous trouverez plus d’informations sur les comptes à plusieurs régions d’écriture ici, la région hub est la première région du portail.

Qu’est-ce qui n’est pas restauré pour les restaurations de comptes d’écriture multirégions (préversion) ?

Les mutations qui doivent encore être confirmées par le timestamp de la 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 de le timestamp.

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

Dans ce scénario, si le timestamp de restauration est T3, seule l’entity1 est restaurée. Entity2 n’a pas été confirmé par la région hub par T3. Uniquement si le timestamp de restauration > T4, l’entity2 est restaurée. T1 : Le client écrit un document Doc1 vers USA Est. (Étant donné que USA Est est la région hub, l’écriture est immédiatement confirmée)
T2 : Le client rédige un document Doc2 à l’intention de USA West. T3 : USA West envoie Doc2 à USA Est pour confirmation. T4 : USA Est reçoit Doc2, il confirme le document et envoie doc2 à USA West. T5 : USA West reçoit la documentation confirmée Doc2.

Dans ce scénario, si l’heure de restauration fournie est T3, seul le document Doc1 sera restauré. Doc2 n’a pas été confirmé par hub par T3. Ce n’est que si le timestamp de la restauration > est T4 que le doc2 sera restauré.

Remarque

La restauration dans la région du hub est prise en charge dans la préversion publique.

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 la restauration dépend de la quantité de données qui doit être restaurée. Le paramètre de cohérence du compte de base de données récemment restauré sera identique aux paramètres de cohérence du compte de base de données source.

Notes

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é zone de disponibilité est activée pour cette région dans votre compte. 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 réseau virtuel, contrôle d’accès en fonction du plan de données RBAC 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 fonction de restauration ponctuelle prend en charge les scénarios suivants. Les scénarios [1] à [3] montrent comment déclencher une restauration si l’horodatage de la 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 la restauration à l’aide des nouvelles API de flux d’événements sur la base de données ou les conteneurs pouvant être restaurés.

1. Restaurer le compte supprimé : tous les comptes supprimés que vous pouvez restaurer sont visibles dans le volet Restaurer. 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.

   

2. Restaurez les 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 à l’horodatage T3. Si vous avez besoin d’une copie du compte A dans USA Ouest, vous pouvez effectuer une restauration à un instant dans le passé à partir du portail Azure, de PowerShell ou de l’interface CLI avec USA Ouest comme localisation cible.

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 à l’horodatage T3. Vous pouvez effectuer une restauration à un instant dans le passé à partir du portail Azure, de PowerShell ou de l’interface CLI dans un autre compte à l’horodatage T3 pour récupérer l’état souhaité du conteneur.

4. Restaurer un compte à un instant dans le passé avant la suppression accidentelle de la base de données : dans le portail Azure, vous pouvez utiliser le volet de flux d’événements pour déterminer quand une base de données a été supprimée et rechercher l’heure de la 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.

5. Restaurez un compte à un instant antérieur dans le passé avant la suppression ou la modification accidentelle des propriétés du conteneur. – Dans le portail Azure, vous pouvez utiliser le volet de flux d’événements pour déterminer à quel moment un conteneur a été créé, modifié ou supprimé pour trouver l’heure de la 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 l’article Autorisations.

Tarification

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 de restauration de l’API entraîne un coût unique. Le coût est 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 de stockage de sauvegarde est calculé comme suit : (1 000 x 0,20 x 2) = 400 USD par mois

• Le coût de restauration est calculé comme suit : (1 000 x 0,15) = 150 USD 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 7 jours n’entraîne pas de frais pour la sauvegarde des données.

Niveau continu 30 jours par rapport au niveau continu 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 7 jours n’est pas facturé.
• La restauration est toujours facturée dans les deux niveaux

Clés gérées par le client

Consultez Comment les clés gérées par le client affectent-elles 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

La fonctionnalité de restauration à un instant dans le passé 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.

• Actuellement, Azure Synapse Link peut être activé dans les comptes de base de données de sauvegarde continue. Mais la situation inverse n’est pas encore prise en charge, et il n’est pas possible d’activer la sauvegarde continue dans les comptes de base de données compatibles Synapse Link. Et le magasin analytique n’est pas inclus dans les sauvegardes. Pour plus d’informations sur la sauvegarde et le magasin analytique, consultez sauvegarde du magasin 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 stratégies accordent les autorisations du compte pour modifier n’importe quel réseau virtuel ou toute configuration de pare-feu.

• Les comptes Azure Cosmos DB for MongoDB avec sauvegarde continue ne prennent pas en charge la création d’index unique pour une collection existante. Pour un compte de ce type, les index uniques doivent être créés avec leur collection à l’aide des commandes d’extension de création de collection.

• La fonctionnalité de limite de restauration dans le temps utilise toujours un nouveau compte Azure Cosmos DB. La restauration vers un compte existant n’est pas prise en charge pour l’instant. Si vous souhaitez fournir des commentaires sur la restauration sur place, contactez l’équipe d’Azure Cosmos DB par le biais de votre responsable de compte.

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

• Le processus de restauration rétablit toutes les propriétés d’un conteneur, y compris sa configuration TTL par défaut. Vous pouvez passer un paramètre pour désactiver le TTL lors de la restauration. Il est donc possible que les données restaurées soient supprimées immédiatement si vous les avez configurées de cette manière. Pour éviter cette situation, l’horodatage de la restauration doit être antérieur à l’ajout des propriétés TTL dans le conteneur.

• Les index uniques dans l’API pour MongoDB ne peuvent pas être ajoutés ou mis à jour 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

• Activez la sauvegarde continue avec le Portail Microsoft Azure, PowerShell, l’interface CLI ou Azure Resource Manager.
• Obtenir les derniers timestamps restaurables pour les comptes SQL et MongoDB.
• Restaurez le compte de sauvegarde continue avec le Portail Microsoft Azure, PowerShell, l’interface CLI ou Azure Resource Manager.
• Migrer vers un compte à partir d’une sauvegarde périodique vers une sauvegarde continue.
• Gérez les autorisations requises pour restaurer les données en mode de sauvegarde continue.
• Modèle de ressource du mode de sauvegarde continue.