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.

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.

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.

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 rôle RBAC 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 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

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

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, ce qui peut entraîner la suppression des données si la restauration est effectuée sans moyen de désactiver TTL. Pour empêcher la suppression, transmettez le 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

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.

• Les comptes Multi region write ne sont pas pris en charge.

• Synapse Link pour des comptes de base de données en utilisant le mode de sauvegarde continue est en disponibilité générale. Sinon, le mode de sauvegarde continue pour les comptes avec Synapse Link est en préversion publique. 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 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.

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

• 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

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