Control de versiones de blobs

Puedes activar el control de versiones de blobs para mantener automáticamente versiones anteriores de un objeto. Cuando activas la versión de blob, puedes acceder a versiones anteriores de un blob para recuperar tus datos si se modifica o elimina.

Configuración de protección de datos recomendada

El control de versiones de blobs es una de varias funciones de protección de datos. La elección de la característica adecuada o de una combinación de características depende de su carga de trabajo y de aquello contra lo que desea protegerse. Para saber más sobre las recomendaciones de Microsoft para la protección de datos, consulte Resumen de Protección de Datos.

Versiones frente a instantáneas

Una versión de blob es similar a una instantánea, pero ambas difieren en cómo se crean y para qué son más adecuadas. El control de versiones es automático y está administrado por el sistema: Azure Storage crea una nueva versión en cada escritura o eliminación cuando el control de versiones de blobs está habilitado, sin necesidad de lógica de aplicación. Una instantánea es manual y está controlada por la aplicación: creas explícitamente una copia en un momento dado cuando tu aplicación decide que es necesaria.

Utiliza el versionado cuando quieras protección automática y continua contra sobrescribencias y eliminaciones accidentales o maliciosas. Utiliza instantáneas cuando quieras copias deliberadas y en un momento concreto, como un punto de control conocido antes de una actualización planificada. Microsoft recomienda que dejes de hacer instantáneas de los blobs de bloque una vez que el versionado esté activado.

Funcionamiento del control de versiones de blobs

Una versión captura el estado de un blob en un momento dado. Cada versión tiene un ID de versión. Cuando activas el control de versiones de blobs para una cuenta de almacenamiento, Azure Storage crea automáticamente una nueva versión con un ID único cuando creas un blob y cada vez que lo modificas.

Un identificador de versión puede identificar la versión actual u otra anterior. Un blob solo puede tener una versión actual a la vez: ese es su estado actual. Un blob puede tener varias versiones anteriores.

Cuando se crea un blob, existe una única versión, que es la versión actual. Al modificar un blob existente, la versión actual se convierte en otra anterior. Se crea una versión para capturar el estado actualizado y esa nueva versión pasa a ser la actual. Cuando elimina un blob, la versión actual se convierte en otra anterior y deja de haber una versión actual. Las versiones anteriores del blob se conservan.

El siguiente diagrama muestra cómo se crean las versiones en las operaciones de escritura y cómo una versión anterior podría promocionarse a la versión actual:

Las versiones anteriores de los blobs son inmutables, es decir, no puedes modificar el contenido ni los metadatos.

Id. de la versión

Cada versión de blob tiene un ID de versión único. El valor del ID de la versión es la marca de tiempo en la que se actualizó el blob. Asignas el ID de la versión cuando creas la versión.

Puedes leer o eliminar una versión específica de un blob usando su ID de versión. Si no incluyes el ID de la versión, la operación apunta a la versión actual.

Cuando realizas una operación de escritura para crear o modificar un blob, Azure Storage devuelve la cabecera x-ms-version-id en la respuesta. Este encabezado contiene el ID de versión de la versión actual del blob que la operación de escritura creó.

El ID de la versión permanece igual durante toda la vida útil de la versión.

Control de versiones en operaciones de escritura

Cuando activas la versión de blob, cada operación de escritura en un blob crea una nueva versión. Las operaciones de escritura incluyen Put Blob, Put Block List, Copy Blob y Set Blob Metadata.

Si la operación de escritura crea un nuevo blob, el blob resultante es la versión actual del blob. Si la operación de escritura modifica un blob existente, la versión actual se convierte en una versión anterior, y una nueva versión actual captura el blob actualizado.

En el diagrama siguiente se muestra cómo las operaciones de escritura afectan a las versiones de los blobs. Para simplificar, los diagramas de este artículo muestran el ID de la versión como un valor entero simple. En realidad, el identificador de la versión es una marca de tiempo. La versión actual se muestra en azul y las anteriores, en gris.

