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 archivada de un objeto cada vez que reemplazas o borras la versión publicada del objeto. La versión archivada 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 los objetos archivados requieren números de generación para poder identificarlos.

Cuando el control de versiones de objetos está habilitado, puedes enumerar las versiones archivadas de un objeto, restablecer la versión publicada de un objeto a un estado anterior o borrar permanentemente una versión archivada, 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 los objetos existentes en su lugar y hace que el depósito pare de acumular versiones de objetos archivadas nuevas.

Detalles del control de versiones de objetos

En Cloud Storage, se usan dos propiedades que identifican juntas la versión de un objeto. Una propiedad identifica la versión de los datos del objeto y la otra propiedad 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 tenga una política de retención actualmente.

Metadatos de objetos archivados

Los objetos archivados tienen sus propios metadatos, los cuales pueden diferir de los metadatos de los objetos publicados. Lo más importante es que una versión archivada conserva sus LCA y no necesariamente tiene los mismos permisos que la versión publicada del objeto.

Cada objeto, ya sea publicado o con versión, 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 un objeto archivado especificando su generation en la solicitud. Para garantizar una semántica segura de lectura, modificación y escritura, 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 archivado. La versión archivada conserva la misma clase de almacenamiento y metadatos que tenía anteriormente. La versión archivada 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 archivada 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

Borras cat.jpg. Cuando haces esto, se archiva la versión que tenía el número de generación 1360887759327000. Tu depósito ahora contiene dos versiones archivadas de cat.jpg y ninguna versión publicada. Aún puedes referirte a cualquiera de las versiones archivadas 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 más información sobre cómo enumerar versiones archivadas de objetos, consulta Enumerar versiones de objetos archivados.

Inhabilitas el control de versiones

Inhabilitas el control de versiones de objetos, el cual detiene el archivo futuro de objetos. Las versiones archivadas 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 manualmente o mediante laAdministración del ciclo de vida de los objetos.

Restableces una de las versiones archivadas

Incluso con el control de versiones de objetos inhabilitado, puedes restablecer una de las versiones archivadas existentes cuando haces una copia de esta. Para hacerlo, dale a la copia el nombre de cat.jpg. Una vez que haces esto, tu depósito tiene tres versiones de cat.jpg: las dos versiones archivadas y la versión en vivo que resultó de hacer una 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 gsutil tiene asistencia integral para trabajar con objetos con versión, lo que facilita muchas tareas que involucran al control de versiones de objetos. Por ejemplo, puedes trabajar con versiones archivadas de objetos agregando # y el número 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 de objeto archivada en la versión publicada actual. Consulta Copia versiones de objetos archivados para obtener una guía paso a paso sobre cómo copiar objetos archivados.

    Cuando haces esto con el control de versiones de objeto habilitada, si ya existe una versión publicada del objeto en tu depósito, Cloud Storage lo reemplaza, pero también crea una versión archivada nueva del objeto reemplazado. En tal caso, después tu depósito contiene el objeto reemplazado (ahora archivado) y dos copias del objeto que se archivó previamente (una copia publicada y una copia aún archivada), todos los cuales generan cargos de almacenamiento. A fin de evitar cargos innecesarios, borra la versión archivada que usaste para hacer la copia publicada actual.

  • Si envías una solicitud para borrar sin especificar una generación, se archiva el objeto publicado actual en Cloud Storage y esto hace que falte en las solicitudes posteriores de la versión no especificada.

  • Si envías una solicitud para borrar con un generation que corresponde al objeto publicado actualmente, Cloud Storage borra el objeto sin hacer una copia archivada.

  • Cuando se borra un objeto archivado, se borra esa versión del objeto de forma permanente en Cloud Storage.

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 correctamente siempre que haya un objeto con ese nombre y número de generación, independientemente de si está publicado o archivado. 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 correctamente si la versión publicada del objeto tiene especificado el número de generación. Si no existe tal objeto o está archivado, se muestra 412 Precondition Failed en Cloud Storage.

  • 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 de PUT con la API de XML para crear un objeto nuevo con el encabezado x-goog-if-generation-match:0, la solicitud se ejecuta de forma correcta si no existe el objeto o si solo hay versiones archivadas de este. 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.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Si necesitas ayuda, visita nuestra página de asistencia.