Rehidratación de blobs desde el nivel de archivo

Un blob archivado está offline y no puede ser leído ni modificado. Para acceder a sus datos, primero rehidrata el blob a un nivel online: caliente, frío o frío. Utiliza uno de los siguientes métodos de rehidratación:

Importante

No puedes rehidratar directamente instantáneas archivadas ni versiones anteriores. Para acceder a datos de una instantánea archivada o de una versión anterior, debes copiarlos a un nuevo blob en un nivel online (caliente, frío o frío) usando la operación Copiar Blob .

La rehidratación de un blob de un nivel de acceso de archivo puede tardar varias horas en completarse. Archive los blobs más grandes para obtener un rendimiento óptimo de rehidratación. La rehidratación de un gran número de blobs pequeños puede requerir más tiempo debido a la sobrecarga de procesamiento en cada blob. Se puede rehidratar un máximo de 10 GiB por cuenta de almacenamiento por hora con recuperación prioritaria.

Para información sobre cómo rehidratar un blob archivado a un nivel de servicio en línea, consulte Rehidratación de un blob archivado a un nivel en línea.

Prioridad de la rehidratación

Cuando rehidratas un blob, puedes establecer la prioridad de la operación mediante el encabezado opcional x-ms-rehydrate-priority en una operación Set Blob Tier o Copy Blob. Las opciones de prioridad de rehidratación incluyen:

  • Prioridad estándar: la solicitud de rehidratación se procesa en el orden en que se recibió y puede tardar hasta 15 horas para completar los objetos de menos de 10 GB de tamaño.
  • Alta prioridad: la solicitud de rehidratación tiene prioridad con respecto a las solicitudes de prioridad estándar y podría completarse en menos de una hora para objetos con un tamaño inferior a 10 GB.

Para comprobar la prioridad de rehidratación mientras se está en curso la operación de rehidratación, llame a BLObGet Blob Properties para devolver el valor del encabezado x-ms-rehydrate-priority. La propiedad de prioridad de rehidratación devuelve Standard o High.

La prioridad estándar es la opción de rehidratación predeterminada. Una rehidratación de alta prioridad es más rápida pero cuesta más que una rehidratación de prioridad estándar. Una rehidratación de alta prioridad puede tardar más de una hora, en función del tamaño del blob y de la demanda actual. Reserve la rehidratación de alta prioridad para la restauración urgente de datos.

Mientras esté pendiente una operación de rehidratación de prioridad estándar, puede actualizar la configuración de prioridad de rehidratación de un blob a Alta para rehidratar ese blob más rápidamente. Por ejemplo, si va a rehidratar un gran número de blobs de forma masiva, puede especificar la prioridad Estándar para todos los blobs para la operación inicial y aumentar la prioridad a Alta para los blobs individuales que necesiten ponerse en línea más rápidamente, hasta el límite de 10 GiB por hora.

Importante

El límite de 10 GiB/hora se aplica en el nivel de cuenta de almacenamiento, no por blob. Aunque plazos como "hasta 15 horas" para prioridad estándar pueden aplicarse a bloques individuales en condiciones ideales, no escalan linealmente para operaciones masivas. Si rehidratas grandes volúmenes de datos, el proceso tardará más, así que planifica en consecuencia. El rendimiento se comparte entre todos los blobs que se están rehidratando en la misma cuenta, y superar el límite por hora puede dar lugar a una limitación de velocidad o a retrasos prolongados. Para obtener un rendimiento óptimo, considere la posibilidad de procesar por lotes solicitudes de rehidratación y supervisar la actividad de nivel de cuenta.

No puedes bajar la prioridad de rehidratación de Alta a Estándar para una operación pendiente. Actualizar la prioridad podría afectar a la facturación.

Para obtener información sobre cómo establecer y actualizar la configuración de prioridad de rehidratación, consulte Rehidratación de un blob archivado en un nivel en línea.

Para más información sobre las diferencias de precios entre las solicitudes de rehidratación de prioridad estándar y de alta prioridad, consulte Precios de Azure Blob Storage.

Copia de un blob archivado en un nivel en línea

Para rehidratar un blob archivado copiándolo, utiliza la operación Copiar Blob para crear un nuevo blob de destino en el nivel caliente, esporádico o frío. El blob fuente permanece sin modificar en el nivel de archivo.

Debe copiar el blob archivado en un nuevo blob con un nombre diferente o en un contenedor diferente. No se puede sobrescribir el blob de origen copiándolo en el mismo blob.

