Restauration dans le temps pour les objets blob de blocs
La limite de restauration dans le temps offre une protection contre les suppressions ou altérations accidentelles en vous permettant de restaurer des données d’objet blob de blocs à un état antérieur. La limite de restauration dans le temps est utile dans les scénarios où un utilisateur ou une application supprime accidentellement des données ou lorsqu’une erreur d’application endommage les données. La restauration dans le temps permet également de tester des scénarios qui nécessitent le rétablissement d’un jeu de données à un état connu avant d’exécuter d’autres tests.
La restauration à un instant dans le passé est prise en charge pour les comptes de stockage v2 à usage général au niveau de performance standard uniquement. Seules les données des niveaux d’accès chaud et froid peuvent être restaurées dans le cadre d’une limite de restauration dans le temps. La restauration à un instant dans le passé n’est pas encore prise en charge sur les comptes qui ont un espace de noms hiérarchique.
Pour savoir comment activer la restauration jusqu’à une date et heure pour un compte de stockage, consultez Effectuer une restauration jusqu’à une date et heure sur les données d’objet blob de blocs.
Fonctionnement de la restauration dans le temps
Pour activer la restauration dans le temps, vous créez une stratégie de gestion pour le compte de stockage et spécifiez une période de rétention. Pendant la période de rétention, vous pouvez restaurer les objets blob de blocs de l’état actuel à un état passé.
Pour lancer une restauration dans le temps, appelez l'opération Restaurer les plages d’objets blob et spécifiez un point de restauration en heure UTC. Vous pouvez spécifier des plages lexicographiques de noms de conteneurs et d’objets blob à restaurer ou omettre la plage pour restaurer tous les conteneurs dans le compte de stockage. Dix plages lexicographiques sont prises en charge par opération de restauration.
Stockage Azure analyse toutes les modifications apportées aux objets blob spécifiés entre le point de restauration demandé, spécifié en heure UTC, et le moment présent. L’opération de restauration est atomique, ce qui signifie qu’elle réussit entièrement à restaurer toutes les modifications ou qu’elle échoue. S’il existe des objets blob qui ne peuvent pas être restaurés, l’opération échoue, et les opérations de lecture et d’écriture sur les conteneurs concernés reprennent.
Le diagramme suivant montre le fonctionnement de la restauration à un point dans le temps. Un ou plusieurs conteneurs ou plages d’objets blob sont restaurés à leur état à n jours auparavant, où n est inférieur ou égal à la période de conservation définie pour la restauration à un point dans le temps. L’effet est le rétablissement des opérations d’écriture et de suppression qui se sont produites pendant la période de conservation.
Une seule opération de restauration à la fois peut être exécutée sur un compte de stockage. Une opération de restauration ne peut pas être annulée une fois qu’elle est en cours, mais une deuxième opération de restauration peut être effectuée pour annuler la première opération.
L’opération Restaurer les plages d'objets blob retourne un ID de restauration qui identifie de façon unique l’opération. Pour vérifier l’état d’une restauration dans le temps, appelez l’opération Obtenir l’état de la restauration avec l’ID de restauration renvoyé par l’opération Restaurer les plages d'objets blob.
Important
Lorsque vous effectuez une opération de restauration, Stockage Azure bloque les opérations de données sur les objets blob de la plage en cours de restauration pendant toute la durée de l’opération. Les opérations de lecture, d’écriture et de suppression sont bloquées dans l’emplacement principal. C’est la raison pour laquelle les opérations telles que l’énumération des conteneurs sur le portail Azure peuvent ne pas se dérouler comme prévu pendant que l’opération de restauration est en cours.
Les opérations de lecture à partir de l’emplacement secondaire peuvent se poursuivre pendant l’opération de restauration si le compte de stockage est géorépliqué.
Attention
La récupération jusqu’à une date et heure prend en charge la restauration des opérations qui ont agi sur les objets blob de blocs uniquement. Toutes les opérations qui ont agi sur des conteneurs ne peuvent pas être restaurées. Par exemple, si vous supprimez un conteneur du compte de stockage en appelant l’opération Supprimer le conteneur, ce conteneur ne peut pas être restauré à l’aide d’une opération de récupération jusqu’à une date et heure. Au lieu de supprimer un conteneur entier, supprimez chacun des objets blob si vous souhaitez les restaurer plus tard.
Conditions préalables pour une restauration dans le temps
La limite de restauration dans le temps implique que les fonctionnalités Stockage Azure suivantes soient activées avant la restauration :
Pour en savoir plus sur les recommandations de Microsoft en matière de protection des données, consultez Vue d’ensemble de la protection des données.
Attention
Après que vous avez activé le contrôle de version d’objet blob pour un compte de stockage, chaque opération d’écriture sur un objet blob dans ce compte entraîne la création d’une nouvelle version. Pour cette raison, l’activation du contrôle de version d’objets blob peut entraîner des coûts supplémentaires. Pour réduire les coûts, utilisez une stratégie de gestion du cycle de vie pour supprimer automatiquement les anciennes versions. Pour plus d’informations sur la gestion de cycle de vie, consultez Optimiser les coûts en automatisant les niveaux d’accès de Stockage Blob Azure.
Période de rétention pour une restauration dans le temps
Lorsque vous activez la restauration dans le temps pour un compte de stockage, vous spécifiez une période de rétention. Les objets blob de blocs de votre compte de stockage peuvent être restaurés au cours de la période de rétention.
La période de rétention commence quelques minutes après l’activation de la récupération jusqu’à une date et heure. N’oubliez pas que vous ne pouvez pas restaurer des objets blob dans un état antérieur au début de la période de rétention. Par exemple, si vous avez activé la restauration à un instant dans le passé le 1er mai avec une rétention de 30 jours, alors le 15 mai, vous pouvez effectuer une restauration pour un maximum de 15 jours. Le 1er juin, vous pouvez restaurer les données entre 1 et 30 jours.
La période de rétention pour la restauration dans le temps doit être inférieure ou égale à la période de rétention spécifiée pour la suppression réversible. Par exemple, si la période de rétention de la suppression réversible est définie sur 7 jours, la période de rétention de la restauration à un instant dans le passé peut être comprise entre 1 et 6 jours.
Notes
La période de rétention que vous spécifiez pour la restauration à un instant dans le passé n’a aucun effet sur la rétention des versions d’objets blob. Les versions d’objets blob sont conservées jusqu’à ce qu’elles soient supprimées explicitement. Pour optimiser les coûts en supprimant ou en hiérarchisant les versions plus anciennes, créez une stratégie de gestion du cycle de vie. Pour plus d’informations, consultez Optimiser les coûts en gérant automatiquement le cycle de vie des données.
Le temps nécessaire à la restauration d’un jeu de données dépend du nombre d’opérations d’écriture et de suppression effectuées au cours de la période de restauration. Par exemple, la restauration à un instant situé 30 jours auparavant d’un compte avec 1 million d’objets blob, 3 000 objets blob ajoutés par jour et 1 000 objets blob supprimés par jour nécessite environ deux heures. Une période de rétention et une restauration à plus de 90 jours dans le passé ne sont pas recommandées pour un compte avec ce taux de changement.
Autorisations pour une restauration dans le temps
Pour lancer une opération de restauration, un client doit disposer d’autorisations en écriture sur tous les conteneurs du compte de stockage. Pour autoriser une opération de restauration avec Microsoft Entra ID, attribuez le rôle Contributeur de comptes de stockage au principal de sécurité au niveau du compte de stockage, du groupe de ressources ou de l’abonnement.
Limitations et problèmes connus
La restauration jusqu’à une date et heure pour les objets blob de blocs présente les limitations et les problèmes connus suivants :
- Seuls les objets blob de blocs d’un compte de stockage v2 standard à usage général peuvent être restaurés dans le cadre d’une opération de restauration jusqu’à une date et heure. Les objets blob d’ajout, les objets blob de pages et les objets blob de blocs Premium ne sont pas restaurés.
- Si vous avez supprimé un conteneur au cours de la période de rétention, ce conteneur n’est pas restauré lors de l’opération de restauration à un instant dans le passé. Si vous tentez de restaurer une plage d’objets blob incluant des objets blob dont le conteneur a été supprimé, l’opération de restauration à un instant dans le passé échoue. Pour en savoir plus sur la protection des conteneurs contre la suppression, consultez Suppression réversible pour les conteneurs.
- Si vous utilisez la suppression permanente pour purger les versions supprimées de manière réversible d’un objet blob pendant la période de rétention de la restauration à un instant dans le passé, il se peut qu’une opération de restauration ne puisse pas restaurer cet objet blob correctement.
- Si un objet blob a été déplacé entre les niveaux chaud et froid pendant la période comprise entre le moment présent et le point de restauration, l’objet blob est restauré à son niveau précédent.
- La restauration d’objets blob de blocs du niveau archive n’est pas prise en charge. Par exemple, si un objet blob a été déplacé du niveau d’accès chaud au niveau de stockage archive deux jours auparavant et qu’une opération de restauration est effectuée sur un point trois jours auparavant, l’objet blob n’est pas restauré vers le niveau d’accès chaud. Pour restaurer un objet blob archivé, commencez par le déplacer en dehors du niveau archive. Pour plus d’informations, consultez Vue d’ensemble de la réactivation d’objets blob à partir du niveau Archive.
- Les opérations de restauration partielle ne sont pas prises en charge. Par conséquent, si un conteneur contient des objets blob archivés, l’ensemble de l’opération de restauration échoue, car la restauration des objets blob de blocs dans le niveau archive n’est pas prise en charge.
- Si une stratégie d’immuabilité est configurée, une opération de restauration peut être lancée, mais les objets blob protégés par la stratégie d’immuabilité ne sont pas modifiés. Dans ce cas, une opération de restauration n’entraîne pas la restauration d’un état cohérent à la date et à l’heure indiquées.
- Un bloc qui a été chargé via Put Block ou Put Block à partir d’une URL, mais qui n’est pas validé via Put Block List, ne fait pas partie d’un objet blob et n’est donc pas restauré dans le cadre d’une opération de restauration.
- Si un objet blob avec un bail actif est inclus dans la plage à restaurer, et si la version actuelle de l’objet blob lié à un bail est différente de la version précédente à l’horodatage fourni pour PITR, l’opération de restauration échoue de manière atomique. Nous vous recommandons d’arrêter les baux actifs avant de lancer l’opération de restauration.
- L’exécution d’un basculement géré par le client sur un compte de stockage réinitialise le point de restauration le plus ancien possible pour le compte de stockage. Pour plus d’informations, consultez Restauration à un instant dans le passé.
- Les instantanés ne sont pas créés ou supprimés dans le cadre d’une opération de restauration. Seul l’objet blob de base est restauré à son état précédent.
- La restauration à un instant dans le passé n’est pas prise en charge pour les espaces de noms hiérarchiques ou les opérations via Azure Data Lake Storage Gen2.
- La restauration à un instant dans le passé n’est pas prise en charge quand la propriété AllowedCopyScope du compte de stockage est définie pour limiter l’étendue de la copie au même réseau virtuel ou locataire Microsoft Entra. Pour plus d’informations, consultez À propos de l’étendue autorisée pour les opérations de copie (préversion).
- La restauration à un instant dans le passé n’est pas prise en charge quand l’immuabilité au niveau de la version est activée sur un compte de stockage ou un conteneur dans un compte. Pour plus d’informations sur l’immuabilité de niveau version, consultez Configurer des stratégies d’immuabilité pour les versions de blob.
Important
Si vous restaurez des objets blob de blocs à un point antérieur au 22 septembre 2020, les limitations de la restauration jusqu’à une date et heure seront appliquées. Microsoft vous recommande de choisir un point de restauration égal ou postérieur au 22 septembre 2020 pour tirer parti de la fonctionnalité de restauration jusqu’à une date et heure généralement disponible.
Prise en charge des fonctionnalités
La prise en charge de cette fonctionnalité peut être impactée par l’activation de Data Lake Storage Gen2, du protocole NFS (Network File System) 3.0 ou du protocole SFTP (SSH File Transfer Protocol). Si vous avez activé l’une de ces fonctionnalités, consultez Prise en charge des fonctionnalités Stockage Blob dans les comptes Stockage Azure pour évaluer la prise en charge de cette fonctionnalité.
Tarification et facturation
Aucun frais n’est facturé pour activer la restauration à un instant dans le passé. Toutefois, l’activation de la récupération jusqu’à une date et heure active également le contrôle de version de blob, la suppression réversible et le flux de modification, qui peuvent occasionner des frais supplémentaires.
La facturation des opérations de restauration à un instant dans le passé est basée sur la quantité de données de flux de modification qui sont traitées pour la restauration. Toutes les transactions de stockage impliquées dans le processus de restauration vous sont également facturées.
Pour plus d’informations sur la tarification pour la restauration dans le passé, consultez Tarification des objets blob de blocs.