Rehidratación de blobs desde el nivel de archivo
Mientras un blob se encuentra en el nivel de acceso de archivo, se considera que está sin conexión y no se puede leer ni modificar. Para leer o modificar los datos de un blob archivado, primero debe rehidratar el blob en un nivel en línea, ya sea el nivel de acceso frecuente o esporádico. Hay dos opciones para rehidratar un blob que se almacena en el nivel de archivo:
Copiar un blob archivado en un nivel en línea: puede rehidratar un blob archivado si lo copia en un nuevo blob en el nivel de acceso frecuente o esporádico con la operación Copiar blob. Microsoft recomienda esta opción para la mayoría de los escenarios.
Cambio del nivel de acceso de un blob archivado a un nivel en línea: puede rehidratar un blob archivado a acceso frecuente o esporádico cambiando su nivel mediante la operación Establecer el nivel del blob.
La rehidratación de un blob de un nivel de acceso de archivo puede tardar varias horas en completarse. Microsoft recomienda archivar blobs más grandes para obtener un rendimiento óptimo al rehidratarlos. 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 pueden rehidratar hasta 10 GiB por cuenta de almacenamiento por hora con la recuperación en orden de prioridad.
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
Al rehidratar un blob, puede establecer la prioridad de la operación de rehidratación mediante el encabezado opcional x-ms-rehydrate-priority en una operación Establecer el nivel del blob o Copiar blob. Las opciones de prioridad de rehidratación incluyen:
- Prioridad estándar: la solicitud de rehidratación se procesará 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 tendrá 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 la operación en curso, llame a Get 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 también cuesta más que una rehidratación de prioridad estándar. Una rehidratación de alta prioridad puede tardar más de una hora, según el tamaño de blob y la demanda actual. Microsoft recomienda reservar la rehidratación de alta prioridad para su uso en situaciones de restauración de datos de emergencia.
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.
La configuración de prioridad de rehidratación no se puede reducir de Alta a Estándar para una operación pendiente. Tenga en cuenta que la actualización de la configuración de prioridad de rehidratación puede tener un impacto en 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
La primera opción para mover un blob del nivel de archivo a un nivel en línea es copiar el blob archivado a un nuevo blob de destino que se encuentre en el nivel de acceso frecuente o esporádico. Puede usar la operación Copiar blob para copiar el blob. Al copiar un blob archivado en un nuevo blob en un nivel en línea, el blob de origen 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.
Microsoft recomienda realizar una operación de copia en la mayoría de los escenarios en los que es necesario mover un blob del nivel de archivo a un nivel en línea, por los siguientes motivos:
Una operación de copia evita la cuota de eliminación anticipada que se aplica si 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.
Si hay una directiva de administración del ciclo de vida en vigor para la cuenta de almacenamiento, la rehidratación de un blob con la operación Set Blob Tier puede dar lugar a un escenario en el que la directiva de ciclo de vida mueva el blob de nuevo al nivel de archivo después de la rehidratación, ya que la hora de la última modificación supera el umbral establecido para la directiva. Una operación de copia deja el blob de origen en el nivel de archivo y crea un nuevo blob con un nombre diferente y una nueva hora de última modificación, por lo que no hay ningún riesgo de que la directiva de ciclo de vida devuelva el blob rehidratado al nivel de archivo.
La copia de un blob desde el nivel de archivo puede tardar horas en completarse, en función de la prioridad de rehidratación seleccionada. En segundo plano, una operación de copia lee el blob de origen de archivo para crear un nuevo blob en línea en el nivel de destino seleccionado. El nuevo blob puede estar visible cuando enumere los blobs del contenedor principal antes de que finalice la operación de rehidratación, pero aparecerá con el nivel de archivo. Los datos no están disponibles hasta que finaliza la operación de lectura del blob de origen en el nivel de archivo y se ha escrito el contenido del blob en el nuevo blob de destino en un nivel en línea. El nuevo blob es una copia independiente, por lo que modificarlo o eliminarlo no afecta al blob de origen en el nivel de archivo.
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 elimine el blob de origen hasta que la rehidratación se complete correctamente. Si se elimina el blob de origen, es posible que el blob de destino no finalice la copia. Puede controlar el evento que se genera cuando se completa la operación de copia para saber cuándo es seguro eliminar el blob de origen. Para obtener más información, consulte Control de un evento en la rehidratación de blobs.
La rehidratación de un blob archivado al copiarlo en un nivel de destino en línea solo se admite en la misma cuenta de almacenamiento para las versiones del servicio anteriores a la 2021-02-12. A partir de la versión del servicio 2021-02-12, puede rehidratar un blob archivado copiándolo en otra cuenta de almacenamiento, siempre y cuando la cuenta de destino esté en la misma región que la cuenta de origen. La rehidratación entre cuentas de almacenamiento permite separar los datos de producción de los datos de copia de seguridad y mantenerlos en cuentas separadas. Aislar los datos archivados en una cuenta aparte también puede ayudar a mitigar los costos de la rehidratación involuntaria.
El blob de destino de la operación de copia debe estar en un nivel en línea (de acceso frecuente o esporádico). 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 | Origen de nivel de archivo | |
|---|---|---|---|
| Destino de nivel de acceso frecuente | 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 | 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 | Admitido | No compatible |
Rehidratación desde una región secundaria
Si ha configurado la cuenta de almacenamiento para usar el almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS), puede usar la operación Copy Blob para rehidratar los blobs de la región secundaria en otra cuenta de almacenamiento que se encuentre en la misma región secundaria. 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, puede cambiar el nivel del blob archivado a nivel de acceso frecuente o esporádico.
Una vez que se inicia una solicitud Set Blob Tier, no se puede cancelar. Durante la operación de rehidratación, la configuración del nivel de acceso del blob continúa a modo de archivado hasta que se completa el proceso de rehidratación. Una vez completada la operación de rehidratación, la propiedad del nivel de acceso del blob se actualiza para reflejar 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 hay una directiva de administración del ciclo de vida en vigor para la cuenta de almacenamiento, la rehidratación de un blob con la operación Set Blob Tier puede dar lugar a un escenario en el que la directiva de ciclo de vida mueva el blob de nuevo al nivel de archivo después de la rehidratación, ya que la hora de la última modificación supera el umbral establecido para la directiva.
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. La realización de una operación de copia crea una nueva instancia del blob con una hora de la última modificación actualizada, por lo que no desencadena la directiva de administració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.
Control de un evento en la rehidratación de blobs
La rehidratación de un blob archivado puede tardar hasta 15 horas y sondear repetidamente Get Blob Properties para determinar si la rehidratación se ha completado no sirve de nada. Microsoft recomienda el uso de Azure Event Grid para capturar el evento que se desencadena cuando la rehidratación finaliza a fin de obtener mayor rendimiento y optimización de costos.
Azure Event Grid genera el evento Microsoft.Storage.BlobTierChanged al finalizar la rehidratación de blobs:
- El evento Microsoft.Storage.BlobTierChanged se desencadena cuando se cambia el nivel de un blob. En el contexto de la rehidratación de blobs, este evento se desencadena cuando el nivel de acceso de un blob de destino se cambia correctamente de nivel de archivo a nivel en línea (nivel de acceso frecuente, esporádico o frío). Puede usar la operación Establecer nivel de blob para cambiar el nivel de acceso de un blob archivado o usar la operación Copiar blob para copiar un blob archivado en un nuevo blob de destino en un nivel en línea.
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 obtener más información sobre el control de eventos en Blob Storage, consulte Reacción ante eventos de Blob Storage y Azure Blob Storage como origen de Event Grid.
Precios y facturación
Una operación de rehidratación con Set Blob Tier se factura por las transacciones de lectura de datos y el tamaño de recuperación de datos. Una rehidratación de alta prioridad tiene mayores costos de operación y recuperación de datos que los de la prioridad estándar. La rehidratación de alta prioridad aparece como una partida independiente en la factura. Si una solicitud de prioridad alta para devolver un blob de archivo que pesa menos de 10 gigabytes tarda más de cinco horas, no se le cobrará la tarifa de recuperación de prioridad alta. Sin embargo, se seguirán aplicando las tarifas de recuperación estándar.
La copia de un blob archivado en un nivel en línea con Copiar Blob o se factura por las transacciones de lectura de datos y el tamaño de recuperación de datos. La creación del blob de destino en un nivel en línea se factura por las transacciones de escritura de datos. Las tarifas de eliminación anticipada no se aplican al realizar la copia en un blob en línea porque el blob de origen permanece sin modificar en el nivel de archivo. Si se selecciona, se aplican cargos por recuperación de alta prioridad.
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 acceso de archivo y, después, se elimina o se mueve al nivel de acceso frecuente al cabo de 45 días, se le cobrará una cuota de eliminación temprana equivalente a 135 (180 menos 45) días a partir del almacenamiento de ese blob en el nivel de acceso 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, consulte la página Precios de Azure Storage. Para obtener más información sobre los cargos por la transferencia de datos salientes, consulte la página Detalles de precios de ancho de banda.