Administración del ciclo de vida de los objetos

Configuración Muestras de configuración

Cloud Storage ofrece la característica de Administración del ciclo de vida de los objetos a fin de ser compatible con casos prácticos comunes que incluyen establecer un tiempo de actividad (TTL) para los objetos, archivar versiones anteriores de objetos o “cambiar a una versión anterior” de las clases de almacenamiento de objetos para facilitar la administración de los costos.

En esta página, se describen las características y las opciones disponibles cuando se usan. Si deseas obtener más información sobre el formato general del archivo de configuración del ciclo de vida, consulta la representación de recursos del bucket para JSON o el formato de configuración del ciclo de vida para XML.

Introducción

Para usar la Administración del ciclo de vida de los objetos, debes definir una configuración del ciclo de vida, que se debe establecer en un bucket. La configuración contiene un conjunto de reglas que se aplican a los objetos actuales y futuros del bucket. Cuando un objeto cumple con los criterios de una de las reglas, Cloud Storage realiza de forma automática una acción específica en él. Estos son algunos ejemplos de casos de uso:

  • Pasar la clase de almacenamiento de objetos con más de 365 días a Coldline Storage
  • Borrar objetos creados antes del 1 de enero de 2019
  • Conservar solo las 3 versiones más recientes de cada objeto en un bucket con el control de versiones habilitado

Configuración del ciclo de vida

Cada configuración de administración del ciclo de vida contiene un conjunto de reglas. Cada regla contiene una acción y una o más condiciones.

  • Un objeto debe coincidir con todas las condiciones especificadas en una regla para que se realice la acción de la regla.

  • Si especificas varias reglas que contienen la misma acción, esta se realiza en un objeto cuando ese objeto coincide con las condiciones de cualquiera de las reglas.

  • Si se cumplen las condiciones de varias reglas de forma simultánea para un solo objeto, Cloud Storage realiza la acción asociada con solo una de las reglas, según las siguientes consideraciones:

    • La acción Delete tiene prioridad sobre cualquier acción SetStorageClass.
    • La acción SetStorageClass que cambia el objeto a la clase de almacenamiento con el precio de almacenamiento en reposo más bajo tiene prioridad.

    Por ejemplo, si tienes una regla que cambia la clase del objeto a Nearline Storage y otra que la cambia a Coldline Storage, pero ambas reglas usan la misma condición, la clase del objeto siempre cambia a Coldline Storage cuando se cumple la condición.

  • Debes probar las reglas del ciclo de vida en los datos en desarrollo antes de aplicarlas a la producción para asegurarte de que no realicen acciones en conjuntos de condiciones no deseados. Si eso no es posible, debes realizar pruebas en un subconjunto pequeño de tus datos de producción mediante las condiciones matchesPrefix o matchesSuffix en tus reglas.

  • Los cambios en la configuración del ciclo de vida de un depósito pueden tardar hasta 24 horas en aplicarse, y la Administración del ciclo de vida de los objetos aún puede realizar acciones basadas en la configuración anterior durante este tiempo.

    Por ejemplo, si cambias una condición age de 10 días a 20, la Administración del ciclo de vida de los objetos podría borrar un objeto de 11 días de antigüedad hasta 24 horas más tarde, debido a los criterios de la configuración anterior.

Para casos prácticos, consulta Ejemplos de configuración para la Administración del ciclo de vida de los objetos.

Acciones del ciclo de vida

Una regla de ciclo de vida especifica exactamente una de las siguientes acciones:

Borrar

La acción Delete borra un objeto cuando este cumple con todas las condiciones especificadas en la regla del ciclo de vida. Según la configuración predeterminada, cuando borras un objeto activo, este se borra de forma no definitiva y Cloud Storage lo conserva durante siete días. Puedes restore este objeto borrado de forma no definitiva dentro del período de retención de la eliminación no definitiva.

Excepción: En los buckets con el control de versiones de objetos habilitado, borrar la versión publicada de un objeto hace que se convierta en una versión no actual, mientras que borrar una versión no actual provoca que se borre esa versión del bucket. Consulta la configuración para borrar objetos a fin de obtener un ejemplo del uso de la acción Delete junto con el control de versiones de objetos.

La acción Delete no tiene efecto en un objeto mientras ese objeto tenga una conservación de objetos en él o una política de retención que aún no se completó. Siempre que las condiciones de la acción Delete se cumplan para el objeto, la acción Delete se produce después de que se quita cualquier conservación de objeto y se cumple cualquier política de retención.

SetStorageClass

La acción SetStorageClass cambia la clase de almacenamiento de un objeto y actualiza la hora de modificación del objeto cuando este cumple con todas las condiciones especificadas en la regla del ciclo de vida.