Al habilitar el control de versiones de blobs para una cuenta de almacenamiento, todas las operaciones de escritura en blobs de bloque desencadenan la creación de una nueva versión, excepto la operación Put Block.

En el caso de los blobs en página y blobs anexos, solo un subconjunto de operaciones de escritura desencadena la creación de una versión. Entre las operaciones se incluyen:

• Put Blob
• Colocar Lista de Bloques
• Establecer metadatos de Blob
• Copia de blob

Las siguientes operaciones no activan la creación de una nueva versión:

• Put Page (blob en páginas)
• Append Block (blob en anexos)

Para capturar los cambios de esas operaciones, toma una instantánea manual. Para más información, véase Instantáneas de blobs.

Todas las versiones de un blob deben ser del mismo tipo de blob. Si un blob tiene versiones anteriores, no puede sobrescribir un blob de un tipo con uno de otro tipo, a menos que primero elimine el blob y todas sus versiones.

Control de versiones en operaciones de eliminación

Cuando realizas la operación de Eliminar Blob sin especificar un ID de versión, la versión actual se convierte en una versión anterior y ya no hay una versión actual. La operación conserva todas las versiones anteriores existentes del blob.

En el diagrama siguiente se muestra el efecto de una operación de eliminación en un blob con versiones:

Para eliminar una versión específica de un blob, proporcione el identificador de la versión en la operación de eliminación. Si además se habilita la eliminación temporal de blobs para la cuenta de almacenamiento, el sistema conserva la versión hasta que transcurra el período de retención de la eliminación temporal.

Al escribir nuevos datos en el blob, se crea una versión actual de este. Esta acción no afecta a ninguna versión existente, como se muestra en el siguiente diagrama.

Niveles de acceso

Puede trasladar cualquier versión de un blob en bloques, incluida la actual, a otro nivel de acceso de blobs mediante una llamada a la operación Set Blob Tier. Al trasladar las versiones más antiguas de un blob al nivel cool o archive, puedes beneficiarte de tarifas de capacidad más bajas. Para más información, consulte Niveles de acceso frecuente, esporádico, esporádico y de archivo para los datos de blobs.

Para automatizar el proceso de mover blobs en bloques al nivel correspondiente, crea una política de Lifecycle Management, crea una tarea de Storage Actions o activa Smart Tier.

Habilitación o deshabilitación del control de versiones de blobs

Para obtener instrucciones sobre cómo habilitar o deshabilitar las versiones de blobs, consulte Habilitar y administrar las versiones de blobs.

Al deshabilitar el control de versiones de blobs, no se eliminan los blobs, las versiones ni las instantáneas existentes. Cuando desactivas el control de versiones de blobs, no puedes crear nuevas versiones.

Después de desactivar el control de versiones, modificar la versión actual crea un blob que no es una versión. Todas las actualizaciones posteriores del blob sobrescribirán sus datos sin guardar el estado anterior. Todas las versiones existentes se conservan como versiones anteriores.

Puedes leer o eliminar versiones usando el ID de versión después de desactivar el versionado. Así mismo, después de deshabilitarlo, también puede enumerar las versiones de un blob.

La replicación de objetos se basa en el control de versiones de blobs. Para poder deshabilitar el control de versiones de blobs, debe eliminar las directivas de replicación de objetos de la cuenta. Para obtener más información sobre la replicación de objetos, vea Replicación de objetos para blobs en bloques.

En el diagrama siguiente se muestra cómo se crea un blob sin versiones cuando se modifica un blob después de deshabilitar el control de versiones. Las versiones existentes asociadas con el blob se conservan.

Compatibilidad de características

La compatibilidad con esta característica puede verse afectada al habilitar Data Lake Storage Gen2, el protocolo Network File System (NFS) 3.0 o el protocolo SSH File Transfer Protocol (SFTP). Si ha habilitado alguna de estas funcionalidades, consulte Compatibilidad de características en cuentas de Azure Storage con Blob Storage para evaluar la compatibilidad de esta funcionalidad.

