Conservación de metadatos

En este documento, se describen los metadatos que se conservan cuando usas el Servicio de transferencia de almacenamiento para transferir datos entre varias fuentes y destinos.

Descripción general

El Servicio de transferencia de almacenamiento conserva los siguientes metadatos:

Se conservan los metadatos personalizados creados por el usuario para las transferencias que se originan en Cloud Storage, Amazon S3 o Microsoft Azure Blob Storage.
Las transferencias entre depósitos de Cloud Storage pueden preservar de manera opcional las LCA de objetos, las claves de encriptación administradas por el cliente, la clase de almacenamiento, el momento de creación del objeto (como el valor de un campo customTime) y las conservaciones temporales.
Para las transferencias de cualquier fuente a un bucket de Cloud Storage, la clase de almacenamiento del objeto en el bucket de destino se puede establecer en cualquier clase compatible como parte de la transferencia.
El tamaño del archivo y la hora de la última modificación (mtime) se conservan para las transferencias que se originan en sistemas de archivos POSIX. mtime no se conserva para las carpetas.
De manera opcional, los symlinks, los UID numéricos, GID numéricos y MODE numéricos se pueden conservar para las transferencias hacia y desde los sistemas de archivos POSIX.
Solo para las transferencias entre sistemas de archivos, si se conservan UID, GID o MODE, esos metadatos también se conservan para las carpetas. Cloud Storage recrea las carpetas en el sistema de archivos de destino y restablece los UID, GID o MODE. Esto incluye carpetas vacías. mtime no se conserva.

Los metadatos a nivel de carpeta no se conservan si la transferencia se realiza mediante el manifiesto.

Los campos de metadatos que no se mencionan de forma explícita en este documento no se conservan.

Comportamiento de la conservación de metadatos

En las siguientes secciones, se enumeran ejemplos de metadatos de diferentes sistemas de almacenamiento de origen y cómo el Servicio de transferencia de almacenamiento conserva los metadatos de cada uno. Para obtener una lista completa de metadatos, consulta la documentación del sistema de almacenamiento de origen.

De Amazon S3 a Cloud Storage

Ejemplo de metadatos	Comportamiento de la preservación
Campos de metadatos de clave fija de Amazon S3, como `Cache-Control`, `Content-Disposition` y `Content-Type`	Se conserva como metadatos de clave fija.
Metadatos definidos por el usuario de Amazon S3, con formato de pares clave-valor. Para obtener más información, consulta la sección Metadatos de objeto definidos por el usuario de Clave y metadatos de objeto.	Se conserva como un campo de metadatos personalizados en objetos de destino de Cloud Storage, que puedes editar más adelante o quitar.
`ETag`	Se conserva como un campo de metadatos personalizados con la clave `x-goog-source-etag`, que puedes editar más adelante o quitar.
Tamaño del objeto	Se conserva como `size`.
Listas de control de acceso (LCA) de Amazon S3 Para obtener una lista completa, consulta la sección Claves de condición de la Descripción general de las listas de control de acceso (LCA).	No se conservan
Etiquetas de objeto de Amazon S3, definidas por ti como pares clave-valor Para obtener más información, consulta Etiquetas de objetos.	No se conservan
Metadatos definidos por el sistema de Amazon S3, excepto `ETag` y el tamaño del objeto Para obtener una lista completa, consulta la sección Metadatos de objeto definidos por el sistema de Clave y metadatos de objeto.	No se conservan Los metadatos de marca de tiempo de la fuente no se conservan. La hora de creación, `timeCreated`, refleja la hora en la que se crea un objeto en Cloud Storage. De manera similar, `updated` refleja el tiempo en que los metadatos de un objeto se modifican en Cloud Storage.
Clase de almacenamiento	Existen varias opciones para configurar la clase de almacenamiento durante una transferencia. Configura la clase de almacenamiento de cada objeto con la del bucket de destino. Este es el comportamiento predeterminado. Establece una clase de almacenamiento específica en todos los objetos que se transfieren. Consulta la documentación de referencia metadataOptions para obtener más información.

