Datenvalidierung und Änderungserkennung

Mit Cloud Storage können Sie die Daten validieren, die Sie zu und aus Ihren Buckets übertragen. Auf dieser Seite werden Best Practices für Validierungen mit CRC32C- oder MD5-Prüfsummen erläutert. Außerdem wird der Änderungserkennungsalgorithmus beschrieben, der vom Befehl gcloud storage rsync verwendet wird.

Vor Datenbeschädigung durch Hashes schützen

Es gibt eine Vielzahl von Möglichkeiten, wie Daten beim Hochladen in die Cloud oder beim Herunterladen beschädigt werden können:

Fehler im Arbeitsspeicher des Client- oder Servercomputers oder eines Routers entlang des Pfads
Softwarefehler, z. B. in einer von den Kunden verwendeten Bibliothek
Änderungen an der Quelldatei, wenn ein Upload über einen längeren Zeitraum erfolgt

Cloud Storage unterstützt zwei Arten von Hashes, mit denen Sie die Integrität Ihrer Daten prüfen können: CRC32C und MD5. CRC32C ist die empfohlene Validierungsmethode für Integritätsprüfungen. Kunden, die MD5 bevorzugen, können diesen Hash verwenden. MD5-Hashes werden für alle Objekte jedoch nicht unterstützt.

Clientseitige Validierung

Sie können eine Integritätsprüfung für heruntergeladene Daten durchführen, indem Sie die Daten in Echtzeit hashen und Ihre Ergebnisse mit den vom Server bereitgestellten Prüfsummen vergleichen. Die vom Server bereitgestellten Prüfsummen basieren jedoch auf dem vollständigen Objekt, das in Cloud Storage gespeichert ist. Dies bedeutet, dass die folgenden Downloadtypen nicht mit den vom Server bereitgestellten Hashes überprüft werden können. Für

Downloads, die einer dekomprimierenden Transcodierung unterzogen werden, da die vom Server bereitgestellte Prüfsumme das Objekt in dem komprimierten Zustand darstellt, während die bereitgestellten Daten ohne Komprimierung gesendet wurden und daher einen anderen Hash-Wert haben.
Eine Antwort, die nur einen Teil der Objektdaten enthält, was bei einer range-Anfrage geschieht. Für Cloud Storage wird deshalb empfohlen, Anfragebereiche nur für den Neustart des Downloads eines kompletten Objekts nach dem letzten erhaltenen Versatz zu verwenden. In diesem Fall können Sie die Prüfsumme berechnen und validieren, wenn der vollständige Download abgeschlossen ist.

Wenn Sie den Download mithilfe von Prüfsummen validieren können, sollten Sie heruntergeladene Daten mit falschen Hashwerten verwerfen und die empfohlene Wiederholungslogik verwenden, um die Anfrage zu wiederholen.

Serverseitige Validierung

In folgenden Fällen führt Cloud Storage eine serverseitige Validierung durch:

Wenn Sie eine Kopier- oder Umschreibungsanfrage in Cloud Storage ausführen.
Wenn Sie den erwarteten MD5- oder CRC32C-Hash eines Objekts in einer Uploadanfrage angeben. Cloud Storage erstellt das Objekt nur, wenn der Hash mit dem Wert übereinstimmt, den Cloud Storage berechnet. Wenn sie nicht übereinstimmt, wird die Anfrage mit dem Fehler BadRequestException: 400 abgelehnt.
- In entsprechenden JSON API-Anfragen geben Sie Prüfsummen als Teil der Objektressource an.
- In entsprechenden XML API-Anfragen geben Sie Prüfsummen mithilfe des Headers x-goog-hash an. Die XML API akzeptiert auch den standardmäßigen HTTP-Header Content-MD5 (siehe Spezifikation).
- Alternativ haben Sie die Möglichkeit, Ihre Uploads clientseitig zu validieren. Stellen Sie dazu eine Anfrage für die Metadaten des hochgeladenen Objekts, vergleichen Sie den Hash-Wert des hochgeladenen Objekts mit dem erwarteten Wert und löschen Sie das Objekt im Fall eines Abweichung. Diese Methode ist nützlich, wenn der MD5- oder CRC32C-Hash des Objekts nicht zu Beginn des Uploads bekannt ist.

Bei parallelen zusammengesetzten Uploads sollten Nutzer für den Upload jeder Komponente eine Integritätsprüfung durchführen und anschließend bei ihren Zusammensetzungsanfragen Vorbedingungen für die Komponenten verwenden, um diese vor Race-Bedingungen zu schützen. Bei Zusammensetzungsanfragen wird keine serverseitige Validierung durchgeführt. Nutzer, die eine End-to-End-Integritätsprüfung wünschen, sollten deshalb eine clientseitige Validierung für das neue zusammengesetzte Objekt durchführen.

Validierung der Google Cloud CLI

Für die Google Cloud CLI werden Daten validiert, die in oder aus einem Cloud Storage-Bucket kopiert wurden. Dies gilt für die Befehle cp, mv und rsync. Wenn die Prüfsumme der Quelldaten nicht mit der Prüfsumme der Zieldaten übereinstimmt, löscht die gcloud CLI die ungültige Kopie und gibt eine Warnmeldung aus. Dies geschieht nur sehr selten. Sollte dieser Fall eintreten, sollten Sie versuchen, den Vorgang zu wiederholen.

Diese automatische Validierung erfolgt nach Abschluss des Objekts selbst. Daher sind ungültige Objekte 1 bis 3 Sekunden lang sichtbar, bevor sie identifiziert und gelöscht werden. Darüber hinaus besteht die Möglichkeit, dass die gcloud CLI nach Abschluss des Uploads, aber vor der Validierung unterbrochen wird, wodurch das ungültige Objekt beibehalten wird. Diese Probleme können beim Hochladen einzelner Dateien in Cloud Storage mithilfe der serverseitigen Validierung vermieden werden, die bei Verwendung des Flags --content-md5 erfolgt.

Änderungserkennung für `rsync`

Der Befehl gcloud storage rsync kann auch MD5- oder CRC32C-Prüfsummen verwenden, um festzustellen, ob es einen Unterschied zwischen der Version eines Objekts an der Quelle gibt und der Version am Ziel “ Der Befehl vergleicht Prüfsummen in den folgenden Fällen:

Die Quelle und das Ziel sind beide Cloud-Buckets und das Objekt hat in beiden Buckets eine MD5- oder CRC32C-Prüfsumme.
Das Objekt hat keine Dateiänderungszeit (mtime) in der Quelle oder im Ziel.

In Fällen, in denen das relevante Objekt sowohl in Quelle als auch in Ziel einen mtime-Wert hat, z. B. wenn Quelle und Ziel Dateisysteme sind, vergleicht der Befehl rsync die Größe des Objekts und mtime anstelle von Prüfsummen. Wenn die Quelle ein Cloud-Bucket und das Ziel ein lokales Dateisystem ist, verwendet der Befehl rsync die für das Quellobjekt erstellte Zeit als Ersatz für mtime und der Befehl verwendet keine Prüfsummen.

Wenn weder mtime noch Prüfsummen verfügbar sind, vergleicht rsync die Dateigrößen nur, wenn festgestellt wird, ob sich die Quellversion eines Objekts und die Zielversion ändert. Zum Beispiel sind weder mtime noch Prüfsummen verfügbar, wenn Sie zusammengesetzte Objekte mit Objekten bei einem Cloud-Anbieter vergleichen, der CRC32C nicht unterstützt, da zusammengesetzte Objekte kein MD5-Prüfsummen haben.