El control de versiones de blobs está disponible para cuentas estándar de uso general V2, cuentas premium de blob en bloques y cuentas heredadas de almacenamiento de blobs. Actualmente no se admiten cuentas de almacenamiento con un espacio de nombres jerárquico habilitado para su uso con Azure Data Lake Storage.

La versión 2019-10-10 y posteriores de la API REST de Azure Storage admite el control de versiones de blobs.

El control de versiones no es compatible con los blobs que se cargan mediante las API de Data Lake Storage.

Autorización de operaciones en versiones de blobs

Puedes autorizar el acceso a versiones blob utilizando uno de los siguientes métodos:

• Utiliza el control de acceso basado en roles de Azure (Azure RBAC) para conceder permisos a un principal de seguridad de Microsoft Entra. Microsoft recomienda usar Microsoft Entra ID para mayor seguridad y facilidad de uso. Para obtener más información sobre el uso de Microsoft Entra ID con operaciones de blobs, consulte Autorizar el acceso a los datos en Azure Storage.
• Utiliza una firma de acceso compartido (SAS) para delegar el acceso a las versiones de blob. Especifique el identificador de versión para el tipo de recurso firmado bv, que representa una versión de blob, para crear un token SAS para operaciones sobre una versión específica. Para obtener más información sobre las firmas de acceso compartido, consulte Conceder acceso limitado a los recursos de Azure Storage usando firmas de acceso compartido (SAS).
• Utilice las claves de acceso de la cuenta para autorizar operaciones sobre las versiones de los blobs mediante la clave compartida. Para más información, consulte el artículo sobre la Autorización con clave compartida.

El control de versiones de blobs está diseñado para proteger los datos de la eliminación accidental o malintencionada. A fin de mejorar la protección, la eliminación de una versión de blob requiere permisos especiales. En las secciones siguientes se describen los permisos necesarios para eliminar una versión de un blob.

Acción de Azure RBAC para eliminar una versión de un blob

En la tabla siguiente se muestran las acciones de Azure RBAC que admiten la eliminación de un blob o una versión de blob.

Parámetros de la Firma de acceso compartido (SAS)

El recurso firmado de una versión de blob es bv. Para obtener más información, vea Creación de un SAS de servicio o Creación de un SAS de delegación de usuario.

En la tabla siguiente se muestra el permiso necesario en un SAS para eliminar una versión de un blob.

Consideraciones sobre la carga de trabajo existente

• Eliminar un blob ya no libera espacio. Cuando activas el versionado, eliminar un blob no elimina sus datos. La versión actual se convierte en una versión anterior que persiste y sigue generando cargos. Las cargas de trabajo que dependen de operaciones de eliminación para liberar espacio de almacenamiento siguen generando cargos hasta que eliminas explícitamente esas versiones.

• Las cargas de trabajo con mucha sobreescritura pueden acumular versiones. Las versiones persisten hasta que las eliminas explícitamente. Esta persistencia puede llevar a la acumulación de versiones si no las gestionas correctamente. Para reducir costes, haga cambios a nivel de bloque para que se cobren a nivel de bloque en todas las versiones, minimizando los costes por versión.

Interacciones entre características

Eliminación suave

Tanto el control de versiones de blobs como la eliminación temporal de blobs forman parte de la configuración de protección de datos recomendable para las cuentas de almacenamiento. Para obtener más información sobre las recomendaciones de Microsoft para la protección de datos, consulte Introducción a la protección de datos.

Sobrescritura de un blob

Si habilita tanto el control de versiones de blobs como la eliminación temporal de blobs para una cuenta de almacenamiento, al sobrescribir un blob se crea automáticamente una nueva versión anterior que refleja el estado del blob antes de la operación de escritura. La nueva versión no se elimina temporalmente y persiste hasta que se elimine explícitamente. No se crea ninguna instantánea eliminada temporalmente.

Eliminación de un blob o una versión

Si activas tanto el control de versiones como la eliminación suave en una cuenta de almacenamiento, cuando eliminas un blob, la versión actual del blob se convierte en una versión anterior. La operación no crea una nueva versión ni ninguna instantánea eliminada temporalmente. El periodo de retención de eliminación suave no se aplica al blob eliminado.