De Microsoft Azure Storage a Cloud Storage

Ejemplo de metadatos	Comportamiento de la preservación
Campos de metadatos de clave fija de Microsoft Azure Storage, como `Cache-Control`, `Content-Disposition` y `Content-Type`	Se conserva como metadatos de clave fija.
Metadatos definidos por el usuario de Microsoft Azure Storage, con formato de pares clave-valor. Para obtener más información, consulta Configuración y recuperación de propiedades y metadatos para recursos del servicio de Blob.	Se conserva como un campo de metadatos personalizados en objetos de destino de Cloud Storage, que puedes editar más adelante o quitar.
`ETag`	Se conserva como un campo de metadatos personalizados con la clave `x-goog-source-etag`, que puedes editar más adelante o quitar.
Tamaño del objeto	Se conserva como `size`.
Permisos del sistema de archivos POSIX compatibles con Azure Data Lake Storage (ADLS) Gen 2.	No se conservan
Control de acceso de Microsoft Azure Storage, en particular `x-ms-blob-public-access`. Para obtener más información, consulta la sección Encabezados de respuesta de Obtén LCA de contenedores.	No se conservan
Etiquetas de índice de Microsoft Azure Storage Para obtener más información, consulta Administra y busca datos de Azure Blob con etiquetas de índice de BLOB.	No se conservan
Metadatos de marca de tiempo de Microsoft Azure Storage, como: `Last-Modified`, `x-ms-creation-time`, `x-ms-version`, `x-ms-request-server-encrypted` y `x-ms-encryption-scope` Para obtener más información, consulta Configura metadatos de BLOB.	No se conservan Los metadatos de marca de tiempo de la fuente no se conservan. La hora de creación, `timeCreated`, refleja la hora en la que se crea un objeto en Cloud Storage. De manera similar, `updated` refleja el tiempo en que los metadatos de un objeto se modifican en Cloud Storage.
Clase de almacenamiento	Existen varias opciones para configurar la clase de almacenamiento durante una transferencia. Configura la clase de almacenamiento de cada objeto con la del bucket de destino. Este es el comportamiento predeterminado. Establece una clase de almacenamiento específica en todos los objetos que se transfieren. Consulta la documentación de referencia metadataOptions para obtener más información.

Transferencias entre buckets de Cloud Storage

Ejemplo de metadatos	Comportamiento de la preservación
Campos de metadatos de clave fija de Cloud Storage, como `Cache-Control`, `Content-Disposition` y `Content-Type` Para obtener más información, consulta Metadatos de objetos.	Se conserva como metadatos de clave fija.
Metadatos definidos por el usuario de Cloud Storage, con formato de pares clave-valor. Para obtener más información, consulta Metadatos personalizados.	Se conserva como un campo de metadatos personalizados en objetos de destino de Cloud Storage, que puedes editar más adelante o quitar.
Tamaño del objeto	Se conserva como `size`.
Generación de objetos	Se conserva como un campo de metadatos personalizado con la clave `x-goog-reserved-source-generation`, que puedes editar más tarde o quitar.
Conservaciones de objetos	Las conservaciones basadas en eventos no se conservan. Si el bucket de destino tiene habilitada la propiedad predeterminada de conservación basada en eventos, se aplica una conservación basada en eventos a los objetos transferidos. Las conservaciones temporales se conservan de forma predeterminada. Para descartar conservaciones temporales durante la transferencia, establece el campo `temporaryHold` del objeto metadataOptions en `TEMPORARY_HOLD_SKIP`.
Listas de control de acceso (LCA)	De forma opcional, las LCA se pueden conservar. Consulta la documentación de referencia de metadataOptions para obtener más información. Cuando conserves las LCA, ten cuidado para evitar crear objetos inaccesibles. Para obtener más información, consulta la documentación de las Listas de control de acceso de Cloud Storage.
Clase de almacenamiento	Existen varias opciones para configurar la clase de almacenamiento durante una transferencia. Configura la clase de almacenamiento de cada objeto con la del bucket de destino. Este es el comportamiento predeterminado. Conserva la clase de almacenamiento del objeto de origen. Establece una clase de almacenamiento específica en todos los objetos que se transfieren. Consulta la documentación de referencia metadataOptions para obtener más información.
Clave de encriptación administrada por el cliente	Si una clave de encriptación administrada por el cliente (CMEK) se usa en un objeto, este puede usar de manera opcional la misma clave cuando se escribe en el bucket de destino. El comportamiento predeterminado es escribir el objeto en el bucket de destino con el método de encriptación del bucket. Cuando se conserva la CMEK original, ten en cuenta las siguientes limitaciones: El bucket de destino debe estar en la misma ubicación que la CMEK. Si el bucket de destino está en otro proyecto, debes agregar la cuenta de servicio de Cloud Storage del proyecto de destino del proyecto de destino a la clave. Consulta la documentación de referencia metadataOptions para obtener más información.
Metadatos de marcas de tiempo	De forma opcional, `timeCreated` se puede conservar. El valor conservado se almacena en el campo `customTime` del objeto transferido en Cloud Storage. Consulta la documentación de referencia metadataOptions para obtener más información. Los metadatos `updated` no se conservan.
Otros metadatos no editables de Cloud Storage, como `etag` y `componentCount`	No se conservan

