Preservação de metadados

Este documento descreve os metadados que são preservados quando usa o serviço de transferência de armazenamento para transferir dados entre várias origens e destinos.

Vista geral

O Serviço de transferência de armazenamento preserva os seguintes metadados:

  • Os metadados personalizados criados pelo utilizador para transferências originárias do Cloud Storage, do Amazon S3 ou do Microsoft Azure Blob Storage são preservados.

  • As transferências entre contentores do Cloud Storage podem preservar opcionalmente ACLs de objetos, chaves de encriptação geridas pelo cliente, classe de armazenamento, hora de criação do objeto (como o valor de um campo customTime) e retenções temporárias.

  • Para transferências de qualquer origem para um contentor do Cloud Storage, a classe de armazenamento do objeto no contentor de destino pode ser definida para qualquer classe suportada como parte da transferência.

  • O tamanho do ficheiro e a hora da última modificação (mtime) são preservados para transferências originárias de sistemas de ficheiros POSIX. mtime não é preservado para pastas.

  • Opcionalmente, os links simbólicos, o UID numérico, o GID numérico e o MODE numérico podem ser preservados para transferências de e para sistemas de ficheiros POSIX.

  • Para transferências apenas entre sistemas de ficheiros, se o UID, o GID ou o MODE forem preservados, esses metadados também são preservados para pastas. O Cloud Storage recria as pastas no sistema de ficheiros de destino e restaura o UID, o GID e/ou o MODE. Isto inclui pastas vazias. mtime não é preservado.

    Os metadados ao nível da pasta não são preservados se a transferência for feita através de um manifesto.

Os campos de metadados que não são mencionados explicitamente neste documento não são preservados.

Comportamento de preservação de metadados

As secções seguintes apresentam exemplos de metadados de diferentes sistemas de armazenamento de origem e como o serviço de transferência de armazenamento preserva os metadados de cada um. Para uma lista exaustiva de metadados, consulte a documentação do sistema de armazenamento de origem.

Amazon S3 ou armazenamento compatível com S3 para o Cloud Storage

Exemplo de metadados Comportamento de preservação
Campos de metadados de chave fixa do Amazon S3, como: Cache-Control, Content-Disposition e Content-Type. Preservado como metadados de chave fixa.
Metadados definidos pelo utilizador do Amazon S3, formatados como pares de chave:valor. Para mais informações, consulte a secção Metadados de objetos definidos pelo utilizador da secção Chave e metadados de objetos.

Preservados como um campo de metadados personalizado nos objetos do Cloud Storage de destino, que pode editar ou remover mais tarde.
ETag Preservado como um campo de metadados personalizados com a chave x-goog-source-etag, que pode editar ou remover mais tarde.
Tamanho do objeto. Preservado como size.
Listas de controlo de acesso (LCAs) do Amazon S3. Para ver uma lista completa, consulte a secção Chaves de condição de Vista geral da lista de controlo de acesso (ACL). Não preservado.
Etiquetas de objetos do Amazon S3, definidas por si como pares de chave-valor. Para mais informações, consulte Etiquetas de objetos. Não preservado.
Metadados definidos pelo sistema do Amazon S3, exceto ETag e o tamanho do objeto. Para ver uma lista completa, consulte a secção Metadados de objetos definidos pelo sistema de Chave e metadados de objetos.

Não preservado.

Os metadados de indicação de tempo da origem não são preservados. A hora de criação, timeCreated, reflete a hora em que um objeto é criado no Cloud Storage. Da mesma forma, updated reflete a hora em que os metadados de um objeto são modificados no Cloud Storage.

Classe de armazenamento

Existem várias opções para definir a classe de armazenamento durante uma transferência.

  • Defina a classe de armazenamento de cada objeto como a do contentor de destino. Este é o comportamento predefinido.
  • Definir uma classe de armazenamento específica em todos os objetos que estão a ser transferidos.

Consulte a documentação de referência de metadataOptions para ver detalhes.

Do armazenamento do Microsoft Azure para o Cloud Storage

Exemplo de metadados Comportamento de preservação
Campos de metadados de chave fixa do Microsoft Azure Storage, como: Cache-Control, Content-Disposition e Content-Type. Preservado como metadados de chave fixa.
Metadados definidos pelo utilizador do Microsoft Azure Storage, formatados como pares de chave:valor. Para mais informações, consulte Definições e obtenção de propriedades e metadados para recursos do serviço Blob .

Preservados como um campo de metadados personalizado nos objetos do Cloud Storage de destino, que pode editar ou remover mais tarde.

