Control de versiones de objetos

Para admitir la recuperación cuando se borran o reemplazan objetos, se ofrece la función de control de versiones de los objetos en Cloud Storage. En esta página, se describe la característica y la disponibilidad de opciones cuando esta se usa. Para obtener más información sobre cómo habilitar y usar el control de versiones de los objetos, consulta Usa el control de versiones de objetos.

Habilita el control de versiones de objetos para proteger tus datos de Cloud Storage y evitar reemplazar o borrar accidentalmente los datos. Habilitar el control de versiones de objetos aumenta el costo de almacenamiento, el cual puede mitigarse parcialmente cuando configuras la Administración del ciclo de vida de los objetos para borrar versiones de objetos anteriores.

Introducción

Habilita el control de versiones de objetos para un depósito. Una vez habilitado, en Cloud Storage se crea una versión no actual de un objeto cada vez que reemplazas o borras la versión publicada del objeto. La versión no actual conserva el nombre del objeto, pero se identifica de forma única con un número de generación. Si bien todos los objetos tienen números de generación asociados, solo las versiones no actuales requieren números de generación para poder identificarlas.

Cuando el control de versiones de objetos está habilitado, puedes enumerar las versiones no actuales de un objeto, restablecer la versión publicada de un objeto a un estado anterior o borrar de forma permanente una versión no actual, según sea necesario. Puedes activar o desactivar el control de versiones para un depósito en cualquier momento. Desactivar el control de versiones deja las versiones de objetos existentes en su lugar y hace que el depósito deje de acumular nuevas versiones no actuales de objetos.

Detalles del control de versiones de objetos

En Cloud Storage, se usan dos propiedades que identifican la versión de un objeto. Una propiedad identifica la versión de los datos del objeto y la otra identifica la versión de sus metadatos. Estas propiedades siempre están presentes en todas las versiones del objeto, incluso si el control de versiones de objetos no está habilitado. Estas propiedades se pueden usar como condiciones previas de actualizaciones condicionales para aplicar el pedido de actualizaciones.

En Cloud Storage, se marcan todos los objetos con las siguientes propiedades:

Propiedad Descripción
generation Identifica la generación de contenido (datos) y se actualiza cuando se reemplaza el contenido de un objeto. No existe una relación entre los números de generación de objetos no relacionados, incluso si los objetos están en el mismo depósito.
metageneration Identifica la generación de metadatos y aumenta cada vez que se actualizan los metadatos para una determinada generación de contenido. metageneration se restablece a 1 para cada generation nuevo de un objeto. La propiedad metageneration no tiene sentido sin la propiedad generation y debe usarse solo junto con ella. En otras palabras, no tiene sentido comparar las generaciones de metadatos de dos versiones que tienen diferentes generaciones de datos.

El control de versiones de los objetos no se puede habilitar en un depósito que actualmente tenga una política de retención.

Metadatos de objetos no actuales

Las versiones no actuales de objetos tienen sus propios metadatos, que pueden diferir de los metadatos de la versión publicada. Lo más importante es que una versión no actual conserva sus LCA y no siempre tiene los mismos permisos que la versión publicada.

Cada versión, ya sea publicada o no actual, tiene un conjunto de metadatos. Solo el último número de metageneración se refiere a los metadatos. Los números de metageneración anteriores no se pueden usar para acceder a los metadatos que se cambiaron desde entonces.

Puedes actualizar los metadatos para una versión no actual de un objeto si especificas su generation en tu solicitud. Para garantizar una semántica de lectura, modificación y escritura segura, puedes usar una condición previa de coincidencia de metageneración. El uso de esta condición previa hace que la actualización falle si los metadatos que quieres actualizar se cambiaron entre el momento en que los leíste y que enviaste la actualización.

Ejemplo de control de versiones de los objetos

En este ejemplo, se muestra lo que sucede con el archivo cat.jpg en un depósito con el control de versiones de objetos habilitado a medida que reemplazas, actualizas y borras el archivo.

Subes una imagen nueva

La primera vez que subes cat.jpg a Cloud Storage, recibe un número generation y un número metageneration. En este ejemplo, el número de generación es 1360887697105000. Como el objeto es nuevo, el número metageneration es 1.

cat.jpg recibe los números generation y metageneration aunque el control de versiones de objetos no esté habilitado. Puedes ver estos números con el comando stat en gsutil. Para obtener instrucciones, consulta la visualización de los metadatos de objetos.

Habilitas el control de versiones de objetos

En este punto, decides habilitar el control de versiones de objetos para tu depósito. Hacerlo no afecta los números generation o metageneration de cat.jpg.

Cambias los metadatos de la imagen

Actualizas los metadatos para cat.jpg mediante el agregado de metadatos personalizados: color:black. La actualización de metadatos hace que aumente el valor metageneration de cat.jpg, en este caso de 1 a 2. Sin embargo, el objeto en sí permanece sin cambios, por lo que Cloud Storage continúa almacenando solo una versión de cat.jpg, y la versión sigue teniendo un número generation de 1360887697105000.

Subes una versión nueva de la imagen

Subes una versión nueva de cat.jpg a tu depósito de Cloud Storage. Cuando lo haces, el control de versiones del objeto pasa el objeto cat.jpg existente a un estado no actual. La versión no actual conserva la misma clase de almacenamiento y metadatos que tenía antes. La versión no actual aparece solo si realizas una lista con versión: no aparece en los comandos de lista normales. Ahora se hace referencia a la versión no actual como: cat.jpg#1360887697105000.