Para obtener una lista de metadatos en Cloud Storage, consulta Objetos.

Transferencia de listas de URL a Cloud Storage

Para obtener más información sobre las listas de URL, consulta Crea una lista de URL.

Ejemplo de metadatos	Comportamiento de la preservación
Campos de metadatos de clave fija, como `Cache-Control`, `Content-Disposition` y `Content-Type`	Se conservan como metadatos editables.
`Content-Length` y `MD5`	Se conservan como metadatos no editables. Si la fuente no proporciona un valor de hash `MD5`, no conservamos un valor. Este comportamiento de conservación es específico de `Content-Length` y `MD5`. Cualquier otro metadato no editable que no se enumere no se conserva.
Metadatos de marca de tiempo, como: hora de creación, hora de modificación y otros metadatos específicos de la fuente.	No se conservan Los metadatos de marca de tiempo de la fuente no se conservan. La hora de creación, `timeCreated`, refleja la hora en la que se crea un objeto en Cloud Storage. De manera similar, `updated` refleja el tiempo en que los metadatos de un objeto se modifican en Cloud Storage.
Clase de almacenamiento	Existen varias opciones para configurar la clase de almacenamiento durante una transferencia. Configura la clase de almacenamiento de cada objeto con la del bucket de destino. Este es el comportamiento predeterminado. Establece una clase de almacenamiento específica en todos los objetos que se transfieren. Consulta la documentación de referencia metadataOptions para obtener más información.

Transferencias del sistema de archivos POSIX

Cuando se transfieren archivos de sistemas de archivos POSIX, el Servicio de transferencia de almacenamiento puede conservar de manera opcional ciertos atributos como metadatos personalizados. Si estos archivos se vuelven a escribir más tarde en un sistema de archivos, el Servicio de transferencia de almacenamiento puede volver a convertir los metadatos preservados en atributos POSIX.

Ejemplo de metadatos	Comportamiento de la preservación
Hora modificada (`mtime`)	Se conservan `mtime` se conserva como metadatos personalizados con la clave `goog-reserved-file-mtime`.
Tamaño del archivo	Se conservan El tamaño de archivo se conserva como `size`.
UID numérico GID numérico MODO numérico Vínculos simbólicos	Opcional. El comportamiento de conservación se especifica con el objeto `metadataOptions`. Consulta Conserva metadatos de POSIX opcionales para obtener más detalles. El comportamiento predeterminado es no conservar ningún metadato.
Metadatos de la carpeta	Los metadatos a nivel de carpeta solo se conservan para las transferencias entre sistemas de archivos. La configuración de preservación de UID, GID y MODE de la transferencia se aplica a los archivos y las carpetas para estas transferencias. `mtime` no se conserva para las carpetas. `mtime` se configura en la hora de creación de la carpeta en el sistema de archivos de destino. Los metadatos de la carpeta no se conservan para las transferencias del manifiesto.
Clase de almacenamiento	Existen varias opciones para configurar la clase de almacenamiento durante una transferencia. Configura la clase de almacenamiento de cada objeto con la del bucket de destino. Este es el comportamiento predeterminado. Establece una clase de almacenamiento específica en todos los objetos que se transfieren. Consulta la documentación de referencia metadataOptions para obtener más información.