ETag Preservado como um campo de metadados personalizados com a chave x-goog-source-etag, que pode editar ou remover mais tarde.
Tamanho do objeto. Preservado como size.
Autorizações do sistema de ficheiros POSIX suportadas pelo Azure Data Lake Storage (ADLS) Gen 2. Não preservado.
Controlo de acesso do Microsoft Azure Storage, especificamente x-ms-blob-public-access. Para mais informações, consulte a secção Cabeçalhos de resposta de Obter ACL do contentor . Não preservado.
Etiquetas de índice do Microsoft Azure Storage. Para mais informações, consulte o artigo Faça a gestão e encontre dados de blobs do Azure com etiquetas de índice de blobs . Não preservado.
Metadados de indicação de tempo do armazenamento do Microsoft Azure, como: Last-Modified, x-ms-creation-time, x-ms-version, x-ms-request-server-encrypted e x-ms-encryption-scope. Para mais informações, consulte o artigo Definir metadados de blobs .

Não preservado.

Os metadados de indicação de tempo da origem não são preservados. A hora de criação, timeCreated, reflete a hora em que um objeto é criado no Cloud Storage. Da mesma forma, updated reflete a hora em que os metadados de um objeto são modificados no Cloud Storage.

Classe de armazenamento

Existem várias opções para definir a classe de armazenamento durante uma transferência.

  • Defina a classe de armazenamento de cada objeto como a do contentor de destino. Este é o comportamento predefinido.
  • Definir uma classe de armazenamento específica em todos os objetos que estão a ser transferidos.

Consulte a documentação de referência de metadataOptions para ver detalhes.

Transferências entre contentores do Cloud Storage

Exemplo de metadados Comportamento de preservação

Campos de metadados de chave fixa do Cloud Storage, como: Cache-Control, Content-Disposition e Content-Type.

Para mais informações, consulte o artigo Metadados de objetos

Preservado como metadados de chave fixa.
Metadados definidos pelo utilizador do Cloud Storage, formatados como pares de chave:valor. Para mais informações, consulte o artigo Metadados personalizados.

Preservados como um campo de metadados personalizado nos objetos do Cloud Storage de destino, que pode editar ou remover mais tarde.

Tamanho do objeto Preservado como size.
Geração de objetos Preservado como um campo de metadados personalizado com a chave x-goog-reserved-source-generation, que pode editar mais tarde ou remover.
Retenções de objetos

As retenções com base em eventos não são preservadas. Se o contentor de destino tiver a propriedade de retenção predefinida baseada em eventos ativada, é aplicada uma retenção baseada em eventos aos objetos transferidos.

As retenções temporárias são preservadas por predefinição. Para rejeitar retenções temporárias durante a transferência, defina o campo temporaryHold do objeto metadataOptions como TEMPORARY_HOLD_SKIP.
Listas de controlo de acesso (LCAs)

Opcionalmente, é possível preservar as ACLs. Consulte a documentação de referência de metadataOptions para ver detalhes.

Quando preservar as ACLs, tenha cuidado para evitar a criação de objetos inacessíveis.

Para mais informações, consulte a documentação das listas de controlo de acesso do Cloud Storage.
Classe de armazenamento

Existem várias opções para definir a classe de armazenamento durante uma transferência.

  • Defina a classe de armazenamento de cada objeto como a do contentor de destino. Este é o comportamento predefinido.
  • Preservar a classe de armazenamento do objeto de origem.
  • Definir uma classe de armazenamento específica em todos os objetos que estão a ser transferidos.

Consulte a documentação de referência de metadataOptions para ver detalhes.
Chave de encriptação gerida pelo cliente

Se estiver a ser usada uma chave de encriptação gerida pelo cliente (CMEK) num objeto, o objeto pode, opcionalmente, usar a mesma chave quando é escrito no contentor de destino.

O comportamento predefinido é escrever o objeto no contentor de destino usando o método de encriptação do contentor.

Quando preserva a CMEK original, tenha em atenção as seguintes limitações:

Consulte a documentação de referência de metadataOptions para ver detalhes.
Metadados de data/hora

timeCreated pode ser preservado opcionalmente. O valor preservado é armazenado no campo customTime do objeto transferido no Cloud Storage. Consulte a documentação de referência de metadataOptions para ver detalhes.

Os metadados updated não são preservados.

Outros metadados não editáveis do Cloud Storage, como etag e componentCount. Não preservado.

Para ver uma lista de metadados no Cloud Storage, consulte a secção Objetos.

Transferência da lista de URLs para o Cloud Storage

Para mais informações sobre listas de URLs, consulte o artigo Criar uma lista de URLs.

Exemplo de metadados Comportamento de preservação
Campos de metadados de chave fixa, como: Cache-Control, Content-Disposition e Content-Type. Preservados como metadados editáveis.
Content-Length e MD5

Preservados como metadados não editáveis.

Se a origem não fornecer um valor hash MD5, não preservamos um valor.

Este comportamento de preservação é específico de Content-Length e MD5. Quaisquer outros metadados não editáveis não indicados não são preservados.

Metadados de data/hora, como: data/hora de criação, data/hora de modificação e outros metadados específicos da origem.

Não preservado.

Os metadados de indicação de tempo da origem não são preservados. A hora de criação, timeCreated, reflete a hora em que um objeto é criado no Cloud Storage. Da mesma forma, updated reflete a hora em que os metadados de um objeto são modificados no Cloud Storage.