Al copiar un blob desde el nivel de archivo a un nivel en línea se evita la cuota de eliminación anticipada que se aplica si se cambia el nivel de un blob del nivel de archivo antes de que transcurra el período requerido de 180 días. Para más información, consulte Nivel de acceso de archivo.

Evitar la rearchivación de políticas de ciclo de vida

La copia también puede evitar que una política de gestión del ciclo de vida mueva un blob rehidratado de vuelta al nivel de archivo. Este riesgo existe cuando la acción de la directiva tierToArchive no incluye la condición daysAfterLastTierChangeGreaterThan y la hora de la última modificación del blob supera el umbral de la directiva. Una operación de copia deja el blob fuente en el archivo y crea un nuevo blob con un nombre diferente y un nuevo tiempo de última modificación.

Finalización de la copia del monitor

Copiar un blob del nivel de archivo puede llevar horas, dependiendo de la prioridad de rehidratación seleccionada. La operación de copia lee el blob de código fuente archivado y crea un nuevo blob en el nivel online seleccionado. El nuevo blob puede aparecer en el contenedor principal antes de que se complete la rehidratación, pero su nivel permanece en el archivo. Sus datos se vuelven disponibles después de que el servicio lea el blob fuente y escriba su contenido en el blob de destino. El nuevo blob es una copia independiente, así que modificarlo o eliminarlo no afecta al blob de origen archivado.

Para obtener información sobre cómo rehidratar un blob copiándolo en un nivel en línea, consulte Rehidratación de un blob con una operación de copia.

Importante

No elimines el blob de origen hasta que la rehidratación se haya completado correctamente. Si eliminas el blob de origen, el blob de destino puede que no termine de copiarse. Monitoriza el evento de finalización para determinar cuándo puedes eliminar el blob fuente de forma segura. Para más información, consulta Administrar un evento de rehidratación de blobs.

Copia entre cuentas de almacenamiento

La versión del servicio 2021-02-12 y versiones posteriores admiten la rehidratación mediante la copia de un blob archivado en una cuenta de almacenamiento diferente de la misma región. Las versiones anteriores del servicio solo admiten la rehidratación dentro de la misma cuenta de almacenamiento. La rehidratación entre cuentas de almacenamiento te permite separar tus datos de producción de los datos de copia de seguridad manteniéndolos en cuentas separadas. Aislar los datos archivados en una cuenta separada también puede ayudar a mitigar los costes derivados de una rehidratación no intencionada.

El blob objetivo para la operación de copia debe estar en un nivel online (caliente, frío o frío). No se puede copiar un blob archivado en un blob de destino que también está en el nivel de archivo.

En la tabla siguiente se muestra el comportamiento de una operación de copia de blob, en función de los niveles del blob de origen y de destino.

Origen de nivel de acceso frecuente Origen de nivel de acceso esporádico Fuente de nivel frío Origen de nivel de archivo
Destino de nivel de acceso frecuente Compatible Compatible Compatible Se admite entre cuentas de la misma región con la versión 2021-02-12 y posteriores. Solo se admite en la misma cuenta de almacenamiento para versiones anteriores. Requiere la rehidratación de blobs.
Destino de nivel de acceso esporádico Compatible Compatible Compatible Se admite entre cuentas de la misma región con la versión 2021-02-12 y posteriores. Solo se admite en la misma cuenta de almacenamiento para versiones anteriores. Requiere la rehidratación de blobs.
Destino de nivel frío Compatible Compatible Compatible Se admite entre cuentas de la misma región con la versión 2021-02-12 y posteriores. Solo se admite en la misma cuenta de almacenamiento para versiones anteriores. Requiere la rehidratación de blobs.
Destino de nivel de archivo Compatible Compatible Compatible No compatible

Rehidratación desde una región secundaria

Si tu cuenta de almacenamiento utiliza almacenamiento geo-redundante de acceso de lectura (RA-GRS), utiliza la operación Copiar Blob para rehidratar blobs de la región secundaria a otra cuenta de esa región. Consulte Rehidratación desde una región secundaria.

Para más información sobre cómo obtener acceso de lectura a las regiones secundarias, consulte Acceso de lectura a los datos de la región secundaria.

Cambio del nivel de acceso de un blob a un nivel en línea

La segunda opción para rehidratar un blob del nivel de archivo a un nivel en línea es cambiar el nivel del blob mediante una llamada a Set Blob Tier. Con esta operación, puedes cambiar el nivel del blob archivado a caliente, frío o frío.

No puedes cancelar una solicitud de Set Blob Tier después de que empiece. Durante la rehidratación, el nivel de acceso del blob permanece en archivo. Cuando finalice la rehidratación, la propiedad del nivel de acceso muestra el nuevo nivel.