SetStorageClass es compatible con las siguientes transiciones de clases de almacenamiento:

Clase de almacenamiento original Nueva clase de almacenamiento
Durable Reduced Availability Storage (DRA) Nearline storage
Coldline storage
Archive storage
Multi-Regional storage/Regional storage1
Standard storage, Multi-Regional storage o Regional storage Nearline Storage
Coldline Storage
Archive Storage
Nearline Storage Coldline Storage
Archive Storage
Coldline Storage Archive Storage

1 Para los buckets en una región, la clase de almacenamiento nueva no puede ser Multi-Regional Storage. En el caso de los buckets en una región doble o múltiple, la clase de almacenamiento nueva no puede ser Regional Storage.

Cloud Storage no valida si la transición de la clase de almacenamiento es correcta. Esto significa que puedes especificar una transición de una clase de almacenamiento que no aparece en la tabla anterior, pero la transición no se llevará a cabo. Debes verificar que en las reglas del ciclo de vida se usen las transiciones de una clase de almacenamiento de la lista.

Anula cargas multiparte incompletas

La acción AbortIncompleteMultipartUpload anula una carga multiparte incompleta y borra las partes asociadas cuando la carga multiparte cumple las condiciones especificadas en la regla del ciclo de vida.

Con esta acción, solo se pueden usar las siguientes condiciones del ciclo de vida:

Si intentas crear una regla que use la acción AbortIncompleteMultipartUpload en combinación con otras condiciones, se generará un error.

Condiciones del ciclo de vida

Una regla de ciclo de vida incluye condiciones que un objeto debe cumplir antes de que la acción definida en la regla se produzca en él. Las reglas de ciclos de vida son compatibles con las siguientes condiciones:

Todas las condiciones son opcionales, pero se requiere al menos una. Si quieres establecer una configuración del ciclo de vida no válida, como el uso de una acción o condición que no existe, recibirás una respuesta de error 400 Bad request, y no se modificará ninguna configuración del ciclo de vida existente.

age

La condición age se cumple cuando un recurso alcanza la antigüedad especificada (en días). La antigüedad se mide desde la hora de creación del recurso.

  • En el caso de los objetos, la hora de creación es el momento en que el objeto se escribe en el bucket de forma correcta, como cuando se completa una carga.

    • La antigüedad de un objeto no se ve afectada cuando el objeto se convierte en una versión no actual.

  • En el caso de las cargas de varias partes, la hora de creación es el momento en que se inicia la carga.

Por ejemplo, si se crea un recurso el 10/01/2022 a las 10:00 UTC y la condición age es de 10 días, la condición se cumple para el recurso a partir del 20/01/2022 a las 10:00 UTC.

createdBefore

La condición createdBefore se cumple cuando se crea un objeto antes de la medianoche de la fecha especificada en UTC.

customTimeBefore

La condición customTimeBefore se cumple cuando la parte correspondiente a la fecha de los metadatos Custom-Time de un objeto es anterior a la fecha especificada en esta condición. Esta condición se establece con el formato de fecha YYYY-MM-DD. customTimeBefore nunca se cumple en un objeto sin metadatos Custom-Time establecidos.

daysSinceCustomTime

La condición daysSinceCustomTime se cumple cuando la cantidad especificada de días pasó desde la fecha y hora especificadas en el campo de metadatos Custom-Time de un objeto. Por ejemplo, si la Custom-Time de un objeto es 2020-05-16T10:00:00Z y la condición daysSinceCustomTime es de 10 días, la condición se cumple para el objeto a partir del 2020/05/26 10:00 UTC.

daysSinceCustomTime nunca se cumple en un objeto sin metadatos Custom-Time establecidos.

daysSinceNoncurrentTime

Por lo general, la condición daysSinceNoncurrentTime solo se usa junto con el control de versiones de objetos. La condición se cumple cuando la cantidad especificada de días pasó desde que el objeto se convirtió en no actual, ya sea porque la versión publicada se borró o se reemplazó. Por ejemplo, si un objeto se convirtió en no actual el 2020/07/08 15:00 UTC y la condición daysSinceNoncurrentTime es de 10 días, la condición se cumple para el objeto a partir del 2020/07/18 15:00 UTC.

isLive

Por lo general, la condición isLive solo se usa junto con el control de versiones de objetos. Cuando se establece en false, esta condición se cumple para cualquier versión no actual de un objeto. Cuando se establece en true, esta condición se cumple para la versión publicada de un objeto. Si no usas el control de versiones, todos tus objetos se consideran publicados y coinciden cuando isLive se establece en true.

matchesPrefix y matchesSuffix