Classe de armazenamento

Existem várias opções para definir a classe de armazenamento durante uma transferência.

  • Defina a classe de armazenamento de cada objeto como a do contentor de destino. Este é o comportamento predefinido.
  • Definir uma classe de armazenamento específica em todos os objetos que estão a ser transferidos.

Consulte a documentação de referência de metadataOptions para ver detalhes.

Transferências do sistema de ficheiros POSIX

Quando transfere ficheiros de sistemas de ficheiros POSIX, o Serviço de transferência de armazenamento pode, opcionalmente, preservar determinados atributos como metadados personalizados. Se estes ficheiros forem posteriormente escritos novamente num sistema de ficheiros, o Serviço de transferência de armazenamento pode converter os metadados preservados novamente em atributos POSIX.

Exemplo de metadados Comportamento de preservação
Hora de modificação (mtime)

Preservado.

mtime é preservado como metadados personalizados com a chave goog-reserved-file-mtime.
Tamanho do ficheiro

Preservado.

O tamanho do ficheiro é preservado como size.
UID numérico
GID numérico
MODO numérico
Links simbólicos

Opcional.

O comportamento de preservação é especificado com o objeto metadataOptions. Consulte o artigo Preservar metadados POSIX opcionais para ver detalhes.

O comportamento predefinido é não preservar metadados.
Metadados da pasta Os metadados ao nível da pasta só são preservados para transferências entre sistemas de ficheiros. As definições de preservação do UID, GID e MODE da transferência aplicam-se a ficheiros e pastas para estas transferências.

O nome mtime não é preservado para pastas. mtime está definido para a hora de criação da pasta no sistema de ficheiros de destino.

Os metadados das pastas não são preservados para transferências de manifestos.
Classe de armazenamento

Existem várias opções para definir a classe de armazenamento durante uma transferência.

  • Defina a classe de armazenamento de cada objeto como a do contentor de destino. Este é o comportamento predefinido.
  • Definir uma classe de armazenamento específica em todos os objetos que estão a ser transferidos.

Consulte a documentação de referência de metadataOptions para ver detalhes.

Preservar metadados POSIX opcionais

Para preservar um ou mais dos seguintes elementos: UID numérico, GID numérico, MODE numérico e links simbólicos, especifique um objeto no corpo da tarefa de transferência.metadataOptions

Estas opções aplicam-se a transferências de POSIX para o Cloud Storage e de Cloud Storage para POSIX. Para este último, os metadados têm de ter sido preservados quando os ficheiros foram transferidos inicialmente para o Cloud Storage.

{
  "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 para Cloud Storage

Os metadados preservados são armazenados no Cloud Storage como pares de chave:valor de metadados personalizados.

  • O GID numérico é armazenado como goog-reserved-posix-gid.
  • O UID numérico é armazenado como goog-reserved-posix-uid.
  • O MODE numérico é armazenado como goog-reserved-posix-mode.

Para links simbólicos, o serviço de transferência de armazenamento preserva o link de destino como um objeto no armazenamento na nuvem com as seguintes qualidades:

  • A chave do objeto é composta pelo prefixo de destino mais o caminho para a ligação simbólica, relativamente a root_directory.
  • Metadados do objeto:
    • Todos os metadados de links simbólicos são preservados como metadados de objetos do Cloud Storage.
    • É criada uma entrada de metadados personalizados: goog-reserved-file-is-symlink:true.
  • O conteúdo do objeto é o destino do link simbólico. Por exemplo, para um symlink sym-> dir1/target, o conteúdo do objeto é "dir1/target".

O serviço de transferência de armazenamento não valida o link nem copia o ficheiro de destino.

Do Cloud Storage para POSIX

Se os metadados forem preservados quando os ficheiros são transferidos para o Cloud Storage, esses metadados podem ser reescritos nos ficheiros quando são transferidos novamente para um sistema de ficheiros POSIX.

Se uma opção de metadados estiver definida para preservar, o Serviço de transferência de armazenamento toma as seguintes ações:

  • Links simbólicos: o serviço de transferência de armazenamento cria um ficheiro de ligação simbólica que aponta para o link de destino. Se o ficheiro de destino não existir, a ligação simbólica é interrompida.
  • GID, UID e MODE: os valores armazenados nos metadados do Cloud Storage são reescritos no ficheiro.

POSIX para POSIX

As transferências entre sistemas de ficheiros podem preservar opcionalmente o GID, o UID e o MODE para ficheiros e pastas.

A hora da última modificação é guardada para ficheiros, mas não para pastas. mtime está definido como a hora de criação da pasta no sistema de ficheiros de destino.

O serviço de transferência de armazenamento guarda os metadados das pastas criando objetos de pastas de 0 bytes no contentor intermédio e, em seguida, copiando esses metadados de volta para a pasta no sistema de ficheiros de destino. Por este motivo, o número de objetos criados no contentor intermédio pode ser superior ao número de ficheiros que estão a ser transferidos.