El borrado suave ofrece protección extra al eliminar versiones de blobs. Al eliminar una versión anterior del blob, la operación elimina temporalmente dicha versión. La versión eliminada temporalmente se conserva hasta que transcurre el período de retención de eliminación temporal, momento en el que se elimina de forma permanente.

Para eliminar una versión anterior de un blob, llame a la operación Delete Blob y especifique el identificador de la versión.

Restauración de una versión eliminada temporalmente

Utiliza la operación Undelete Blob para restaurar versiones con borrado suave durante el periodo de retención de eliminación suave. La operación Undelete Blob siempre restaura todas las versiones eliminadas temporalmente del blob. No es posible restaurar únicamente una versión eliminada de forma temporal.

Restaurar versiones eliminadas suavemente usando la operación Borrar Blob no promueve que ninguna versión sea la actual. Para restaurar la versión actual, primero restaure todas las versiones eliminadas temporalmente y, después, use la operación Copy Blob para copiar una versión anterior en otra actual de reciente creación.

Tras el periodo de retención de eliminación suave, el sistema elimina permanentemente cualquier versión de blob con eliminación suave.

Instantáneas de blobs

Una instantánea de blob es una copia de solo lectura de un blob tomada en un momento específico. Las instantáneas de blobs y las versiones de blobs son similares, pero tú o tu aplicación creáis manualmente una instantánea, mientras que una versión de blob se crea automáticamente al realizar una operación de escritura o eliminación cuando habilitas el control de versiones de blobs para tu cuenta de almacenamiento.

Instantánea de un blob cuando el control de versiones está habilitado

Aunque no se recomienda, puedes crear una instantánea de un blob que también tenga control de versiones. Si no puede actualizar la aplicación para que deje de tomar instantáneas de blobs al habilitar el control de versiones, es posible que la aplicación admita tanto instantáneas como versiones.

Cuando tomas una instantánea de un blob versionado, creas una nueva versión al mismo tiempo que se crea la instantánea. También creas una nueva versión actual cuando haces una instantánea.

En el diagrama siguiente se muestra lo que ocurre cuando toma una instantánea de un blob con versiones. En el diagrama, las versiones del blob y las instantáneas con el identificador de versión 2 y 3 contienen datos idénticos.

Limitaciones conocidas

• No se admite en cuentas de espacios de nombres jerárquicos (Azure Data Lake Storage), ni para blobs subidos mediante APIs de Data Lake Storage.

• No protege contra la eliminación del contenedor o de la cuenta. El versionado solo funciona a nivel de blob. Eliminar un contenedor elimina todos los blobs y sus versiones. Para recuperar datos tras esa eliminación, es necesario utilizar la eliminación temporal del contenedor. Proteger contra la eliminación de cuentas requiere un bloqueo de recurso.

• Las versiones son inmutables. No puedes cambiar el contenido ni los metadatos de una versión existente.

• Todas las versiones de un blob deben ser del mismo tipo de blob. No puedes sobrescribir un blob con otro tipo de blob mientras tenga versiones anteriores a menos que primero elimines el blob y todas sus versiones.

• No todas las operaciones de escritura crean una versión. Consulta la información anterior en este artículo que detalla las excepciones. Para capturar esos estados, utiliza una instantánea manual.

• No se puede desactivar el versionado mientras existan políticas de replicación de objetos en la cuenta. Debes eliminar primero todas las políticas de replicación de objetos.

• Undelete Blob restaura todas las versiones eliminadas de forma temporal de un blob, no solo una. No es posible recuperar selectivamente una sola versión. La recuperación nunca convierte una versión en la actual.

• Techo recomendado de 1.000 versiones por blob. Superarlo degrada el rendimiento de las listas de blobs.

Precios y facturación

Cuando activas la versión de blob, podrías incurrir en cargos adicionales de almacenamiento de datos. Cuando diseñes tu aplicación, considera cómo podrían sumarse estos cargos para mantener los costes bajos.

