Validación de datos y detección de cambios

Cloud Storage te recomienda validar los datos que transfieres a tus buckets y desde ellos. En esta página, se describen las prácticas recomendadas para realizar validaciones a través de las sumas de comprobación CRC32C o MD5 y se describe el algoritmo de detección de cambios que usa el comando gcloud storage rsync.

Protege contra la corrupción de datos mediante hashes

Existen varias maneras en las que los datos se pueden corromper cuando los subes o los descargas de la nube:

  • Errores de memoria en computadoras del cliente o del servidor, o routers a lo largo de la ruta
  • Errores de software (p. ej., en una biblioteca que usen los clientes)
  • Cambios en el archivo fuente cuando se realiza una carga durante un período prolongado

Cloud Storage admite dos tipos de hash que puedes usar para verificar la integridad de tus datos: CRC32C y MD5. CRC32C es el método de validación recomendado para realizar verificaciones de integridad. Los clientes que prefieren MD5 pueden usar ese hash, pero no estos no son compatibles con todos los objetos compuestos.

Validación del cliente

Puedes realizar una verificación de integridad de los datos descargados si generas un hash de los datos en el momento y comparas los resultados con las sumas de comprobación proporcionadas por el servidor. Sin embargo, ten en cuenta que las sumas de comprobación proporcionadas por el servidor se basan en el objeto completo, ya que se almacena en Cloud Storage, lo que significa que los siguientes tipos de descargas no se pueden validar a través de los hashes que proporciona el servidor:

  • Descargas que se someten a una transcodificación descompresiva, porque la suma de comprobación proporcionada por el servidor representa el objeto en su estado comprimido, mientras que a los datos entregados se les quitó la compresión y, en consecuencia, se genera un valor de hash diferente.

  • Una respuesta que contiene solo una parte de los datos del objeto, que ocurre cuando se realiza una solicitud range. Recomendamos el uso de solicitudes de rango solo para reiniciar la descarga de un objeto completo después de la última compensación recibida, debido a que, en ese caso, puedes calcular y validar la suma de verificación cuando se complete la descarga.

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

Validación del servidor

Cloud Storage realiza una validación del lado del servidor en los siguientes casos:

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

  • Cuando se proporciona el hash MD5 o CRC32C esperado de un objeto en una solicitud de carga 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 a la API de JSON aplicables, debes proporcionar sumas de comprobación como parte del recurso de objetos.

    • En las solicitudes a la API de XML aplicables, debes proporcionar sumas de comprobación a través del encabezado x-goog-hash. La API de XML también acepta el encabezado Content-MD5 HTTP estándar (consulta la especificación).

    • De manera alternativa, puedes realizar una validación del cliente de tus cargas a través de la emisión de una solicitud para los metadatos del objeto subido, la comparación del valor de hash del objeto subido con el valor esperado y la eliminación del objeto en caso de no coinciden. Este método es útil si no se conoce el hash MD5 o CRC32C del objeto al inicio de la carga.

En el caso de las cargas compuestas paralelas, los usuarios deben realizar una verificación de integridad para cada carga de componente y, luego, usar las condiciones previas con las solicitudes de composición para protegerse de las condiciones de carrera. Las solicitudes de redacción no realizan una validación del servidor, por lo que los usuarios que quieran una verificación de integridad de extremo a extremo deben realizar una validación del cliente en el objeto compuesto nuevo.

Validación de Google Cloud CLI

Para Google Cloud CLI, se validan los datos copiados desde y hacia un bucket de Cloud Storage. 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 verificación de los datos de destino, gcloud CLI borra la copia no válida y, luego, muestra un mensaje de advertencia. Eso no suele suceder. Si coincide, puedes intentar de nuevo la operación.

Esta validación automática se produce después de que se completa el objeto, por lo que los objetos no válidos son visibles durante 1 o 3 segundos antes de que se identifiquen y se borren. Además, existe la posibilidad de que la gcloud CLI se interrumpa después de que se complete la carga, pero antes de que realice la validación, lo que deja el objeto no válido en su lugar. Estos problemas se pueden evitar cuando se suben archivos únicos a Cloud Storage con la validación del servidor, que ocurre cuando se usan las siguientes marcas --content-md5.

Detección de cambios para rsync

El comando gcloud storage rsync también puede usar sumas de verificación MD5 o CRC32C para determinar si hay una diferencia entre la versión de un objeto que se encuentra en la fuente 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 buckets en la nube y el objeto tiene una suma de comprobación MD5 o CRC32C en ambos depósitos.

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

En los casos en los que el objeto relevante tiene un valor mtime en el origen y el destino, como cuando el origen y el destino son sistemas de archivos, el comando rsync compara el tamaño de los objetos y mtime, en lugar de usar sumas de comprobación. Del mismo modo, si la fuente es un bucket en la nube y el destino es un sistema de archivos local, el comando rsync usa la hora creada para el objeto de origen como sustituto de mtime, y el comando no usa sumas de comprobación.

Si no hay mtime ni sumas de comprobación disponibles, rsync solo compara los tamaños de archivo cuando se determina si hay un 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 cuando se comparan objetos compuestos con objetos en un proveedor de servicios en la nube que no admite CRC32C, ya que los objetos compuestos no tienen suma de comprobación MD5.

¿Qué sigue?