Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Puede habilitar el control de versiones de almacenamiento de blobs para conservar automáticamente las 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.
Precaución
Tras habilitar el control de versiones de blobs en una cuenta de almacenamiento, cada operación de escritura dirigida hacia un blob de esa cuenta dará como resultado la creación de una nueva versión. Por esta razón, habilitar la versión de blob podría suponer costes adicionales. Para minimizar los costos, use una directiva de administración del ciclo de vida para eliminar automáticamente las versiones anteriores. Para obtener más información sobre la gestión del ciclo de vida, consulte Optimice los costos automatizando los niveles de acceso al almacenamiento en bloques de Azure.
Funcionamiento del control de versiones de blobs
Una versión captura el estado de un blob en un momento dado. Cada versión se identifica mediante un identificador. Cuando el control de versiones de blobs está habilitado para una cuenta de almacenamiento, Azure Storage crea automáticamente una nueva versión con un identificador único cuando se crea un blob por primera vez y cada vez que se modifica el blob posteriormente.
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.
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.
En el siguiente diagrama se muestra cómo se crean las versiones en operaciones de escritura y cómo se puede promover una versión anterior para que pase a ser la actual:
Importante
Tener un gran número de versiones por cada blob puede aumentar la latencia de las operaciones de enumeración de blobs. Microsoft recomienda mantener menos de 1000 versiones por blob. Puede usar la administración del ciclo de vida para eliminar automáticamente las versiones anteriores. Para obtener más información sobre la gestión del ciclo de vida, consulte Optimice los costos automatizando los niveles de acceso al almacenamiento en bloques de Azure.
Las versiones del blob son inmutables. No puede modificar el contenido ni los metadatos de la versión de un blob existente.
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.
Importante
El versionado por blob no puede ayudarte a recuperarte de la eliminación accidental de una cuenta o contenedor de almacenamiento. Para evitar dicha eliminación, configure un bloqueo en el recurso de la cuenta de almacenamiento. Para obtener más información sobre cómo bloquear una cuenta de almacenamiento, consulte Aplicar un bloqueo de Azure Resource Manager a una cuenta de almacenamiento.
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.
Al llamar a una operación de escritura para crear o modificar un blob, Azure Storage devuelve el encabezado x-ms-version-id en la respuesta. Este encabezado contiene el ID de versión de la versión actual del blob que crea la operación de escritura.
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.
Nota:
Cuando habilita el control de versiones de blobs para una cuenta de almacenamiento, todas las operaciones de escritura en blobs en bloques 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:
Las siguientes operaciones no desencadenan la creación de una nueva versión. Para capturar los cambios de esas operaciones, realice una instantánea manual:
- Put Page (blob en páginas)
- Append Block (blob en anexos)
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 se llama a la operación Delete Blob sin especificar un identificador de versión, la versión actual se convierte en una versión anterior y deja de haber 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 también activas la eliminación suave de blob para la cuenta de almacenamiento, el sistema conserva la versión hasta que termine el periodo de retención de eliminación suave.
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 mover versiones antiguas de un blob al nivel frío o archivo, puedes aprovechar precios de menor capacidad. 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 de bloque al nivel correspondiente, utiliza la gestión del ciclo de vida del blob. Para más información sobre la gestión del ciclo de vida, consulte Gestionar el ciclo de vida del almacenamiento de Blob en Azure.
Habilitación o deshabilitación del control de versiones de blobs
Para obtener información sobre cómo habilitar el control de versiones de blobs, consulte Habilitación y administración del control de versiones de blob (versión preliminar).
Al deshabilitar el control de versiones de blobs, no se eliminan los blobs, las versiones ni las instantáneas existentes. Cuando desactiva el control de versiones de blobs, todas las versiones existentes permanecen accesibles en la cuenta de almacenamiento. No se crean nuevas versiones posteriormente.
Una vez deshabilitado el control de versiones, al modificar la versión actual se 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.
Control de versiones de blobs y eliminación temporal
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 están habilitados el control de versiones y la eliminación temporal de blobs para una cuenta de almacenamiento, al sobrescribir un blob se crea una versión automáticamente. La nueva versión no se elimina de forma temporal ni se quita cuando expira el período de retención de eliminación temporal. No se crea ninguna instantánea eliminada temporalmente.
Eliminación de un blob o una versión
Si activas la versión y la eliminación suave en una cuenta de almacenamiento, al eliminar 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 instantáneas eliminadas temporalmente. El periodo de retención de eliminación suave no se aplica al blob eliminado.
El soft delete proporciona protección adicional al eliminar versiones de blob. Cuando eliminas una versión anterior del blob, esa versión se elimina de forma gradual. La versión con eliminación suave se conserva hasta que termina el periodo de retención de eliminación suave, y entonces se elimina permanentemente.
Para eliminar una versión anterior de un blob, llame a la operación Delete Blob y especifique el identificador de la versión.
En el diagrama siguiente se muestra lo que ocurre cuando elimina un blob o una versión de este.
Restauración de una versión eliminada temporalmente
Puede usar la operación Undelete Blob para restaurar versiones eliminadas temporalmente durante el período de retención de la eliminación. La operación Undelete Blob siempre restaura todas las versiones eliminadas temporalmente del blob. No puedes restaurar solo una versión eliminada de forma suave.
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.
El siguiente diagrama muestra cómo restaurar versiones de blobs eliminadas temporalmente mediante la operación Recuperar blob y cómo restaurar la versión actual del blob mediante la operación Copiar blob.
Tras finalizar el periodo de retención de eliminación suave, cualquier versión de blob con eliminación suave se elimina permanentemente.
Control de versiones e instantáneas de blobs
Una instantánea de blob es una copia de solo lectura de un blob creada en un momento específico. Las instantáneas blob y las versiones blob son similares, pero tú o tu aplicación creáis manualmente una instantánea, mientras que una versión blob se crea automáticamente durante una operación de escritura o eliminación cuando activas la versión blob para tu cuenta de almacenamiento.
Importante
Microsoft recomienda que, después de habilitar el control de versiones de blobs, también actualice la aplicación para que deje de tomar instantáneas de blobs en bloques. Si habilita el control de versiones para su cuenta de almacenamiento, se capturan y conservan todas las actualizaciones y eliminaciones de blobs en bloques mediante versiones. Crear instantáneas no ofrece ninguna protección adicional para los datos de tus blobs en bloques si el control de versiones de blobs está habilitado, y podría aumentar los costes y la complejidad de la aplicación.
Instantánea de un blob cuando el control de versiones está habilitado
Aunque no se recomienda, puedes hacer una instantánea de un blob que también tiene 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 haces una instantánea de un blob versionado, creas una nueva versión al mismo tiempo que creas 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.
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). - Utiliza las claves de acceso a la cuenta para autorizar operaciones contra versiones blob usando 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.
| Descripción | Operación de servicio de blob | Acción de datos de Azure RBAC necesaria | Azure soporte para roles integrados |
|---|---|---|---|
| Eliminación de la versión actual | Eliminar Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete | Colaborador de datos de blobs de almacenamiento |
| Eliminación de una versión anterior | Eliminar Blob | Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action | Propietario de datos de blobs de almacenamiento |
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.
| Permiso | Símbolo de URI | Operaciones permitidas |
|---|---|---|
| Eliminar | x | Eliminar una versión de un blob |
Precios y facturación
Activar la versión de blob puede suponer cargos adicionales por almacenamiento de datos en tu cuenta. Al diseñar tu aplicación, ten en cuenta cómo pueden acumularse estos cargos para minimizar costes.
Las versiones de blobs, como las instantáneas de blobs, se facturan con la misma tarifa que los datos activos. La forma en que pagas por las versiones depende de si estableces explícitamente el nivel de acceso para las versiones actuales o anteriores de un blob (o 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 cambias el nivel de un blob o una versión, pagas por bloques únicos de datos en ese blob, sus versiones y cualquier snapshot que pueda tener. Para más información, consulta Facturación cuando el nivel de blob no esté explícitamente establecido.
Si cambias el nivel de un blob o una versión, pagas por el objeto completo, independientemente de si el blob y la versión acaban volviendo a estar en el mismo nivel. Para más información, consulte Facturación cuando el nivel de blob esté explícitamente establecido.
Nota:
Habilitar el versionado para datos que se sobrescriben con frecuencia podría aumentar los cargos de capacidad de almacenamiento y aumentar la latencia durante las operaciones de listado. A fin de mitigar estos problemas, almacene los datos que se sobrescriben con frecuencia en una cuenta de almacenamiento independiente con el control de versiones deshabilitado.
La habilitación de versiones en cuentas de almacenamiento de las que se realiza una copia de seguridad con frecuencia podría desencadenar cargos de recuperación de datos cuando las versiones se almacenan en niveles de acceso esporádico o esporádico.
Para más información sobre los detalles de facturación de las instantáneas de blobs, consulte Instantáneas de blob.
Para las cuentas de almacenamiento que usan 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 del blob
Si no configuras explícitamente el nivel del blob para ninguna de las versiones de un blob, se te cobra por los bloques o páginas únicos de todas las versiones y por cualquier instantánea que pueda tener. Solo pagas una vez por los datos compartidos entre las versiones de blobs. Cuando actualizas un blob, los datos de la nueva versión actual divergen de los datos almacenados en versiones anteriores, y pagas por los datos únicos por bloque o página.
Cuando reemplazas un bloque dentro de un bloque de bloques, pagas por 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 confirmar el bloque, este diverge de su equivalente en la versión anterior y pagas por almacenar 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 pagas por bloques únicos, ten en cuenta que actualizar un blob cuando se habilita el versionado resulta en más bloques únicos y cargos adicionales.
Cuando habilites el control de versiones de blobs, realiza operaciones de actualización en blobs en bloques de modo que se actualice 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. 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 demuestran cómo se acumulan cargos por un blob de bloques y sus versiones cuando no se establece explícitamente el nivel del 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, actualizas un bloque (bloque 3 en el diagrama) dentro 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, pagas por cuatro bloques.
Escenario 3
En el escenario 3, actualizas el blob, pero no actualizas la versión. Sustituyes el bloque 3 por el bloque 4 en el blob actual, pero la versión anterior sigue reflejando el bloque 3. Como resultado, pagas por cuatro bloques.
Escenario 4
En el escenario 4, actualizas completamente la versión actual y no contiene ninguno de sus bloques originales. Como resultado, pagas 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 el nivel de blob está explícitamente establecido
Si configuras explícitamente el nivel del blob para un blob, versión o instantánea, pagas por la longitud total del contenido del objeto en el nuevo nivel, incluso 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. Para cualquier otra versión anterior o instantánea que permanezca en el nivel original, se cobra por los bloques únicos que comparten, como se describe en Facturación cuando el nivel del blob no se establece 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.
| Cuando configuras el nivel de la masa... | Entonces se le factura por... |
|---|---|
| Explícitamente en una versión, ya sea actual o anterior | La longitud de contenido completo de esa versión. Las versiones que no tienen un nivel de servicio establecido explícitamente se facturan solo por bloques únicos.1 |
| Para archivar | La longitud de contenido completo de todas las versiones e instantáneas. 1. |
1Si 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.
En el diagrama siguiente se muestra cómo se facturan los objetos cuando un blob con versión se mueve a un nivel diferente.
No puedes deshacer explícitamente la configuración 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 que tenga un nivel explícitamente establecido, pagas por cualquier versión anterior del blob eliminado suavemente a la longitud completa del contenido. Para más información sobre el uso conjunto del control de versiones de blobs y la eliminación temporal, consulte Control de versiones de blobs y eliminación temporal.
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.
No se admite el control de versiones para los blobs que carga mediante las API de Data Lake Storage.