Se te factura por las versiones blob, como las instantáneas blob, al mismo ritmo que los datos activos. La forma en que se facturan las versiones depende de si se establece explícitamente el nivel de las versiones actuales o anteriores de un blob (o de las instantáneas). Para más información sobre los niveles de blob, consulte Niveles de acceso frecuente, esporádico, esporádico y de archivo para los datos de blobs.

Si no cambia el nivel de un blob o de una versión, se le facturarán los bloques únicos de datos de ese blob, sus versiones y cualquier instantánea que pueda tener. Para obtener más información, consulte Facturación cuando el nivel del blob no está establecido explícitamente.

Si cambias el nivel de un blob o una versión, te facturan por todo el objeto, independientemente de si el blob y la versión acaban en el mismo nivel otra vez. Para obtener más información, consulta Facturación cuando se establece explícitamente el nivel de blob.

Para más información sobre los detalles de facturación de las instantáneas de blobs, consulte Instantáneas de blob.

En el caso de las cuentas de almacenamiento que utilizan el nivel inteligente, se paga por las versiones y las instantáneas según la longitud total del contenido. Para obtener más información, consulte Optimizar costos con el nivel inteligente.

Facturación cuando no se establece explícitamente el nivel de blob

Si no establece explícitamente el nivel de un blob para ninguna de sus versiones, se le facturarán los bloques o páginas únicos de todas las versiones, así como cualquier instantánea que pueda tener. Se te factura por los datos que se comparten entre versiones de blob solo una vez. Cuando actualizas un blob, los datos de la nueva versión actual divergen de los datos almacenados en versiones anteriores, por lo que se te factura por los datos únicos por bloque o página.

Cuando sustituyes un bloque dentro de un blob de bloques, se te factura ese bloque como un bloque único. Esta regla se aplica incluso si el bloque tiene el mismo ID de bloque y los mismos datos que en la versión anterior. Después de volver a hacer commit del bloque, se desvía de su contraparte en la versión anterior y se te factura por sus datos. La misma regla se aplica a una página en un blob de páginas que se actualiza con datos idénticos.

El almacenamiento de blobs no tiene forma de determinar si dos bloques contienen datos idénticos. Cada bloque que subes y confirmas se considera único, aunque tenga los mismos datos y el mismo ID de bloque. Como te cobran por bloques únicos, ten en cuenta que actualizar un blob cuando se habilita el versionado resulta en bloques únicos extra y cargos adicionales.

Cuando habilite el control de versiones de blobs, realice operaciones de actualización en los blobs de bloque de forma que actualicen el menor número posible de bloques. Las operaciones de escritura que permiten un control más exhaustivo de los bloques son Put Block y Put Block List. Put Block prepara los cambios, pero la modificación real y la creación de la versión ocurren en la operación Put Block List. La operación Put Blob , en cambio, reemplaza todo el contenido de un blob y por tanto podría generar cargos adicionales.

Los siguientes escenarios muestran cómo se acumulan los cargos por un blob de bloque y sus versiones cuando no se establece explícitamente el nivel de blob.

Escenario 1

En el escenario 1, el blob tiene una versión anterior. El blob no se actualiza desde que se creó la versión, así que solo incurres en cargas por los bloques únicos 1, 2 y 3.

Escenario 2

En el escenario 2, se actualiza un bloque (bloque 3 en el diagrama) del blob. Aunque el bloque actualizado contiene los mismos datos y el mismo identificador, no es igual que el bloque 3 de la versión anterior. Como resultado, se aplicarán cargos a la cuenta por cuatro bloques.

Escenario 3

En el escenario 3, el blob se actualiza, pero la versión no. El bloque 3 se reemplaza por el bloque 4 en el blob actual, pero la versión anterior sigue reflejando el bloque 3. Como resultado, se aplicarán cargos a la cuenta por cuatro bloques.

Escenario 4