Conserva metadatos POSIX opcionales

Para conservar uno o más UID numéricos, GID numéricos, MODE numéricos y vínculos simbólicos, especifica un objeto metadataOptions en el cuerpo de tu trabajo de transferencia.

Estas opciones se aplican a las transferencias de POSIX a Cloud Storage y a las transferencias de Cloud Storage a POSIX. Para este último, los metadatos deben conservarse cuando se transfirieron los archivos a Cloud Storage al principio.

{
  "description": "metadata-example",
  "projectId": "example-project-id"
  "transferSpec": {
    ...
    "transferOptions": {
      "metadataOptions": {
        "gid":     "GID_NUMBER",       # Default is "GID_SKIP"
        "uid":     "UID_NUMBER",       # Default is "UID_SKIP"
        "mode":    "MODE_PRESERVE",    # Default is "MODE_SKIP"
        "symlink": "SYMLINK_PRESERVE"  # Default is "SYMLINK_SKIP"
      }
    }
  }
}

POSIX a Cloud Storage

Los metadatos conservados se almacenan en Cloud Storage como pares clave-valor de metadatos personalizados.

El GID numérico se almacena como goog-reserved-posix-gid.
El UID numérico se almacena como goog-reserved-posix-uid.
El MODE numérico se almacena como goog-reserved-posix-mode.

Para los vínculos simbólicos, el Servicio de transferencia de almacenamiento conserva el vínculo de destino como un objeto en Cloud Storage con las siguientes calidades:

La clave del objeto está compuesta por el prefijo de destino más la ruta de acceso al symlink, en relación con root_directory.
Metadatos de objeto:
- Todos los metadatos de symlink se conservan como metadatos de objeto de Cloud Storage.
- Se crea una entrada de metadatos personalizados: goog-reserved-file-is-symlink:true.
El contenido del objeto es el destino del symlink. Por ejemplo, para un symlink sym-> dir1/target, el contenido del objeto es “dir1/target”.

El Servicio de transferencia de almacenamiento no valida el vínculo ni copia el archivo de destino.

Cloud Storage a POSIX

Si los metadatos se conservan cuando los archivos se transfieren a Cloud Storage, esos metadatos se pueden volver a escribir en los archivos cuando se transfieren de nuevo a un sistema de archivos POSIX.

Si se configura una opción de metadatos para conservar, el Servicio de transferencia de almacenamiento realiza las siguientes acciones:

Vínculos simbólicos: El Servicio de transferencia de almacenamiento crea un archivo symlink que apunta al vínculo de destino. Si el archivo de destino no existe, el symlink se romperá.
GID, UID y MODE: los valores almacenados en los metadatos de Cloud Storage se vuelven a escribir en el archivo.

De POSIX a POSIX

De manera opcional, las transferencias entre sistemas de archivos pueden conservar GID, UID y MODE para archivos y carpetas.

La hora de la última modificación se guarda para los archivos, pero no para las carpetas. mtime se establece en la hora de creación de la carpeta en el sistema de archivos de destino.

El Servicio de transferencia de almacenamiento guarda los metadatos de las carpetas mediante la creación de objetos de carpetas de 0 bytes en el bucket intermedio y, luego, vuelve a copiar esos metadatos en la carpeta del sistema de archivos de destino. Por este motivo, la cantidad de objetos creados en el bucket intermedio puede ser mayor que la cantidad de archivos que se transfieren.