Las condiciones matchesPrefix y matchesSuffix se cumplen cuando el principio o el final del nombre de un objeto coincide exactamente con el prefijo o sufijo especificado, distinguiendo mayúsculas de minúsculas. Puedes especificar varias strings como una lista (por ejemplo, "matchesSuffix": [".jpg", ".png"]).

Cuando uses matchesPrefix, no incluyas el nombre del bucket ni el / que precede a los nombres de objetos en la mayoría de las rutas de solicitud. Por ejemplo, en Google Cloud CLI, la ruta a un objeto en un bucket denominado my_bucket tiene un formato similar a gs://my_bucket/pictures/paris_2022.jpg. Para que coincida con el objeto, debes usar una condición como "matchesPrefix":["pictures/paris_"].

Puedes tener hasta 50 prefijos y 50 sufijos especificados en todas las reglas. No se puede usar un prefijo ni sufijo dos veces en una sola condición.

matchesStorageClass

La condición matchesStorageClass se cumple cuando se almacena un objeto en el bucket como la clase de almacenamiento especificada. Puedes usar los siguientes valores para matchesStorageClass: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL y DURABLE_REDUCED_AVAILABILITY.

En general, si quieres usar la condición matchesStorageClass en objetos de Standard Storage, también debes incluir lo siguiente:

  • Si el depósito está en una región, debes incluir REGIONAL y DURABLE_REDUCED_AVAILABILITY en la condición.

  • Si el bucket está en una región doble o múltiple, incluye MULTI_REGIONAL y DURABLE_REDUCED_AVAILABILITY en la condición.

La inclusión de estas clases adicionales garantiza que la regla del ciclo de vida cubra objetos más antiguos en tus buckets, los que pueden configurarse en clases de almacenamiento heredadas.

noncurrentTimeBefore

Por lo general, la condición noncurrentTimeBefore solo se usa junto con el control de versiones de objetos. La condición se cumple en los objetos que se convirtieron en no actuales en una fecha anterior a la que se especifica en esta condición. La condición se establece con el formato de fecha YYYY-MM-DD. noncurrentTimeBefore nunca se cumple en un objeto activo.

numNewerVersions

Por lo general, la condición numNewerVersions solo se usa junto con el control de versiones de objetos. Si el valor de esta condición se establece en N, una versión de objeto cumple con la condición cuando existen, al menos, N versiones más recientes que esta (incluida la versión publicada). Para la versión publicada de un objeto, la cantidad de versiones más recientes es 0. Para la versión no actual más reciente, la cantidad de versiones más recientes es 1 (o 0 si no existen versiones publicadas de un objeto), y así de forma sucesiva.

Comportamiento del ciclo de vida del objeto

Cloud Storage inspecciona con regularidad todos los objetos en un bucket en el que esté configurada la Administración del ciclo de vida de los objetos y realiza todas las acciones aplicables según las reglas del bucket. Cloud Storage realiza una acción de manera asíncrona, por lo que puede haber un lapso de tiempo entre el momento en el que las condiciones se cumplen y en el que se realiza la acción. Tus aplicaciones no deben depender de las acciones del ciclo de vida que se producen en un determinado período después de que se cumple una condición del ciclo de vida.

Por ejemplo, si un objeto cumple con las condiciones para la eliminación, es posible que el objeto no se borre de inmediato y lo veas hasta que la acción del ciclo de vida se ejecute en él. En buckets que tienen habilitado el control de versiones de objetos, esto significa que un objeto activo existirá en un estado no actual por un tiempo, incluso si la versión no actual del objeto también cumple con las condiciones de la regla de eliminación.

Se siguen aplicando cargos aplicables mientras el objeto se mantenga en su estado original, con una excepción: los costos del almacenamiento en reposo no se aplican si el objeto cumple con todos los criterios siguientes:

  • El objeto está en un bucket con la opción de eliminación no definitiva inhabilitada
  • El objeto está sujeto a una regla con una acción Delete
  • La única condición para la regla es una condición age
  • La condición age se cumple en el objeto.

Consideraciones de costo para SetStorageClass

De manera similar a Cambia clases de almacenamiento de objetos de forma manual, el uso de SetStorageClass cuenta como una operación de Clase A y se factura con la tarifa que determina la clase de almacenamiento del destino

A diferencia del cambio de la clase de almacenamiento de un objeto de forma manual, el uso de SetStorageClass no reescribe un objeto. Esto le brinda a la Administración del ciclo de vida de los objetos ciertas ventajas de precios:

Por ejemplo, supongamos que subiste un objeto como Nearline Storage y, 20 días después, la configuración del ciclo de vida cambia la clase de almacenamiento del objeto a Coldline Storage. Este cambio no genera tarifas de recuperación ni de eliminación temprana. Si borras el objeto 60 días después del cambio de clase de almacenamiento, solo se aplicará un cargo por eliminación temprana correspondiente a 10 días, dado que Coldline Storage tiene una duración mínima de almacenamiento de 90 días y el objeto existió por un total de 80 días.