En el escenario 4, la versión actual está completamente actualizada y no contiene ninguno de sus bloques originales. Como resultado, a la cuenta se le cobra por los ocho bloques únicos: cuatro en la versión actual y cuatro combinados en las dos versiones anteriores. Este escenario puede ocurrir si escribes en un blob usando la operación Put Blob , porque reemplaza todo el contenido del blob.

Facturación cuando estableces explícitamente el nivel de blob

Si configuras explícitamente el nivel de blob para un blob, versión o instantánea, pagas por la longitud total del contenido del objeto en el nuevo nivel, independientemente de si comparte bloques con un objeto del nivel original. También pagas por la duración completa del contenido de la versión más antigua del nivel original. Por cualquier otra versión anterior o instantánea que permanezca en el nivel original, se paga por los bloques únicos que comparten, tal y como se describe en Facturación cuando el nivel de blob no está establecido explícitamente.

Traslado de un blob a un nuevo nivel

La siguiente tabla describe el comportamiento de facturación de un blob o versión cuando lo trasladas a un nuevo nivel.

¹Si hay otras versiones anteriores o instantáneas que no hayas movido de su nivel original, esas versiones o instantáneas se cobran en función del número de bloques únicos que contienen, como se describe en Facturación cuando el nivel del blob no se establece explícitamente.

El siguiente diagrama ilustra cómo se facturan los objetos cuando se mueve un blob versionado a otro nivel.

No se puede deshacer el establecimiento explícito del nivel para un blob, una versión o una instantánea. Si mueves un blob a un nuevo nivel y luego lo vuelves a su nivel original, pagas por toda la longitud del contenido del objeto aunque comparta bloques con otros objetos del nivel original.

Las operaciones que establecen explícitamente el nivel de un blob, una versión o una instantánea incluyen:

• Establecer nivel de Blob
• Put Blob con el nivel especificado
• Put Block List con el nivel especificado
• Copy Blob con el nivel especificado

Eliminación de un blob cuando está habilitada la eliminación temporal

Cuando habilitas la eliminación temporal de blobs, pagas por todas las entidades eliminadas temporalmente al mismo precio que los datos activos. Si eliminas o sobrescribes una versión actual para la que hayas establecido explícitamente el nivel de almacenamiento, pagarás por cualquier versión anterior del blob eliminado de forma temporal por su longitud total de contenido. Para más información sobre cómo funcionan conjuntamente el versionado de blob y la eliminación suave, véase Interacciones de características.

Supervisión y solución de problemas

• Mi política de LCM no elimina versiones cuando espero: La antigüedad de una versión se basa en cuándo escribiste originalmente sus datos, no en cuándo se convirtió en una versión anterior. El plazo comienza en el momento de la creación del blob, no en el momento de la sobrescritura que lo incorporó al historial de versiones. Como resultado, un blob que se mantuvo vigente durante mucho tiempo antes de ser sobrescrito puede producir una versión anterior que ya supera tu daysAfterCreationGreaterThan umbral en el momento en que se crea, provocando que se elimine casi de inmediato. Por el contrario, las versiones de blobs creados recientemente pueden persistir más de lo esperado. Para confirmarlo, comprueba la marca de tiempo real de creación en las versiones en lugar de asumir que coincide con el tiempo de sobrescritura. Si necesitas basar la retención en cuándo una versión dejó de ser la versión actual o quieres un control más detallado que el que permiten los umbrales diarios de la gestión del ciclo de vida, considera usar Azure Storage Actions en su lugar. Para más información, consulte Acciones de almacenamiento.

• Mi factura sigue siendo alta después de desactivar las versiones: Las versiones existentes permanecen hasta que las eliminas manualmente.

• No puedo desactivar el versionado. La replicación de objetos podría configurarse en la cuenta. Elimina primero todas las políticas de replicación de objetos y luego desactiva el versionado. Por otra parte, puede existir una directiva de inmutabilidad (WORM) en un contenedor o en la cuenta en la que no se pueda desactivar el control de versiones.

Consulte también

• Habilitar y administrar las versiones de blob
• Creación de una instantánea de un blob
• Eliminación temporal para blobs
• Eliminación temporal de contenedores