Para obtener información sobre cómo rehidratar un blob cambiando su nivel a un nivel en línea, consulte Rehidratación de un blob cambiando su nivel.

Precaución

Cambiar el nivel de un blob no afecta a la hora de la última modificación. Si la cuenta de almacenamiento tiene una política de gestión del ciclo de vida , la política podría mover el blob de vuelta al nivel de archivo tras la rehidratación cuando el último tiempo modificado supere el umbral de la política.

Para evitar este escenario, agregue la condición daysAfterLastTierChangeGreaterThan a la acción tierToArchive de la directiva. También puede, en su lugar, rehidratar el blob archivado copiándolo, tal como se describe en la sección Copia de un blob archivado en un nivel en línea. Realizar una operación de copia crea una nueva instancia del blob con un tiempo actualizado de última modificación, por lo que no activa la política de gestión del ciclo de vida.

Comprobación del estado de la operación de rehidratación del blob

Durante la operación de rehidratación del blob, puede llamar a la operación Get Blob Properties para comprobar su estado. Para obtener información sobre cómo comprobar el estado de una operación de rehidratación, consulte Comprobación del estado de una operación de rehidratación.

Gestionar un evento de rehidratación de blob

Rehidratar un blob archivado puede llevar hasta 15 horas, y sondear repetidamente Get Blob Properties es ineficiente. Utiliza Azure Event Grid para capturar el evento de finalización y así mejorar el rendimiento y reducir los costes.

Azure Event Grid genera el evento Microsoft.Storage.BlobTierChanged cuando se completa la rehidratación de blobs:

  • El Microsoft.Storage.BlobTierChanged evento se activa cuando cambia el nivel de un blob. Para la rehidratación de blobs, el evento se activa cuando el blob de destino cambia con éxito del nivel de archivo a un nivel online (caliente, frío o frío).

Al usar la operación Copiar blob para copiar un blob desde el nivel de archivo a un nuevo blob de destino en un nivel en línea (nivel frecuente, esporádico o poco frecuente) para la rehidratación:

  1. Azure Event Grid activa un Microsoft.Storage.BlobCreated evento cuando comienza la operación de copia. El nivel del blob es Archivo.

  2. Después de copiar y rehidratar el blob, Azure Event Grid lanza un Microsoft.Storage.BlobTierChanged evento que indica el cambio de Archive al nivel online especificado.

Para obtener información sobre cómo capturar un evento de rehidratación y enviarlo a un controlador de eventos de Azure Function, consulte Ejecución de una función de Azure en respuesta a un evento de rehidratación de blobs.

Para más información sobre cómo gestionar eventos en Blob Storage, véase Reacting to Azure Blob storage events y Azure Blob Storage as Event Grid source.

Precios y facturación

Para Set Blob Tier, Azure Storage cobra por transacciones de lectura de datos y por la cantidad de datos recuperados. La rehidratación de alta prioridad cuesta más que la prioridad estándar y aparece como una partida separada en tu factura. Si una solicitud de alta prioridad para un blob archivado menor a 10 GB tarda más de cinco horas, Azure Storage no cobra la tasa de recuperación de alta prioridad. Las tarifas estándar de recuperación siguen aplicándose. Para obtener una estimación de costos de ejemplo, consulte Estimación de costos: Traslado de datos fuera del almacenamiento de archivo.

Para Copy Blob, Azure Storage cobra por las transacciones de lectura de datos, la cantidad de datos recuperados y las transacciones de escritura de datos para el blob de destino. Las tasas de eliminación anticipada no se aplican porque el blob fuente permanece sin modificar en el nivel de archivo. Se aplican cargos de recuperación de alta prioridad si se selecciona. Para obtener una estimación de ejemplo, consulte Estimación de costos: Recuperación de datos del almacenamiento de archivo para su análisis.

Los blobs de nivel de archivo deben estar almacenados durante un mínimo de 180 días. La eliminación o el cambio del nivel de un blob archivado antes de que transcurra el período de 180 días conlleva una cuota de eliminación anticipada. Por ejemplo, si un blob se mueve al nivel de archivo y luego se elimina o se traslada al tier caliente tras 45 días, incurres en una tasa de eliminación anticipada equivalente a 135 (180 menos 45) días de almacenamiento de ese blob en el tier de archivo. Para más información, consulte Nivel de acceso de archivo.

Para obtener más información sobre los precios de los blobs en bloques y la rehidratación de datos, consulta Precios de Azure Storage. Para más información sobre los cargos de transferencia de datos salientes, consulte detalles de precios de transferencia de datos.

Consulte también

  • Last updated on