Réactivation d’objets blob à partir du niveau archive
Lorsqu’un objet blob se trouve au niveau d’accès aux archives, il est considéré comme étant hors ligne et ne peut pas être lu ou modifié. Pour pouvoir lire ou modifier des données dans un objet blob archivé, vous devez d’abord le réactiver dans un niveau en ligne, à savoir le niveau chaud ou froid. Il existe deux options possibles pour réactiver un objet blob stocké au niveau archive :
Copier un blob archivé vers un niveau en ligne : vous pouvez réhydrater un blob archivé en le copiant dans un nouveau blob du niveau chaud ou froid avec l'opération Copier le blob. Microsoft recommande cette option pour la plupart des scénarios.
Modifier un niveau d'accès aux objets blob archivés en un niveau en ligne : vous pouvez réhydrater un blob archivé au niveau chaud ou froid en modifiant son niveau à l'aide de l'opération Définir le niveau Blob.
La réactivation d’un objet blob à partir du niveau archive peut prendre plusieurs heures. Microsoft recommande d’archiver les blobs volumineux pour des performances optimales lors de la réalimentation. La réhydratation d’un grand nombre de petits objets blob peut nécessiter plus de temps en raison de la surcharge de traitement de chaque objet blob. Un maximum de 10 Gio par compte de stockage peut être réalimenté par heure avec extraction de priorité.
Pour savoir comment réhydrater un blob archivé dans un niveau en ligne, consultez Réhydrater un objet blob archivé dans un niveau en ligne.
Priorité de réactivation
Lorsque vous réhydratez un blob, vous pouvez définir la priorité de l’opération de réhydratation avec l’en-tête x-ms-rehydrate-priority facultatif sur une opération Définir le niveau du blob ou Copier le blob. Les options de priorité de réactivation sont les suivantes :
- Priorité standard : la requête de réalimentation est traitée dans l’ordre dans lequel elle a été reçue et son exécution peut prendre jusqu’à 15 heures pour les objets de taille inférieure à 10 Go.
- Priorité élevée : La demande de réhydratation est prioritaire par rapport aux demandes de priorité standard. Elle peut être effectuée en moins d’une heure pour les objets d’une taille inférieure à 10 Go.
Pour connaître la priorité de réactivation alors que l’opération de réactivation est en cours, appelez Get Blob Properties afin de retourner la valeur de l’en-tête x-ms-rehydrate-priority. La propriété de priorité de réactivation renvoie Standard ou Élevée.
La priorité standard constitue l’option de réactivation par défaut. Une réactivation de priorité élevée est plus rapide, mais aussi plus coûteuse qu’une réactivation de priorité standard. Elle peut prendre plus d’une heure en fonction de la taille de l’objet blob et de la demande actuelle. Microsoft recommande de réserver la réactivation de priorité élevée aux situations de restauration de données d’urgence.
Lorsqu’une opération de réhydratation de priorité standard est en attente, vous pouvez mettre à jour le paramètre de priorité de réhydratation d’un blob en le faisant passer à Élevée pour réhydrater ce blob plus rapidement. Par exemple, si vous réhydratez un grand nombre d’objets blob en bloc, vous pouvez spécifier la priorité Standard pour tous les objets blob dans le cadre de l’opération initiale, puis augmenter la priorité à Élevée pour tous les objets blob qui doivent être mis en ligne plus rapidement, jusqu’à la limite de 10 Gio par heure.
Le paramètre de priorité de réhydratation ne peut pas être abaissé d’Élevée à Standard pour une opération en attente. Gardez à l’esprit que la mise à jour du paramètre de priorité de réhydratation peut avoir un impact sur la facturation.
Pour savoir comment définir et mettre à jour le paramètre de priorité de réhydratation, consultez Réhydrater un objet blob archivé dans un niveau en ligne.
Pour plus d’informations sur les différences tarifaires entre les demandes de réactivation de priorité standard et de priorité élevée, consultez Tarification du Stockage Blob Azure.
Copier un objet blob archivé dans un niveau en ligne
La première option pour déplacer un objet blob du niveau archive vers un niveau en ligne consiste à copier l’objet blob archivé dans un nouvel objet blob de destination qui se trouve dans le niveau chaud ou froid. Vous pouvez utiliser l’opération Copier le blob pour copier le blob. Quand vous copiez un blob archivé vers un nouveau blob dans un niveau en ligne, le blob source reste inchangé dans le niveau archive.
Vous devez copier l’objet blob archivé dans un nouvel objet blob sous un autre nom ou dans un autre conteneur. Il n’est pas possible de remplacer l’objet blob source par le biais d’une copie.
Microsoft recommande d’effectuer une opération de copie dans la plupart des scénarios impliquant de déplacer un objet blob du niveau archive vers un niveau en ligne, pour les raisons suivantes :
Une opération de copie évite les frais de suppression anticipée qui sont évalués si un objet blob passe du niveau archive à un autre niveau avant que la période de 180 jours ne soit écoulée. Pour plus d’informations, voir Niveau d’accès archive.
Si une stratégie de gestion du cycle de vie est en vigueur pour le compte de stockage, la réhydratation d'un objet blob avec Définir le niveau d'objet blob peut entraîner un scénario dans lequel la stratégie de cycle de vie ramène l'objet blob au niveau d'archive après la réhydratation, car l'heure de la dernière modification dépasse le seuil défini. pour la politique. Une opération de copie laisse l’objet blob source dans le niveau d’archive et crée un nouveau blob avec un nom différent et une nouvelle heure de dernière modification. Il n’y a donc aucun risque que l’objet blob réhydraté soit replacé vers le niveau d’archive par la politique de cycle de vie.
La copie d’un blob à partir du niveau archive peut prendre plusieurs heures, en fonction de la priorité de réactivation sélectionnée. En arrière-plan, l’opération Copier l’objet blob lit l’objet blob source archivé pour créer un nouvel objet blob en ligne dans le niveau de destination sélectionné. Le nouveau blob peut être visible lorsque vous répertoriez les blobs dans le conteneur parent avant la fin de l’opération de réhydratation, mais son niveau sera défini sur archive. Les données ne sont pas disponibles tant que l’opération de lecture à partir du blob source dans le niveau d’archive n’est pas terminée et que le contenu du blob n’a pas été écrit dans le nouveau blob de destination dans un niveau en ligne. Le nouveau blob est une copie indépendante, donc sa modification ou sa suppression n’affecte pas le blob source dans le niveau archive.
Pour savoir comment réactiver un objet blob en le copiant dans un niveau en ligne, consultez Réactivation d’un objet blob avec une opération de copie.
Important
Ne supprimez pas l’objet blob source avant la fin de la réactivation. La copie de l’objet blob de destination risquerait de ne pas aboutir. Vous pouvez gérer l’événement qui se déclenche lorsque l’opération de copie est terminée pour savoir quand supprimer l’objet blob source en toute sécurité. Pour plus d’informations, consultez Gestion d’un événement déclenché lors de la réactivation d’objets blob.
La réactivation d’un objet blob archivé en le copiant vers un niveau de destination en ligne est pris en charge uniquement dans le même compte de stockage pour les versions de service antérieures à 2021-02-12. À compter de la version de service 2021-02-12, vous pouvez réactiver un objet blob archivé en le copiant vers un autre compte de stockage, tant que le compte de destination se trouve dans la même région que le compte source. La réactivation entre comptes de stockage vous permet de séparer vos données de production de vos données de sauvegarde en les plaçant dans des comptes distincts. L’isolation des données archivées dans un compte distinct peut également contribuer à limiter les coûts liés à la réactivation involontaire.
L’objet blob cible pour l’opération de copie doit se trouver dans un niveau en ligne (chaud ou froid). Il n’est pas possible de copier un objet blob archivé dans un objet blob de destination qui se trouve également dans le niveau archive.
Le tableau suivant indique le comportement d’une opération de copie d’objet blob, en fonction du niveau de l’objet blob source et de l’objet blob de destination.
| Source de niveau chaud | Source de niveau froid | Source de niveau d’archive | |
|---|---|---|---|
| Destination de niveau chaud | Prise en charge | Prise en charge | Prise en charge entre les comptes de la même région avec la version 2021-02-12 et ultérieure. Pris en charge dans le même compte de stockage uniquement pour les versions antérieures. Réactivation de l’objet blob nécessaire. |
| Destination de niveau froid | Prise en charge | Prise en charge | Prise en charge entre les comptes de la même région avec la version 2021-02-12 et ultérieure. Pris en charge dans le même compte de stockage uniquement pour les versions antérieures. Réactivation de l’objet blob nécessaire. |
| Destination du niveau d’archive | Prise en charge | Prise en charge | Non prise en charge |
Réhydrater à partir d’une région secondaire
Si vous avez configuré votre compte de stockage de manière à utiliser le stockage géoredondant avec accès en lecture (RA-GRS), vous pouvez utiliser l’opération Copier l’objet blob pour réhydrater les objets blob de la région secondaire vers un autre compte de stockage situé dans cette même région secondaire. Consultez Réhydrater à partir d’une région secondaire.
Pour en savoir plus sur l’obtention de l’accès en lecture aux régions secondaires, consultez Accès en lecture aux données dans la région secondaire.
Remplacement du niveau d’accès d’un objet blob par un niveau en ligne
La deuxième option pour réactiver un objet blob du niveau archive à un niveau en ligne consiste à modifier son niveau en appelant Définir le niveau de l’objet blob. Cette opération permet de remplacer le niveau de l’objet blob archivé par le niveau chaud ou froid.
Une demande Définir le niveau du blob ne peut pas être annulée une fois lancée. Pendant l’opération de réactivation, le paramètre de niveau d’accès de l’objet blob continue à s’afficher comme archivé jusqu’à ce que le processus de réactivation soit terminé. À la fin de l’opération, la propriété de niveau d’accès est mise à jour pour refléter le nouveau niveau.
Pour savoir comment réactiver un objet blob en remplaçant son niveau par un niveau en ligne, consultez Réactivation d’un objet blob en modifiant son niveau.
Attention
La modification du niveau d’un objet blob n’a pas d’incidence sur son heure de dernière modification. Si une stratégie de gestion du cycle de vie est en vigueur pour le compte de stockage, le fait de réactiver un objet blob avec Définir le niveau de l’objet blob peut donner lieu à un scénario dans lequel la stratégie de cycle de vie déplace l’objet blob vers le niveau archive après la réactivation, car l’heure de dernière modification dépasse le seuil défini pour la stratégie.
Pour éviter ce scénario, ajoutez la condition daysAfterLastTierChangeGreaterThan à l’action tierToArchive de la stratégie. Vous pouvez aussi réactiver l’objet blob archivé en le copiant, comme indiqué dans la section Copie d’un objet blob archivé dans un niveau en ligne. L’opération de copie crée une nouvelle instance de l’objet blob avec une heure de dernière modification mise à jour. Elle ne déclenche pas la stratégie de gestion du cycle de vie.
Vérification de l’état d’une opération de réactivation d’un objet blob
Pendant l’opération de réactivation d’un objet blob, vous pouvez appeler l’opération Obtenir les propriétés de l’objet blob pour connaître son état. Pour savoir comment vérifier l’état d’une opération de réactivation, consultez Vérification de l’état d’une opération de réactivation.
Gérer un événement lors de la réhydratation d’objets blob
La réhydratation d’un objet blob archivé peut prendre jusqu’à 15 heures. Il est par ailleurs inefficace d’interroger de manière répétée Obtenir les propriétés de l’objet blob pour déterminer si la réhydratation est terminée. Microsoft recommande d’utiliser Azure Event Grid pour capturer l’événement qui se déclenche à l’issue de la réalimentation pour de meilleures performances et une optimisation des coûts.
Azure Event Grid déclenche l’événement Microsoft.Storage.BlobTierChanged à la fin de la réhydratation des objets blob :
- L’événement Microsoft.Storage.BlobTierChanged se déclenche lors de la modification du niveau d’un objet blob. Dans le contexte de la réhydratation des objets blob, cet événement se déclenche lorsque le niveau d’accès d’un objet blob de destination passe du niveau archive au niveau en ligne (niveau chaud, sporadique ou froid). Vous pouvez utiliser l’opération Définir un niveau d’objet blob pour modifier le niveau d’accès d’un objet blob archivé ou l’opération Copier un objet blob pour copier un objet blob archivé vers un nouvel objet blob de destination dans un niveau en ligne.
Pour savoir comment capturer un événement déclenché en cas de réactivation et l’envoyer à un gestionnaire d’événements Azure Functions, consultez Exécution d’une fonction Azure Functions en réponse à un événement de réactivation d’objets blob.
Pour plus d’informations sur la gestion des événements dans le Stockage blob, consultez Réaction aux événements du Stockage Blob Azure et Stockage Blob Azure en tant que source Event Grid.
Tarification et facturation
Une opération de réactivation effectuée avec Définir le niveau de l’objet blob est facturée selon les transactions de lecture de données et la taille de l’extraction de données. Une réactivation de priorité élevée présente des coûts d’opération et d’extraction de données plus élevés qu’une réactivation de priorité standard. La réalimentation à haute priorité apparaît sous la forme d’un élément de ligne distinct sur votre facture. Si une demande de priorité élevée visant à renvoyer un blob archivé dont la taille est inférieure à 10 Go prend plus de cinq heures, le tarif de récupération haute priorité n’est pas appliqué. Toutefois, les tarifs de récupération standard s’appliquent toujours.
La copie d’un blob archivé sur un niveau en ligne avec l’opération Copier le blob est facturée selon les transactions de lecture de données et la taille de l’extraction de données. La création de l’objet blob de destination dans un niveau en ligne est facturée selon les transactions d’écriture de données. Aucun frais de suppression précoce n’est appliqué lorsque vous copiez vers un objet blob en ligne car l’objet blob source reste inchangé dans le niveau archive. Les frais d’extraction de priorité élevée s’appliquent si cette option est sélectionnée.
Les objets blob dans le niveau Archive doivent être stockés pendant un minimum de 180 jours. La suppression et la modification du niveau d’un objet blob archivé avant l’expiration de la période de 180 jours entraînent des frais de suppression anticipée. Par exemple, si un objet blob est déplacé vers le niveau de stockage archive puis supprimé ou déplacé vers le niveau de stockage chaud après 45 jours, des frais de suppression anticipée équivalents à 135 jours de stockage (180 moins 45) de cet objet blob dans le niveau de stockage archive vous seront facturés. Pour plus d’informations, voir Niveau d’accès archive.
Pour plus d’informations sur la tarification de la réalimentation des données et des objets blob de blocs, consultez Présentation de la tarification Stockage Azure. Pour plus d’informations sur les frais de transfert de données sortantes, consultez la page Détails de la tarification – Transferts de données.