En comparación, supongamos que subiste un objeto como Nearline Storage y, 20 días después, cambias la clase de almacenamiento mediante una reescritura (de nuevo a Coldline Storage). Este cambio genera una tarifa de recuperación y un cargo de eliminación temprana correspondiente a 10 días. Si borras el objeto 60 días después de la reescritura, hay un cargo por eliminación temprana correspondiente a 30 días.

En ambos ejemplos, si la eliminación no definitiva está habilitada en el bucket, los cargos por almacenamiento aumentan, pero los cargos por eliminación temprana se reducen según la duración del período de retención de eliminación no definitiva.

Hora de creación de los objetos

En muchos casos, la carga de un objeto se completa poco después de que comienza. Sin embargo, para las cargas que ocurren en varias solicitudes, como las cargas reanudables, pueden pasar días entre el momento en el que se envía la solicitud de carga inicial y el momento en que se envía la solicitud de carga final. En esos casos, debes tener en cuenta lo siguiente:

  • Un objeto no está sujeto a las reglas del ciclo de vida hasta que se completa la carga.
  • La hora de creación de un objeto se basa en la finalización de la carga. Esto afecta las condiciones del ciclo de vida de age y createdBefore.
  • Cuando configuras un Custom-Time para el objeto, lo haces al comienzo de la carga. Si configuras un Custom-Time según el momento de la solicitud, Custom-Time podría darse mucho antes que la hora de creación del objeto. Esto afecta las condiciones del ciclo de vida de customTimeBefore y daysSinceCustomTime.

Metadatos de hora de vencimiento

Si se especifica una acción Delete para un bucket con la condición age (y ninguna otra condición aparte de matchesStorageClass), algunos objetos pueden etiquetarse con metadatos de hora de vencimiento. La hora de vencimiento de un objeto indica el momento en que el objeto cumple (o cumplió) con las condiciones para que la Administración del ciclo de vida de los objetos lo borre. La hora de vencimiento puede cambiar a medida que cambia la configuración del ciclo de vida del bucket o la política de retención.

Ten en cuenta que la ausencia de los metadatos de hora de vencimiento no significa necesariamente que el objeto no se borrará, sino que no hay suficiente información disponible para determinar cuándo se borrará o si se borrará. Por ejemplo, si la hora de creación de un objeto es 10:00 UTC del 10/01/2020 y la condición age es 10 días, entonces la hora de vencimiento del objeto es a las 10:00 UTC del 20/01/2020. Sin embargo, la hora de vencimiento no está disponible para el objeto en los siguientes casos:

  • Hay otras condiciones especificadas en la regla Delete, con la excepción de matchesStorageClass.

  • Usas una condición matchesStorageClass que no incluye la clase de almacenamiento del objeto.

  • El objeto está en conservación, debido a que Cloud Storage no puede saber cuándo se quitará la conservación.

  • La eliminación no definitiva está habilitada en tu bucket.

No se cobra por el almacenamiento después de la hora de vencimiento del objeto incluso si el objeto no se borra de inmediato. Puedes acceder al objeto antes de que se borre. Eres responsable de otros cargos (solicitud, ancho de banda de la red). Si la hora de vencimiento no está disponible para un objeto, se cobra por el almacenamiento del objeto hasta el momento en que se borre.

Cuando trabajes con horas de vencimiento, ten en cuenta lo siguiente:

  • Si el bucket tiene una política de retención, la hora de vencimiento es la última de la condición age de la Administración del ciclo de vida de los objetos y la hora en que el objeto cumple con el período de retención que especifica la política de retención.

  • Si existen varias horas de vencimiento en conflicto aplicables para un objeto debido a diferentes reglas de administración de ciclos de vida, se usa la primera hora de vencimiento aplicable.

Opciones para el seguimiento de las acciones del ciclo de vida

Para realizar un seguimiento de las acciones de administración del ciclo de vida que realiza Cloud Storage, usa una de las siguientes opciones:

  • Usa los registros de uso de Cloud Storage. Esta característica registra la acción y quién la realiza. Un valor de GCS Lifecycle Management en el campo cs_user_agent de la entrada de registro indica que Cloud Storage realizó la acción en función de una configuración del ciclo de vida.
  • Habilita las notificaciones de Pub/Sub para Cloud Storage en tu bucket. Con esta característica, se envían notificaciones a un tema de Pub/Sub de tu elección cuando se producen acciones específicas. Ten en cuenta que en esta característica no se registra quién realizó las acciones.

¿Qué sigue?