Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Un blob archivé est hors ligne et ne peut ni être lu ni modifié. Pour accéder à ses données, il suffit d’abord de réhydrater le blob à un niveau en ligne : chaud, froid ou froid. Utilisez l’une des méthodes de réhydratation suivantes :
Copie d’un blob archivé vers un niveau en ligne : Vous pouvez réhydrater un blob archivé en le copiant vers un nouveau blob dans le niveau chaud, intermédiaire ou froid à l’aide de l’opération Copier un blob.
Modifier le niveau d’accès d’un blob archivé pour le remplacer par un niveau en ligne : Vous pouvez réhydrater un blob archivé vers le niveau chaud, intermédiaire ou froid à l’aide de l’opération Set Blob Tier.
Important
Vous ne pouvez pas réhydrater directement les instantanés archivés ou les versions précédentes. Pour accéder aux données d’un instantané archivé ou d’une version précédente, vous devez les copier dans un nouveau blob d’un niveau en ligne (chaud, froid ou froid) en utilisant l’opération Copy Blob .
La réactivation d’un objet blob à partir du niveau archive peut prendre plusieurs heures. Archivez les blobs volumineux pour des performances de réhydratation optimales. La réhydratation d’un grand nombre de petits blobs peut demander plus de temps en raison de la surcharge de traitement sur chaque blob. Jusqu’à 10 Gio par compte de stockage peuvent être réhydratés par heure avec récupération prioritaire.
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 à l’aide de l’en-tête facultatif x-ms-rehydrate-priority sur une opération Set Blob Tier ou sur une opération Copy Blob. Les options de priorité de réactivation sont les suivantes :
- Priorité standard : La demande de réhydratation est traitée dans l’ordre dans lequel elle a été reçue et son exécution risque de prendre jusqu’à 15 heures pour les objets de moins de 10 Go.
- Priorité élevée : La demande de réhydratation est prioritaire par rapport aux demandes de priorité standard et peut être effectuée en moins d’une heure pour les objets de moins de 10 Go.
Pour connaître la priorité de réactivation alors que l’opération de réactivation est en cours, appelez Obtenir les propriétés de l’objet blob 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éhydratation prioritaire est plus rapide mais coûte plus cher qu’une réhydratation prioritaire standard. Une réhydratation à haute priorité peut prendre plus d’une heure, selon la taille du blob et la demande actuelle. Réservez la réhydratation prioritaire pour la restauration des 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.
Important
La limite de 10 Gio/heure s’applique au niveau du compte de stockage, pas par objet blob. Bien que des délais tels que « jusqu’à 15 heures » pour la priorité standard puissent s’appliquer à des blobs individuels dans des conditions idéales, ils ne s’adaptent pas de manière linéaire pour les opérations en masse. Si vous réhydratez de grands volumes de données, attendez-vous à des durées plus longues et planifiez en conséquence. Le débit est partagé entre tous les blobs en cours de réhydratation dans le même compte, et le dépassement de la limite horaire peut entraîner une limitation du débit ou des retards prolongés. Pour des performances optimales, envisagez de traiter par lot les demandes de réhydratation et de surveiller l’activité au niveau du compte.
Vous ne pouvez pas baisser la priorité de réhydratation de Haut à Standard pour une opération en cours. Mettre à jour la priorité peut affecter 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
Pour réhydrater un blob archivé en le copiant, utilisez l’opération Copy Blob pour créer un nouveau blob de destination dans les niveaux chaud, froid ou très froid. Le blob source reste inchangé dans la couche d’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.
En copiant un blob du niveau archive dans un niveau en ligne, vous pouvez éviter les frais de suppression anticipée qui sont évalués si vous changez le niveau d’un blob en le faisant passer 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.
Éviter le réarchivage de la stratégie de cycle de vie
La copie peut également empêcher une politique de gestion du cycle de vie de déplacer un blob réhydraté vers le niveau d’archive. Ce risque existe lorsque l’action tierToArchive de la stratégie n’inclut pas la condition daysAfterLastTierChangeGreaterThan et que la date de dernière modification du blob dépasse le seuil défini par la stratégie. Une opération de copie laisse le 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.
Surveiller la fin de la copie
La copie d’un blob depuis le niveau Archive peut prendre des heures, selon la priorité de réhydratation sélectionnée. L’opération de copie lit le bloc source archivé et crée un nouveau blob dans le niveau en ligne sélectionné. La nouvelle masse peut apparaître dans le contenant parent avant la fin de la réhydratation, mais son niveau reste archivé. Ses données deviennent disponibles après que le service ait lu le blob source et écrit son contenu sur le blob de destination. Le nouveau blob est une copie indépendante, donc le modifier ou le supprimer n’affecte pas le blob source archivé.
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 le blob source tant que la réhydratation n’est pas terminée avec succès. Si vous supprimez le blob source, le blob de destination pourrait ne pas finir de copier. Surveillez l’événement d’achèvement pour déterminer quand vous pouvez supprimer en toute sécurité le bloc source. Pour plus d’informations, voir Gérer un événement de réhydratation de blobs.
Copie entre comptes de stockage
La version du service 2021-02-12 et ultérieure prend en charge la réhydratation en copiant un blob archivé vers un autre compte de stockage dans la même région. Les versions de service antérieures ne prennent en charge la réhydratation qu’au sein du même compte de stockage. La réhydratation entre les comptes de stockage vous permet de séparer vos données de production de vos données de sauvegarde en les maintenant dans des comptes séparés. Isoler les données archivées dans un compte séparé peut également aider à réduire les coûts liés à une réhydratation involontaire.
Le blob cible pour l’opération de copie doit se trouver dans un niveau en ligne (chaud, froid ou très froid). Il n’est pas possible de copier un objet blob archivé dans un objet blob de destination se trouvant é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 à niveau froid | Source de niveau d’archive | |
|---|---|---|---|---|
| Destination de niveau chaud | Pris en charge | Pris en charge | Pris 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 | Pris en charge | Pris en charge | Pris 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 de stockage à froid | Pris en charge | Pris en charge | Pris 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 | Pris en charge | Pris en charge | Pris en charge | Non pris en charge |
Réhydrater à partir d’une région secondaire
Si votre compte de stockage utilise un stockage géo-redondant en accès en lecture (RA-GRS), utilisez l’opération Copier Blob pour réhydrater les blobs de la région secondaire vers un autre compte dans cette région. 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. Avec cette opération, vous pouvez changer le niveau de la masse archivée en chaud, froid ou froid.
Vous ne pouvez pas annuler une demande de Set Blob Tier après qu’elle ait commencé. Pendant la réhydratation, le niveau d’accès du blob reste défini sur Archive. Lorsque la réhydratation est terminée, la propriété de niveau d’accès affiche 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 le compte de stockage dispose d’une politique de gestion du cycle de vie , celle-ci peut déplacer le blob vers le niveau d’archive après la réhydratation lorsque le dernier délai de modification dépasse le seuil de la politique.
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. Effectuer une opération de copie crée une nouvelle instance du blob avec un temps de dernière modification mis à jour, afin de ne pas déclencher la politique 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 de réhydratation de blob
La réhydratation d’un blob archivé peut prendre jusqu’à 15 heures, et interroger de façon répétée Get Blob Properties est inefficace. Utilisez Azure Event Grid pour capturer l’événement d’achèvement afin de meilleures performances et des coûts réduits.
Azure Event Grid relance l’événement Microsoft.Storage.BlobTierChanged lorsque la réhydratation des blobs s’achève :
- L’événement
Microsoft.Storage.BlobTierChangedse déclenche lorsque le niveau d’un blob change. Pour la réhydratation des blobs, l’événement se déclenche lorsque le blob de destination passe avec succès du palier archive à un palier en ligne (chaud, froid ou froid).
Lorsque vous utilisez l’opération Copier un objet Blob pour copier un objet blob du niveau Archive vers une nouvelle destination d'objet blob dans un niveau en ligne (niveau chaud, cool ou froid) afin de réhydrater :
Azure Event Grid déclenche un
Microsoft.Storage.BlobCreatedévénement au début de l’opération de copiage. Le palier du blob est Archive.Après que le blob a été copié et réhydraté, Azure Event Grid lance un
Microsoft.Storage.BlobTierChangedévénement indiquant le passage de l’Archive au niveau en ligne spécifié.
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 Stockage Blob, voir Reacting to Azure Blob storage events et Stockage Blob Azure as Event Grid source.
Tarification et facturation
Pour Set Blob Tier, stockage Azure facture les transactions de lecture de données et la quantité de données récupérées. La réhydratation à haute priorité coûte plus cher que la priorité standard et apparaît comme une ligne distincte sur votre facture. Si une requête prioritaire pour un blob archivé inférieur à 10 Go prend plus de cinq heures, stockage Azure ne facture pas le taux de récupération prioritaire. Les tarifs standards de récupération restent en vigueur. Pour obtenir un exemple d’estimation de coût, consultez Estimation des coûts : Déplacer des données hors du stockage d’archivage.
Pour Copy Blob, stockage Azure facture les transactions de lecture de données, la quantité de données récupérées et les transactions d’écriture de données pour le blob de destination. Les frais de suppression anticipée ne s’appliquent pas car le bloc source reste inchangé dans le niveau d’archive. Des frais de récupération prioritaires s’appliquent si cette option est sélectionnée. Pour obtenir un exemple d’estimation, consultez Estimation des coûts : Récupérer des données à partir du stockage d’archivage à des fins d’analyse.
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 blob est déplacé vers le niveau d’archive puis supprimé ou déplacé vers le tier chaud après 45 jours, vous encourez des frais de suppression anticipée équivalents à 135 (180 moins 45) jours de stockage de ce blob dans le palier d’archive. Pour plus d’informations, voir Niveau d’accès archive.
Pour plus d’informations sur la tarification des blobs de blocs et la réhydratation des données, consultez Tarification stockage Azure. Pour plus d’informations sur les frais de transfert de données sortants, voir les détails des prix de transfert des données.