Mientras tanto, el cat.jpg que se acaba de subir se convierte en la versión publicada del objeto. Este cat.jpg nuevo obtiene su propio número generation, en este ejemplo: 1360887759327000. También obtiene sus propios metadatos y un número metageneration de 1, lo que significa que no contiene los metadatos color:black, a menos que lo especifiques. Cuando accedes a cat.jpg, o lo modificas, esta es la versión que se usa. Como alternativa, puedes consultar esta versión de cat.jpg con su número generation. Por ejemplo, cuando usas la herramienta gsutil, te referirás a ella como cat.jpg#1360887759327000.

Borras la versión publicada de la imagen

Borra cat.jpg. Cuando lo haces, la versión que tenía el número de generación 1360887759327000 se convierte en no actual. Tu depósito contiene dos versiones no actuales de cat.jpg y ninguna versión publicada. Aún puedes hacer referencia a cualquiera de las versiones no actuales con su número generation, pero falla si intentas acceder a cat.jpg sin un número generation.

Del mismo modo, una lista de objetos normal del depósito no mostrará cat.jpg como uno de los objetos en el depósito. Para obtener información sobre cómo enumerar las versiones no actuales de objetos, consulta Enumera las versiones no actuales de objetos.

Inhabilitas el control de versiones

Inhabilitas el control de versiones de objetos, que evita que los objetos se conviertan en no actuales. Las versiones no actuales de objetos existentes permanecen en Cloud Storage. Aunque el control de versiones de objetos está inhabilitado, cat.jpg#1360887697105000 y cat.jpg#1360887759327000 permanecen almacenados en tu depósito hasta que los borres, ya sea de forma manual o mediante la Administración del ciclo de vida de los objetos.

Restableces una de las versiones no actuales

Incluso con el control de versiones de objetos inhabilitado, puedes restablecer una de las versiones no actuales existentes si haces una copia de esta. Para hacerlo, asigna a la copia el nombre cat.jpg. Una vez que haces esto, tu depósito tiene tres versiones de cat.jpg: las dos versiones no actuales y la versión publicada que se generó cuando se hizo la copia.

Sugerencias

En esta sección, se analizan sugerencias para ayudarte a trabajar con el control de versiones de objetos de manera más efectiva.

Usa gsutil

  • La herramienta de gsutil tiene asistencia integral para trabajar con objetos con versión, lo que facilita muchas tareas que involucran el control de versiones de objetos. Por ejemplo, puedes trabajar con versiones no actuales de objetos si agregas # y el número de generation al nombre del objeto. Para obtener más información sobre el uso de gsutil con el control de versiones de objetos, consulta la página sobre control de versiones de objetos y control de simultaneidad.

Evita usar ETags

  • Considera usar los números generation y metageneration para las actualizaciones condicionales en lugar de ETags. Juntos, los números generation y metageneration realizan un seguimiento de todas las actualizaciones de objetos, incluidos los cambios de metadatos, lo que proporciona una garantía más sólida que ETags.

Comprende el comportamiento de eliminación y restablecimiento de archivos

  • Puedes copiar una versión no actual de objeto en la versión publicada actual. Consulta Copia las versiones de objetos no actuales a fin de obtener una guía paso a paso para copiar versiones no actuales de objetos.

    Cuando haces esto con el control de versiones de objeto habilitado, si ya existe una versión publicada del objeto en tu depósito, Cloud Storage lo reemplaza, pero también crea una versión no actual nueva del objeto reemplazado. En ese caso, tu depósito contendrá el objeto reemplazado (ahora no actual) y dos copias del objeto que antes era no actual (una copia publicada y otra aún no actual) y todos incurren en cargos de almacenamiento. Con el fin de evitar cargos innecesarios, borra la versión no actual que usaste para hacer la copia publicada actual.

  • Si envías una solicitud de eliminación sin especificar una generación, Cloud Storage hace que la versión publicada actual se convierta en no actual, lo que provoca que falte en las solicitudes posteriores de la versión no especificada.

  • Si envías una solicitud de eliminación con un generation que corresponde a la versión publicada actual, Cloud Storage borra el objeto sin hacer una copia no actual.

  • Cuando se borra una versión de objeto no actual, Cloud Storage borra esa versión de forma permanente.

Usa las condiciones previas de coincidencia de generación cuando hagas mutaciones de versiones publicadas de objetos

  • Cuando usas números de generación, una solicitud se realiza con éxito, siempre y cuando haya un objeto con ese nombre y número de generación, sin importar si está publicado o no es actual. Si no existe tal objeto, se muestra 404 Not Found en Cloud Storage.

  • Cuando uses condiciones previas de coincidencia de generación, solo se realiza una solicitud de forma correcta si la versión publicada del objeto tiene especificado el número de generación. Si no existe ese objeto o no es actual, Cloud Storage muestra 412 Precondition Failed.

  • Debes evitar usar una condición previa de coincidencia de generación al mismo tiempo que un número de generación en el nombre del objeto. Si usas ambos y los números coinciden, es redundante usar la condición previa. Si los números no coinciden, la solicitud siempre falla.

  • Si realizas varias solicitudes de mutación simultáneas con una condición previa de coincidencia de generación, la coherencia sólida de Cloud Storage permite que solo una de esas solicitudes sea correcta. Esta característica es útil si tus objetos se actualizan desde varias fuentes y necesitas asegurarte de que los usuarios no los reemplazarán por accidente.

  • Si estableces una condición previa de coincidencia de generación en 0 cuando subes un objeto, se realiza la solicitud especificada en Cloud Storage solo si no hay una versión publicada del objeto. Por ejemplo, si realizas una solicitud PUT con la API de XML para crear un objeto nuevo con el encabezado x-goog-if-generation-match:0, la solicitud se realiza de forma correcta si el objeto no existe o si solo hay versiones no actuales del objeto. Si hay una versión publicada del objeto, se cancela la actualización en Cloud Storage con un código de estado de 412 Precondition Failed.