Validação de dados e detecção de alterações

O Cloud Storage recomenda que você valide os dados transferidos de e para seus buckets. Esta página descreve as práticas recomendadas para realizar validações usando somas de verificação CRC32C ou MD5 e descreve o algoritmo de detecção de alteração usado pelo comando gcloud storage rsync.

Proteger contra corrupção de dados usando hashes

Há várias maneiras de corromper os dados durante o upload ou o download do Cloud:

  • Erros de memória em computadores clientes ou servidores, ou roteadores ao longo do caminho.
  • Erros de software (por exemplo, em uma biblioteca que os clientes usam).
  • Alterações no arquivo de origem quando ocorre um upload durante um período prolongado.

O Cloud Storage aceita dois tipos de hashes que podem ser usados para verificar a integridade dos dados: CRC32C e MD5. O CRC32C é o método de validação recomendado para realizar verificações de integridade. Os clientes que preferem o MD5 podem usar esse hash, mas os hashes MD5 não são compatíveis com todos os objetos.

Validação do lado do cliente

Você pode executar uma verificação de integridade para dados baixados, gerando hash dos dados em tempo real e comparando seus resultados com as somas de verificação fornecidas pelo servidor. Observe, no entanto, que as somas de verificação fornecidas pelo servidor são baseadas no objeto completo, já que são armazenadas no Cloud Storage, ou seja, os seguintes tipos de downloads não podem ser validados usando os hashes fornecidos pelo servidor:

  • Downloads que passam por transcodificação descompressiva, porque a soma de verificação fornecida pelo servidor representa o objeto em seu estado compactado, enquanto a compactação dos dados veiculados é removida e, consequentemente, já um valor de hash diferente.

  • Uma resposta que contém somente uma parte dos dados do objeto, que ocorre ao fazer uma solicitação range. O Cloud Storage recomenda usar solicitações de intervalo apenas para reiniciar o download de um objeto inteiro após o último deslocamento recebido, porque, nesse caso, é possível calcular e validar a soma de verificação quando todo o download for concluído.

Nos casos em que for possível validar o download usando somas de verificação, descarte dados de download com valores de hash incorretos e use a lógica de repetição recomendada para repetir a solicitação.

Validação do servidor

O Cloud Storage realiza a validação do servidor nos seguintes casos:

  • Quando você faz uma solicitação de cópia ou regravação no Cloud Storage.

  • Ao fornecer o hash MD5 ou CRC32C esperado de um objeto em uma solicitação de upload. O Cloud Storage criará o objeto somente se o hash fornecido corresponder ao valor calculado pelo Cloud Storage. Se não corresponder, a solicitação será rejeitada com um erro BadRequestException: 400.

    • Em solicitações de API JSON aplicáveis, você fornece somas de verificação como parte do recurso de objetos.

    • Em solicitações de API XML aplicáveis, você fornece somas de verificação usando o cabeçalho x-goog-hash. A API XML também aceita a solicitação padrão Cabeçalho Content-MD5 HTTP (consulte a especificação).

    • Como alternativa, você pode realizar uma validação do lado do cliente de seus envios emitindo uma solicitação para os metadados do objeto enviado, comparando o valor de hash do objeto enviado com o valor esperado e excluindo o objeto em caso de incompatibilidade. Esse método é útil se o hash MD5 ou CRC32C do objeto não for conhecido no início do upload.

No caso de uploads compostos paralelos, os usuários precisam executar uma verificação de integridade para cada upload de componente e, em seguida, usam as condições prévias com as solicitações de composição para proteção contra disputas. Solicitações compostas não realizam validação do lado do servidor. Assim, os usuários que querem ter integridade de ponta a ponta precisam realizar a validação do lado do cliente no novo objeto composto.

Validação da CLI do Google Cloud

Para a CLI do Google Cloud, os dados copiados de ou para um bucket do Cloud Storage são validados. Isso se aplica aos comandos cp, mv e rsync. Quando o checksum dos dados de origem não corresponde ao checksum dos dados de destino, a gcloud CLI exclui a cópia inválida e gera uma mensagem de aviso. Isso raramente acontece. Se isso acontecer, repita a operação.

Essa validação automática ocorre após a finalização do próprio objeto. Portanto, objetos inválidos ficam visíveis por um a três segundos antes de serem identificados e excluídos. Além disso, há uma chance de que a gcloud CLI possa ser interrompida após a conclusão do upload, mas antes de realizar a validação, deixando o objeto inválido no lugar. Esses problemas podem ser evitados ao fazer upload de arquivos individuais para o Cloud Storage com a validação do lado do servidor, que ocorre ao usar a flag --content-md5.

Detecção de mudanças para rsync

O comando gcloud storage rsync também pode usar somas de verificação MD5 ou CRC32C para determinar se há uma diferença entre a versão de um objeto encontrado na origem e a versão encontrada no destino. O comando compara somas de verificação nos seguintes casos:

  • A origem e o destino são buckets na nuvem, e o objeto tem um checksum MD5 ou CRC32C em ambos os buckets.

  • O objeto não tem um horário de modificação do arquivo (mtime) na origem ou destino.

Nos casos em que o objeto relevante tem um valor mtime na origem e destino, como quando a origem e o destino são sistemas de arquivos, o comando rsync compara o tamanho de objeto e mtime, em vez de usar checksums. Da mesma forma, se a origem for um bucket em nuvem e o destino for um sistema de arquivos local, o comando rsync usará o horário de criação do objeto de origem como substituto de mtime, e o comando não usa somas de verificação.

Se mtime e as somas de verificação não estiverem disponíveis, o rsync só vai comparar os tamanhos dos arquivos ao determinar se há uma mudança entre a versão de origem de um objeto e a versão de destino. Por exemplo, nem mtime nem as somas de verificação estão disponíveis ao comparar objetos compostos com objetos em um provedor de nuvem que não oferece suporte a CRC32C, porque objetos compostos não têm checksums MD5.

A seguir