Validation des données et détection des modifications

Cloud Storage vous encourage à valider les données que vous transférez vers et depuis vos buckets. Cette page décrit les bonnes pratiques à suivre pour effectuer des validations à l'aide de sommes de contrôle CRC32C ou MD5, et décrit l'algorithme de détection des modifications utilisé par la commande gcloud storage rsync.

Se protéger contre la corruption des données à l'aide de hachages

Lorsque les données sont transférées depuis ou vers le cloud, elles peuvent être corrompues pour de multiples raisons :

  • Erreurs de mémoire sur les ordinateurs clients ou serveurs, ou sur les routeurs le long du chemin
  • Bugs logiciels (p.ex., dans une bibliothèque utilisée par les clients)
  • Modifications apportées au fichier source alors qu'une importation est en cours sur une période prolongée

Cloud Storage accepte deux types de hachages que vous pouvez utiliser pour vérifier l'intégrité de vos données : CRC32C et MD5. CRC32C est la méthode de validation recommandée pour effectuer des vérifications d'intégrité. Les clients qui préfèrent le MD5 peuvent utiliser ce hachage, mais les hachages MD5 ne sont pas compatibles avec tous les objets.

Validation côté client

Vous pouvez effectuer une vérification de l'intégrité des données téléchargées en hachant les données à la volée et en comparant les résultats aux sommes de contrôle fournies par le serveur. Notez cependant que les sommes de contrôle fournies par le serveur sont basées sur l'objet complet tel qu'il est stocké dans Cloud Storage. Cela signifie que les types de téléchargements suivants ne peuvent pas être validés à l'aide des hachages fournis par le serveur :

  • Téléchargements soumis à un transcodage par décompression, car la somme de contrôle fournie par le serveur représente l'objet dans son état compressé, tandis que les données diffusées voient leur compression supprimée et, par conséquent, ont une valeur de hachage différente.

  • Une réponse qui ne contient qu'une partie des données d'objet, qui se produit lors de l'envoi d'une requête range Cloud Storage recommande donc de n'utiliser les requêtes de plage qu'à l'occasion d'un redémarrage du téléchargement d'un objet complet après le dernier décalage reçu, car vous pourrez alors calculer et valider la somme de contrôle à la fin du téléchargement complet.

Si vous pouvez valider le téléchargement à l'aide de sommes de contrôle, vous devez supprimer les données téléchargées comportant des valeurs de hachage incorrectes et appliquer la logique de nouvelle tentative recommandée pour relancer la requête.

Validation côté serveur

Cloud Storage procède à une validation côté serveur dans les cas suivants :

  • Lorsque vous effectuez une requête de copie ou de réécriture dans Cloud Storage.

  • Lorsque vous fournissez le hachage MD5 ou CRC32C attendu d'un objet dans une requête d'importation. Cloud Storage ne crée l'objet que si le hachage que vous fournissez correspond à la valeur calculée par Cloud Storage. Si ce n'est pas le cas, la requête est rejetée avec une erreur BadRequestException: 400.

    • Dans les requêtes d'API JSON applicables, vous fournissez des sommes de contrôle dans le cadre de la ressource d'objets.

    • Dans les requêtes d'API XML applicables, vous fournissez des sommes de contrôle à l'aide de l'en-tête x-goog-hash. L'API XML accepte également l'en-tête Content-MD5 HTTP standard (reportez-vous à la spécification).

    • Vous pouvez également effectuer une validation côté client de vos importations. Pour ce faire, envoyez une requête de métadonnées de l'objet importé, comparez la valeur de hachage de l'objet importé à la valeur attendue, puis supprimez l'objet dans le cas d'une non-concordance. Cette méthode est utile si le hachage MD5 ou CRC32C de l'objet n'est pas connu au début de l'importation.

Dans le cas d'importations composites parallèles, les utilisateurs doivent effectuer un contrôle d'intégrité pour chaque importation de composants, puis utiliser les conditions préalables avec leurs requêtes de composition pour se protéger d'une condition de concurrence. Les requêtes de composition n'effectuent pas de validation côté serveur. Par conséquent, les utilisateurs qui souhaitent effectuer une vérification de l'intégrité de bout en bout doivent effectuer une validation côté client sur le nouvel objet composite.

Validation de Google Cloud CLI

Pour Google Cloud CLI, les données copiées vers ou depuis un bucket Cloud Storage sont validées. Cela s'applique aux commandes cp, mv et rsync. Si la somme de contrôle des données sources ne correspond pas à celle des données de destination, la gcloud CLI supprime la copie non valide et affiche un message d'avertissement. Ceci arrive très rarement. Vous pouvez retenter l'opération si cela se produit.

Cette validation automatique a lieu une fois l'objet lui-même finalisé. Les objets non valides sont donc visibles pendant 1 à 3 secondes avant d'être identifiés et supprimés. De plus, la gcloud CLI peut être interrompue après la fin de l'importation, mais avant qu'il effectue la validation, laissant l'objet non valide en place. Ces problèmes peuvent être évités lors de l'importation de fichiers uniques dans Cloud Storage à l'aide de la validation côté serveur, qui se produit lorsque vous utilisez l'option --content-md5.

Détection des modifications pour rsync

La commande gcloud storage rsync peut également utiliser des sommes de contrôle MD5 ou CRC32C pour déterminer s'il existe une différence entre la version d'un objet trouvée à la source et celle trouvée à l'emplacement de destination. La commande compare les sommes de contrôle dans les cas suivants :

  • La source et la destination sont des buckets cloud, et l'objet possède une somme de contrôle MD5 ou CRC32C dans les deux buckets.

  • L'objet n'a pas d'heure de modification de fichier (mtime) dans la source ou la destination.

Si l'objet concerné a une valeur mtime à la fois dans la source et dans la destination, par exemple lorsque la source et la destination sont des systèmes de fichiers, la commande rsync compare la taille des objets et mtime, au lieu d'utiliser des sommes de contrôle. De même, si la source est un bucket Cloud et que la destination est un système de fichiers local, la commande rsync utilise l'heure créée pour l'objet source pour remplacer mtime, et la commande n'utilise pas de sommes de contrôle.

Si ni mtime, ni les sommes de contrôle ne sont disponibles, rsync ne compare que les tailles de fichier pour déterminer s'il existe une modification entre la version source d'un objet et la version de destination. Par exemple, ni mtime, ni les sommes de contrôle ne sont disponibles lorsque vous comparez des objets composites avec des objets chez un fournisseur cloud qui n'est pas compatible avec le hachage CRC32C, car les objets composites ne possèdent pas de sommes de contrôle MD5.

Étape suivante