Validación de datos y detección de cambios

Cloud Storage te recomienda que valides los datos que transfieres a tus segmentos y desde ellos. En esta página se describen las prácticas recomendadas para realizar validaciones mediante sumas de comprobación CRC32C o MD5 y se explica el algoritmo de detección de cambios que utiliza el comando gcloud storage rsync.

Protegerse frente a la corrupción de datos mediante hashes

Los datos se pueden dañar de varias formas al subirlos o descargarlos de la nube:

  • Errores de memoria en ordenadores cliente o servidor, o en routers de la ruta
  • Errores de software (por ejemplo, en una biblioteca que usan los clientes)
  • Cambios en el archivo de origen cuando se produce una subida durante un periodo prolongado

Cloud Storage admite dos tipos de hashes que puede usar para comprobar la integridad de sus datos: CRC32C y MD5. CRC32C es el método de validación recomendado para realizar comprobaciones de integridad. Los clientes que prefieran MD5 pueden usar ese hash, pero no se admite en todos los objetos.

Validación del lado del cliente

Puede realizar una comprobación de integridad de los datos descargados cifrando los datos sobre la marcha y comparando los resultados con las sumas de comprobación proporcionadas por el servidor. Sin embargo, tenga en cuenta que las sumas de comprobación proporcionadas por el servidor se basan en el objeto completo tal como se almacena en Cloud Storage, lo que significa que los siguientes tipos de descargas no se pueden validar con los hashes proporcionados por el servidor:

  • Descargas que se someten a transcodificación de descompresión, ya que la suma de comprobación proporcionada por el servidor representa el objeto en su estado comprimido, mientras que los datos servidos no tienen compresión y, por lo tanto, tienen un valor hash diferente.

  • Una respuesta que contiene solo una parte de los datos del objeto, que se produce al hacer una solicitud range. Cloud Storage recomienda usar solicitudes de intervalo solo para reiniciar la descarga de un objeto completo después del último desplazamiento recibido, ya que, en ese caso, puedes calcular y validar la suma de comprobación cuando se complete la descarga.

En los casos en los que puedas validar la descarga mediante sumas de comprobación, debes descartar los datos descargados con valores hash incorrectos y usar la lógica de reintento recomendada para volver a intentar la solicitud.

Validación del lado del servidor

Cloud Storage realiza validaciones del lado del servidor en los siguientes casos:

  • Cuando realizas una solicitud de copia o de reescritura en Cloud Storage.

  • Cuando se proporciona el hash MD5 o CRC32C esperado de un objeto en una solicitud de subida. Cloud Storage solo crea el objeto si el hash que proporcionas coincide con el valor que calcula Cloud Storage. Si no coincide, la solicitud se rechaza con un error BadRequestException: 400.

    • En las solicitudes de la API JSON aplicables, proporciona sumas de comprobación como parte del recurso objects.

    • En las solicitudes de la API XML aplicables, se proporcionan sumas de comprobación mediante el encabezado x-goog-hash. La API XML también acepta el encabezado Content-MD5 HTTP estándar (consulta la especificación).

    • También puede validar sus subidas del lado del cliente. Para ello, envíe una solicitud de los metadatos del objeto subido, compare el valor de hash del objeto subido con el valor esperado y elimine el objeto si no coinciden. Este método es útil si el hash MD5 o CRC32C del objeto no se conoce al inicio de la subida.

En el caso de las subidas compuestas paralelas, los usuarios deben realizar una comprobación de integridad de cada componente y, a continuación, usar precondiciones con sus solicitudes de composición para protegerse frente a las condiciones de carrera. Las solicitudes de composición no realizan validaciones del lado del servidor, por lo que los usuarios que quieran comprobar la integridad de extremo a extremo deben realizar validaciones del lado del cliente en el nuevo objeto compuesto.

Validación de Google Cloud CLI

En el caso de la CLI de Google Cloud, los datos copiados en un segmento de Cloud Storage o desde él se validan. Esto se aplica a los comandos cp, mv y rsync. Si la suma de comprobación de los datos de origen no coincide con la suma de comprobación de los datos de destino, la CLI de gcloud elimina la copia no válida e imprime un mensaje de advertencia. Esto ocurre muy rara vez. Si es así, vuelve a intentar la operación.

Esta validación automática se produce después de que se finalice el objeto, por lo que los objetos no válidos se muestran durante 1-3 segundos antes de que se identifiquen y se eliminen. Además, existe la posibilidad de que se interrumpa la CLI de gcloud después de que se complete la subida, pero antes de que se realice la validación, lo que dejaría el objeto no válido en su lugar. Estos problemas se pueden evitar al subir archivos individuales a Cloud Storage mediante la validación del lado del servidor, que se produce al usar la marca --content-md5.

Detección de cambios en rsync

El comando gcloud storage rsync también puede usar sumas de comprobación MD5 o CRC32C para determinar si hay alguna diferencia entre la versión de un objeto que se encuentra en el origen y la versión que se encuentra en el destino. El comando compara las sumas de comprobación en los siguientes casos:

  • El origen y el destino son segmentos en la nube, y el objeto tiene una suma de comprobación MD5 o CRC32C en ambos segmentos.

  • El objeto no tiene una hora de modificación de archivo (mtime) en el origen ni en el destino.

En los casos en los que el objeto pertinente tiene un valor mtime tanto en el origen como en el destino (por ejemplo, cuando el origen y el destino son sistemas de archivos), el comando rsync compara el tamaño y el mtime de los objetos en lugar de usar sumas de comprobación. Del mismo modo, si el origen es un contenedor en la nube y el destino es un sistema de archivos local, el comando rsync usa la hora de creación del objeto de origen como sustituto de mtime y no usa sumas de comprobación.

Si no hay disponibles ni mtime ni sumas de comprobación, rsync solo compara los tamaños de los archivos para determinar si hay algún cambio entre la versión de origen de un objeto y la versión de destino. Por ejemplo, ni mtime ni las sumas de comprobación están disponibles al comparar objetos compuestos con objetos de un proveedor de servicios en la nube que no admite CRC32C, ya que los objetos compuestos no tienen sumas de comprobación MD5.

Siguientes pasos